-
Notifications
You must be signed in to change notification settings - Fork 10
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/jwt status list #225
Feat/jwt status list #225
Conversation
…s#224 Signed-off-by: Mirko Mollik <mollik@trustcerts.de>
Signed-off-by: Mirko Mollik <mollik@trustcerts.de>
Should this instead be using https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/? That's the replacement of JWT / CWT status list i believe. |
It was built on the referenced IETF. I also opened a PR in the sd-jwt-vc spec since it was pointing to the wrong file |
Signed-off-by: Mirko Mollik <mirko.mollik@fit.fraunhofer.de>
Signed-off-by: Mirko Mollik <mirko.mollik@fit.fraunhofer.de>
@berendsliedrecht @TimoGlastra To make a clean PR, how should we proceed? Merge this PR and then open another to transfer the Lib directly into the repo. Or do all in one step? I would prefer the first option since it makes a cleaner cut between the two tasks |
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.
Nice work @cre8, we were intending to start work on this later this month, and left some comments based on how we wanted to approach it
Co-authored-by: Timo Glastra <timo@animo.id> Signed-off-by: Mirko Mollik <mirkomollik@gmail.com>
Signed-off-by: Mirko Mollik <mirko.mollik@fit.fraunhofer.de>
Signed-off-by: Mirko Mollik <mirko.mollik@fit.fraunhofer.de>
… feat/jwt-status-list Signed-off-by: Mirko Mollik <mirko.mollik@fit.fraunhofer.de>
Signed-off-by: Mirko Mollik <mirko.mollik@fit.fraunhofer.de>
Signed-off-by: Mirko Mollik <mirko.mollik@fit.fraunhofer.de>
First option is fine for me. |
Well, too late :D |
Signed-off-by: Mirko Mollik <mirko.mollik@fit.fraunhofer.de>
Signed-off-by: Mirko Mollik <mollik@trustcerts.de>
Signed-off-by: Mirko Mollik <mollik@trustcerts.de>
Signed-off-by: Mirko Mollik <mollik@trustcerts.de>
Signed-off-by: Mirko Mollik <mollik@trustcerts.de>
Co-authored-by: Timo Glastra <timo@animo.id> Signed-off-by: Mirko Mollik <mirkomollik@gmail.com>
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.
Really nice work @cre8. LGTM ✅
I'm going to implement this into Credo directly, and will let you know if I encounter any issues
Signed-off-by: Mirko Mollik <mirko.mollik@fit.fraunhofer.de>
Co-authored-by: Timo Glastra <timo@animo.id> Signed-off-by: Mirko Mollik <mirkomollik@gmail.com>
@TimoGlastra new version |
closes #224
I extended the verify method so all checked that should be done via sd-jwt are called and then we are looking for revocation.
We will only check the revocation if the
status
field is present. We are not throwing an error if somebody has referenced another status mechanism and we are not validating if the status field was correctly placed inside the payload when the credential is created (but types are provided).The verifier has to implement the fetch and validation function of the jwt-status-token and also the logic how to deal with the status (it can have multiple definitions but the values are not covered by the spec).
The statusValidator function is to stop the current validation. In case the status has a value to continue, the function executes without throwing an error and the verifier has to deal with the state after the successful verification.