-
Notifications
You must be signed in to change notification settings - Fork 13
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
Add sd-jwt example #114
Add sd-jwt example #114
Conversation
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.
We should explicitly note that this is a work in progress draft that may change.
Very useful example though
Co-authored-by: Mike Prorock <mprorock@users.noreply.github.com>
@mprorock I applied your suggestions, please re-review. |
@@ -969,6 +978,50 @@ <h2> | |||
<p class="issue">TODO add COSE Sign1 detached payload examples</p> | |||
|
|||
</section> | |||
<section> | |||
<h3>Selective Disclosure</h3> |
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 found this title rather confusing.
Perhaps we could rename it?
My understanding is that it's a VC that is derived from an SD-JWT.
<h3>Selective Disclosure</h3> | |
<h3>Credential derived from SD-JWT</h3> |
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.
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.
@andresuribe87 I've added additional context, based on the other PR feedback we received, perhaps its clearer now? in the case that you feel it is not, is your suggestion here blocking?
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.
Yeah much clearer now. Thanks @OR13 !
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.
The example does not contain _sd claims, it's not taken from SD-JWT, what's the purpose?
Somewhat naively I would have expected an "sd-jwt example" to be an example showing the SD-JWT mechanisms applied to some VCDM conforming JSON. Or something like that. But other than a stray |
Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>
@Sakurann @bc-pi The goal here is to convey that this W3C work item recognizes that your IETF draft can secure However, I can add a complete example of all the SD-JWT bits that are not |
For reference, here is where the example was taken from: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-04#name-example-4b-w3c-verifiable-c {
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://w3id.org/vaccination/v1"
],
"type": [
"VerifiableCredential",
"VaccinationCertificate"
],
"issuer": "https://example.com/issuer",
"issuanceDate": "2023-02-09T11:01:59Z",
"expirationDate": "2028-02-08T11:01:59Z",
"name": "COVID-19 Vaccination Certificate",
"description": "COVID-19 Vaccination Certificate",
"credentialSubject": {
"vaccine": {
"type": "Vaccine",
"medicinalProductName": "COVID-19 Vaccine Moderna",
"atcCode": "J07BX03"
},
"recipient": {
"type": "VaccineRecipient"
},
"type": "VaccinationEvent",
"order": "3/3",
"dateOfVaccination": "2021-06-23T13:40:12Z"
},
"_sd_alg": "sha-256",
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
}
}
} |
That is input claim set before all the sd-jwt processing is applied, the actual sd-jwt payload is the example after the one you used, with an _sd claim. https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-05.html#appendix-A.4-7 |
@Sakurann hmm, I don't want to comment on "input" and "mapping"... I just want to say that the verifier ends with something that can be processed as I'm ok adding more examples that are not From the section you referenced above: This is identical to how "after the validation" for "vc+ld+jwt", the verifier has a JSON (LD) payload that can be further processed. |
Maybe just say that in text and link to https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-05.html#appendix-A.4 for readers that want to see an example? |
@bc-pi are you requesting that no JSON-LD example of the final SD-JWT validated / verified form be included in this spec? Is this a blocking change request? |
@OR13 it was not meant to be adversarial or blocking. I think that an JSON-LD example of the final SD-JWT form on its own without context or explanation isn't particularly useful (and maybe confusing to some). Stating what you said previously here, that verifier ends up with something after consuming the SD-JWT that can be processed as vc+ld+json is helpful and should probably be in this PR. Beyond that I was suggesting that maybe rather than pulling in parts of https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-05.html#appendix-A.4 you could just reference it or link to it. |
Yes, I agree with this, but I chose the simple PR first, because its easier to add then it is to remove. I am trying to understand what changes to apply, which is why I ask if its blocking... @Sakurann has requested changes, but not clarified, so I cannot implement her feedback.
@Sakurann ^ If I implement these changes, will you approve? Can you clarify what changes you would like to see.
I am already referencing it, I think it's better to reference it and copy the example, so that readers are not required to navigate in order to see an example. |
Sorry it was not clear what changes I was requesting. I would suggest either a) directly put the URL to the JSON-LD example in the SD-JWT spec with some explanation text, but without copying any payload example, or b) copying the payload of the Issuer-Signed JWT with _sd array (to illustrate what is the out put after sd-jwt processing is applied to vc+ld+jwt input claimset) and add that "this results in a valid vc+ld+jwt payload, for details see ". I agree that copying input claimset (pretty much vc+ld+jwt as-is) does not illustrate anything specific to sd-jwt and can be confusing. |
@Sakurann thanks, I will take path B. I think it's important for folks to understand that the verification process for both In the case of As an aside, related to the sentence above, you can't refer to the I think its very important that sd-jwt follow the JWT BCP, and use |
Maybe cty can be used... but I suspect that will be more confusing than not using it. |
If approach analogous to what was taken for vc+sd-jwt is to be taken, only vc+ld+sd-jwt would be sufficient. And the only difference from the current approach of having two media types will be that even when there is no selective disclosure, there is a ~ in the end of a JWS, but after that ~ is removed, usual JWT libraries can be used. |
@Sakurann @bc-pi I tried to implement your feedback. I copied several examples from the section on conformance to W3C Verifiable Credentials in JSON-LD, and I added text that can be aligned with the term definitions of the core data model, for example regarding issuer, holder and verifier. Please let me know if there are any further change requests, what you would like to see. |
Preview | Diff