-
Notifications
You must be signed in to change notification settings - Fork 200
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(w3cCredentials)!: add jwt vc support #1468
feat(w3cCredentials)!: add jwt vc support #1468
Conversation
} | ||
|
||
public static fromSerializedJwt(serializedJwt: string) { | ||
if (typeof serializedJwt !== 'string' || !Jwt.format.test(serializedJwt)) { |
Check failure
Code scanning / CodeQL
Polynomial regular expression used on uncontrolled data
Codecov Report
@@ Coverage Diff @@
## main #1468 +/- ##
===========================================
- Coverage 85.84% 72.59% -13.25%
===========================================
Files 912 882 -30
Lines 21759 21338 -421
Branches 3727 3712 -15
===========================================
- Hits 18679 15491 -3188
- Misses 2901 5428 +2527
- Partials 179 419 +240
|
Awesome stuff, Timo. Any thought to how AnonCreds in W3C format could use this? Would it be a matter of adding an “algo” for AnonCreds and a corresponding handler? My expectation is that anoncreds-rs could detect W3C format AnonCreds objects as needed and convert internally, and on creation, be passed a flag to indicate the generated objects be converted to W3C form when needed. Do you see that as possible? |
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.
Great PR! I see a lot of manual validation is happening. Is this something we might be able to extract into a non-AFJ library which can be used by anyone, also non AFJ-projects.
|
||
/** | ||
* Base64url encoded protected header | ||
*/ | ||
protected: 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.
I assume it is common JWS/JWT practise, but can we not call this protectedHeader
? Might be easier to understand.
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.
This is a direct mapping of the format as used by the specification. In other places we call it protectedHeader
, but if we change this, the JWS service will create invalid JWSes.
* is performed against current time (`now`), the validation can be of by the skew | ||
* time. | ||
*/ | ||
const DEFAULT_SKEW_TIME = 300 |
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.
Is this something that can be changed by the user?
Also, might be good to reference: https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5
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.
They can't change the value of this constant. But everywhere this constant is used, the user can provide a custom skew time value. (so this is only used if the user didn't provide a value)
packages/core/src/modules/vc/data-integrity/models/W3cJsonLdVerifiableCredential.ts
Outdated
Show resolved
Hide resolved
packages/core/src/modules/vc/models/credential/W3cVerifiableCredential.ts
Show resolved
Hide resolved
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.
Great PR! I see a lot of manual validation is happening. Is this something we might be able to extract into a non-AFJ library which can be used by anyone, also non AFJ-projects.
Signed-off-by: Timo Glastra <[email protected]>
Signed-off-by: Timo Glastra <[email protected]>
Yeah I think we can definitely extract the JWT-VC part to a separate library. Only thing is that we would need to replace the class-transformer/class-validator parts with something else |
Signed-off-by: Timo Glastra <[email protected]>
@swcurran, for this specific addition that wouldn't be possible as this just focuses on JWT credentials using Json Web Signatures. For the AnonCreds mapping we need a custom But for JSON-LD credentials that would exactly how it would work yes, We can add a signature suite called |
let payload: string | ||
|
||
if (typeof jws === 'string') { | ||
if (!JWS_COMPACT_FORMAT_MATCHER.test(jws)) |
Check failure
Code scanning / CodeQL
Polynomial regular expression used on uncontrolled data
Signed-off-by: Timo Glastra <[email protected]>
Adds support for JWT VCs in addition to the already supported JSON-LD VCs.
It became a bigger PR than anticipated, mainly because I moved some files around and made some changes to e.g. how verification methods are handled so they can be used without JSON-LD as well.
The PR has extracted the JSON-LD specific functionality from the
W3cCredentialService
into a newW3cJsonLdCredentialService
, and we've got a newW3cJwtCredentialService
. The general w3c credential service exposes a generic api to work with both, while the specific classes implement the logic. Records are only handled through the general w3c credential service. The idea is that users will mostly use the W3cCredentialService, and not the underlying imlementations, that is more to split up logic based on format.The API has changed to now require a format when signing credentials / presentations:
For the verification the API has also changed to support a more rich API. This rich API has been fully implemented for JWT VCs, but could not be fully supported for JSON-LD library due to the way errors are thrown in that library (see #1466, this will be addressed in a follow up pr).
The idea for the results is that now everything is handled by a custom validation object that has the following structure. The specific validations differ a bit between a VC and VP, but the idea is the same.
For now, for JSON-LD verifications the result looks like this. This means the same data is available before this PR (the VC.js structure was followed), but a bit more nested. Over time we want to remove the use of vc.js and use the same structure as above for both credential formats. This allows for fine grained control over what you want to validate.