-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: [EUDIW-209] Add Remote presentation for Potential #174
base: eudiw-master
Are you sure you want to change the base?
Conversation
…ition # Conflicts: # src/credential/presentation/__tests__/04-retrieve-jwks.test.ts
let pubKey; | ||
|
||
// verify token signature to ensure the request object is authentic | ||
if (jwkKeys) { | ||
pubKey = jwkKeys.find( | ||
({ kid }) => kid === requestObjectJwt.protectedHeader.kid | ||
); | ||
} | ||
|
||
if (!pubKey) { | ||
throw new UnverifiedEntityError("Request Object signature verification!"); | ||
} | ||
await verify(requestObjectEncodedJwt, pubKey); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually we avoid the usage of let
as much as possibile to prefer an immutable data approach. This could be refactored as:
const pubKey = jwkKeys?.find(
({ kid }) => kid === requestObjectJwt.protectedHeader.kid
);
if (!pubKey) {
throw new UnverifiedEntityError("Request Object signature verification!");
}
What do you think?
let requiredClaimNames: string[] = []; | ||
let optionalClaimNames: string[] = []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above
let [matchedPath, matchedValue] = findMatchedClaim( | ||
field.path, | ||
disclosuresAsPayload | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here is more complicated using const because matchedPath really change...maybe enforce to use const could cause the code to become less readable
let requestBody: string; | ||
if (requestObject.response_mode === "direct_post.jwt") { | ||
requestBody = await buildDirectPostJwtBody( | ||
jwkKeys, | ||
requestObject, | ||
vp_token, | ||
presentation_submission | ||
); | ||
} else { | ||
requestBody = await buildDirectPostBody( | ||
requestObject, | ||
vp_token, | ||
presentation_submission | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above
List of Changes
verifyTokenSignature
to dedicated method which is executed after getting Request Objectscope
.evaluateInputDescriptionForSdJwt4VC()
to enforce required/optional fields and validate JSON schema filters on disclosed claims.limit_disclosure
handling to restrict data revealed to only those fields explicitly required.sendAuthorizationResponse
flow with a new module that supports both direct post and encrypted direct post (JWT) response modes.Motivation and Context
These changes are specifically targeted for the Potential use case and some logic are been made in order to support also the Italian specification.
How Has This Been Tested?
Screenshots (if appropriate):
Checklist: