second attempt to add sd-jwt vcdm #147
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| @@ -1,13 +1,13 @@ | ||||||||||||||
| %%% | ||||||||||||||
| title = "OpenID4VC High Assurance Interoperability Profile - draft 03" | ||||||||||||||
| abbrev = "openid4vc-high-assurance-interoperability-profile" | ||||||||||||||
| ipr = "none" | ||||||||||||||
| workgroup = "Digital Credentials Protocols" | ||||||||||||||
| keyword = ["security", "openid4vc", "sd-jwt", "sd-jwt-vc", "mdoc"] | ||||||||||||||
|
|
||||||||||||||
| [seriesInfo] | ||||||||||||||
| name = "Internet-Draft" | ||||||||||||||
| value = "openid4vc-high-assurance-interoperability-profile-1_0-03" | ||||||||||||||
| status = "standard" | ||||||||||||||
|
|
||||||||||||||
| [[author]] | ||||||||||||||
| @@ -181,7 +181,6 @@ The following requirements apply for both, the Wallet and the Verifier, unless s | ||||||||||||||
| The JWE `enc` (encryption algorithm) header parameter (see [@!RFC7516, section 4.1.2]) value `A128GCM` (as defined in [@!RFC7518, section 5.3]) MUST be supported. | ||||||||||||||
| * The DCQL query and response as defined in Section 6 of [@!OIDF.OID4VP] MUST be used. Presentation Exchange as defined in Sections 5.4 and 5.5 of [@!OIDF.OID4VP] MUST NOT be used. | ||||||||||||||
|
|
||||||||||||||
| ## ISO mdoc specific requirements for OpenID for Verifiable Presentations over W3C Digital Credentials API | ||||||||||||||
|
|
||||||||||||||
| Requirements for both the Wallet and the Verifier: | ||||||||||||||
| @@ -255,6 +254,91 @@ Note: The issuer MAY decide to support both options. In which case, it is at the | ||||||||||||||
|
|
||||||||||||||
| A Credential Format Profile for Credentials complying with IETF SD-JWT VCs [@!I-D.ietf-oauth-sd-jwt-vc] is defined in Annex A.3 of [@!OIDF.OID4VCI] and Annex A.4 of [@!OIDF.OID4VP]. | ||||||||||||||
|
|
||||||||||||||
| ## SD-JWT VC Data Model (SD-JWT VCDM) | ||||||||||||||
|
|
||||||||||||||
| SD-JWT VCDM is a credential format that is compliant to IETF SD-JWT VC [@!I-D.ietf-oauth-sd-jwt-vc] that allows the usage of existing data structures represented using W3C VCDM [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0], while enabling selective disclosure. | ||||||||||||||
|
There was a problem hiding this comment. This, of course, doesn't strictly speak to the false cry of perpetuating claims that W3C VCDM does not support selective disclosure but might be more relatable to many readers.
Suggested change
There was a problem hiding this comment.
I don't think it's helpful to bring emotions into this thread. There is no "cry", and it is not "false" to simply observe that SD-JWT (VC(DM)) proponents have made false claims about selective disclosure in W3C VCDM. There was a problem hiding this comment. To try and be productive, I don't think this suggested change is helpful, since it still doesn't explain why SD-JWT VCDM is needed. If you want to enable "a consistent approach to selective disclosure", as this suggestion says, you can also just use plain SD-JWT with VCDM directly, without the SD-JWT VC extensions. Therefore I still think this introduction needs to explain somehow what this work adds to what's already out there. |
||||||||||||||
|
|
||||||||||||||
| SD-JWT VCDM credentials contain a data structure that can be processed using a JSON-LD processor after applying SD-JWT processing. | ||||||||||||||
|
|
||||||||||||||
| When IETF SD-JWT VC is mentioned in this specification, SD-JWT VCDM defined in this section MAY be used. | ||||||||||||||
|
|
||||||||||||||
| Implementaters of SD-JWT VCDM MUST use valid values for both `vct` Claim defined in IETF SD-JWT VC [@!I-D.ietf-oauth-sd-jwt-vc] and `type` proprty defined in W3C VCDM [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0]. | ||||||||||||||
|
There was a problem hiding this comment. Do they have to match or not? What happens if one client processes the Saying that "it's the responsibility of the issuer" is a bit naïve I think... There was a problem hiding this comment.
Suggested change
There was a problem hiding this comment.
Suggested change
There was a problem hiding this comment.
Suggested change
|
||||||||||||||
|
|
||||||||||||||
| For backward compatibility with JWT processors, the following registered JWT claims MUST be used, instead of their respective counterpart properties in W3C VCDM [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0]: | ||||||||||||||
|
|
||||||||||||||
| * To represent the validity period of SD-JWT VCDM (i.e., cryptographic signature), `exp`/`iat` Claims encoded as a UNIX timestamp (NumericDate) MUST be used, and not `expirationDate` and `issuanceDate` properties defined in [@!W3C.VCDM1.1], `validFrom` and `validTo` properties defined in [@!W3C.VCDM2.0]. | ||||||||||||||
|
There was a problem hiding this comment.
Suggested change
There was a problem hiding this comment. See:
It's conceivable that a mismatch here would prevent use cases where I issue a credential now, that becomes active a day from now. You could also say that for simplicity it is not possible to issue sd-jwt-vc with validity periods which exist in the future, and leave the current text, and resolve this comment. There was a problem hiding this comment. Could there be valid scenarios where Or is the idea that There was a problem hiding this comment. |
||||||||||||||
| * `iss` Claim MUST represent the identifier of the `issuer` property, i.e., the `issuer` property value if `issuer` is a String, or the `id` property of the `issuer` object if `issuer` is an object. `issuer` property MUST be ignored if present. | ||||||||||||||
| * `status` Claim MUST represent `credentialStatus` property. `credentialStatus` property MUST be ignored if present. | ||||||||||||||
| * `sub` Claim MUST represent the `id` property of `credentialSubject` property. `credentialSubject` property MUST be ignored if present. | ||||||||||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||||||||||
|
|
||||||||||||||
| IETF SD-JWT VC is extended with the following claims: | ||||||||||||||
|
|
||||||||||||||
| * `vcdm`: OPTIONAL. Contains properties defined in [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0] that are not represented by their counterpart JWT Claims as defined above. | ||||||||||||||
|
There was a problem hiding this comment. How is There was a problem hiding this comment. I recommend removing the "vcdm" if the governance of the data model is well defined. (see my question on how to express claims from different vocabularies) There was a problem hiding this comment. The There was a problem hiding this comment.
Isn't that exactly the same reason why you introduced There was a problem hiding this comment. I guess There was a problem hiding this comment. If implementations had issues There was a problem hiding this comment.
But @Sakurann said:
Wouldn't there be a lot of ambiguity and interop problems if you define two different JWT claims that can be used for the same purpose (VCDM 1.1)? There was a problem hiding this comment. I don't see how that would be a problem. The SD-JWT VC DM wrapper is new and has to be implemented anyway; any claim name would work. What is important is what is in the There was a problem hiding this comment.
So are you saying if an Issuer wants to use VCDM 1.1 wrapped inside a JWT, they could use either the There was a problem hiding this comment. I meant to say that we can define any claim name here, without much impact on implementations. Whether they process There may be a preference of one over the other for historic reasons, or because one has an existing IANA definition, or because one has clearer semantics, but other than that, it doesn't matter. There was a problem hiding this comment. Don't do this. Just let the claimset be defined as a JWT claimset. There was a problem hiding this comment. Agree with @OR13 , inserting one data model as a nested object inside another data model will lead to interop problems. |
||||||||||||||
|
|
||||||||||||||
Sakurann marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||
| The following outlines a suggested non-normative processing steps for SD-JWT VCDM: | ||||||||||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||||||||||
|
|
||||||||||||||
| 1. SD-JWT VC Processing: | ||||||||||||||
|
|
||||||||||||||
| - A receiver (holder or verifier) of an SD-JWT VCDM applies the processing rules outlined in Section 4 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc. | ||||||||||||||
| - If the `vct` value is associated with any SD-JWT VC Type Metadata, schema validation of the entire SD-JWT VCDM is performed, including the nested `vcdm` claim. | ||||||||||||||
|
There was a problem hiding this comment. Just say that when |
||||||||||||||
| - Additionally, trust framework rules are applied, such as ensuring the issuer is authorized to issue SD-JWT VCDMs for the specified `vct` value. | ||||||||||||||
|
|
||||||||||||||
| 2. Business Logic Processing: | ||||||||||||||
|
|
||||||||||||||
| - Once the SD-JWT VC is verified and trusted by the SD-JWT VC processor, and if the `vcdm` claim is present, the receiver extracts the VCDM (1.1 or 2.0) object from the `vcdm` claim and uses this for the business logic object. If the `vcdm` claim is not present, the entire SD-JWT VC is considered to represent the business logic object. | ||||||||||||||
| - The business logic object is then passed on for further use case-specific processing and validation. The business logic assumes that all security-critical functions (e.g., signature verification, trusted issuer) have already been performed during the previous step. Additional schema validation is applied if provided in the `vcdm` claim, e.g., to support SHACL schemas. Note that while a `vct` claim is required, SD-JWT VC type metadata resolution and related schema validation is optional in certain cases. | ||||||||||||||
|
|
||||||||||||||
| The following is a non-normative example of an unsecured payload of an SD-JWT VCDM, that is built using the example of unsecured payload in Section 3.3 of [@!I-D.ietf-oauth-sd-jwt-vc]: | ||||||||||||||
Sakurann marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||
|
|
||||||||||||||
| ```json | ||||||||||||||
| { | ||||||||||||||
| "vct": "https://credentials.example.com/identity_credential", | ||||||||||||||
| "vcdm": { //W3C VCDM 2.0 compliant claims | ||||||||||||||
|
There was a problem hiding this comment.
Suggested change
There was a problem hiding this comment. What does this mean for:
|
||||||||||||||
| "@context": ["https://www.w3.org/ns/credentials/v2"], | ||||||||||||||
| "type": ["VerifiableCredential", "https://credentials.example.com/identity_credential"], | ||||||||||||||
|
There was a problem hiding this comment. should be top level and relationship with vct must be explained There was a problem hiding this comment. There are various options, see above, but it seems that only one is reasonable. There was a problem hiding this comment. I disagree. See my question on data model governance: https://github.com/openid/oid4vc-haip/pull/147/files#r1922674086 There was a problem hiding this comment. I would remove the relationship between
Suggested change
There was a problem hiding this comment. This means you could have a situation where you request a driver's license on the OID4VP level, but then receive a VC with a type of birth certificate? There was a problem hiding this comment.
I always thought OID4VP supports different credential formats? Is it now getting more tightly coupled to SD-JWT VC? There was a problem hiding this comment.
@peacekeeper It is the issuer's responsibility to avoid nonsensical situations like this. If the issuer is trusted, I'd assume this not going to happen and they would make sure that There was a problem hiding this comment.
@peacekeeper It is not getting more tightly coupled. OID4VP does support any format. This PR is specifically about SD-JWT VCDM. Also note that this is the HAIP repository, not the OID4VP repository. There was a problem hiding this comment. The goal is to have the selective disclosure capabilities of SD-JWT VC, but re-use existing data structures in W3C VCDM format. See the modified intro text: "SD-JWT VCDM credentials contain a data structure that can be processed using a JSON-LD processor after applying SD-JWT processing." There was a problem hiding this comment.
Apart from the fact that VCDM already supports selective disclosure using Data Integrity proofs (no SD-JWT needed), it ALSO supports securing VCDM with SD-JWT directly (no SD-JWT VC needed). So why SD JWT VCDM? There was a problem hiding this comment.
If you asked me personally, one major advantage is that no JSON-LD is required whereas VCDM 2.0 requires the payload to be a valid JSON-LD object in compact form. It has more overhead and the idea is that while this should stay possible, it shouldn't be required. SD-JWT VCDM would allow for this. There was a problem hiding this comment. @peacekeeper because SD-JWT VC does not cover several subjects like microcredentials, references to external formats. On other hand Selective Disclosure much easier as well as the subjects Olivermentioned. That's why SD-JWT VCDM needed. Also in context eIDAS. Recommend to focus on technical subjects here There was a problem hiding this comment.
Hence, I propose to remove the "VCDM" claim and the double-processing rules as it is creating confusion and repeating the error from the past. |
||||||||||||||
| "credentialSubject": { | ||||||||||||||
| "given_name": "John", | ||||||||||||||
| "family_name": "Doe", | ||||||||||||||
|
There was a problem hiding this comment. these terms are not defined in https://www.w3.org/ns/credentials/v2, so you either need to add another context to the top level, or leave them defined like this to highlight that the RDF part of JSON-LD rarely works. The "correct" way to fix this is to put a second context in the claimset which you are intending to be well formed JSON-LD, like this: or |
||||||||||||||
| "email": "[email protected]", | ||||||||||||||
| "phone_number": "+1-202-555-0101", | ||||||||||||||
| "address": { | ||||||||||||||
| "street_address": "123 Main St", | ||||||||||||||
| "locality": "Anytown", | ||||||||||||||
| "region": "Anystate", | ||||||||||||||
| "country": "US" | ||||||||||||||
| }, | ||||||||||||||
| "birthdate": "1940-01-01", | ||||||||||||||
| "is_over_18": true, | ||||||||||||||
| "is_over_21": true, | ||||||||||||||
| "is_over_65": true | ||||||||||||||
| } | ||||||||||||||
| } | ||||||||||||||
| } | ||||||||||||||
| ``` | ||||||||||||||
|
|
||||||||||||||
| The following is a non-normative example of how an unsecured payload of an SD-JWT VCDM above can be used for the SD-JWT: | ||||||||||||||
|
There was a problem hiding this comment. Still not sure this sentience makes sense but the "an"s here weren't helping.
Suggested change
There was a problem hiding this comment. I think this sentence is trying to say: The following is a non-normative example of how to secure "application/vc" with "application/dc+sd-jwt": |
||||||||||||||
|
|
||||||||||||||
| ```json | ||||||||||||||
| { | ||||||||||||||
| "_sd": [ | ||||||||||||||
| "vwUhdFvpylx9Sqi2YNBV1dfVK6lCbhXvkH0nThfKFT0" | ||||||||||||||
|
There was a problem hiding this comment. I realize it's just a "a non-normative example" but to my naïve little mind this implies that the |
||||||||||||||
| ], | ||||||||||||||
| "iss": "https://example.com/issuer", | ||||||||||||||
| "iat": 1683000000, | ||||||||||||||
| "exp": 1883000000, | ||||||||||||||
| "vct": "https://credentials.example.com/identity_credential", | ||||||||||||||
| "_sd_alg": "sha-256", | ||||||||||||||
| "cnf": { | ||||||||||||||
| "jwk": { | ||||||||||||||
| "kty": "EC", | ||||||||||||||
| "crv": "P-256", | ||||||||||||||
| "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", | ||||||||||||||
| "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" | ||||||||||||||
| } | ||||||||||||||
| } | ||||||||||||||
| } | ||||||||||||||
| ``` | ||||||||||||||
|
|
||||||||||||||
| # Crypto Suites | ||||||||||||||
Sakurann marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||
|
|
||||||||||||||
| Issuers, holders and verifiers MUST support P-256 (secp256r1) as a key type with ES256 JWT algorithm for signing and signature validation whenever this profiles requires to do so: | ||||||||||||||
| @@ -398,19 +482,23 @@ Note: When using this profile with other cryptosuites, it is recommended to be e | ||||||||||||||
| </front> | ||||||||||||||
| </reference> | ||||||||||||||
|
|
||||||||||||||
| <reference anchor="W3C.VCDM2.0" target="https://www.w3.org/TR/2025/CRD-vc-data-model-2.0-20250127/"> | ||||||||||||||
| <front> | ||||||||||||||
| <title>Verifiable Credentials Data Model v2.0</title> | ||||||||||||||
| <author fullname="Manu Sporny"/> | ||||||||||||||
| <author fullname="Dave Longley"/> | ||||||||||||||
| <author fullname="David Chadwick"/> | ||||||||||||||
| <date day="27" month="January" year="2025"/> | ||||||||||||||
| </front> | ||||||||||||||
| </reference> | ||||||||||||||
|
|
||||||||||||||
| <reference anchor="W3C.VCDM1.1" target="https://www.w3.org/TR/vc-data-model-1.1/"> | ||||||||||||||
| <front> | ||||||||||||||
| <title>Verifiable Credentials Data Model v1.1</title> | ||||||||||||||
| <author fullname="Manu Sporny"/> | ||||||||||||||
| <author fullname="Dave Longley"/> | ||||||||||||||
| <author fullname="David Chadwick"/> | ||||||||||||||
| <date day="3" month="March" year="2022"/> | ||||||||||||||
| </front> | ||||||||||||||
| </reference> | ||||||||||||||
|
|
||||||||||||||
| @@ -434,6 +522,10 @@ The technology described in this specification was made available from contribut | ||||||||||||||
|
|
||||||||||||||
| [[ To be removed from the final specification ]] | ||||||||||||||
|
|
||||||||||||||
| -03 | ||||||||||||||
|
|
||||||||||||||
| * Add SD-JWT VCDM | ||||||||||||||
|
|
||||||||||||||
| -02 | ||||||||||||||
|
|
||||||||||||||
| * Mandate DCQL instead of presentation exchange | ||||||||||||||
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.
Please change this sentence. While admittedly not strictly untrue, to most readers, this paragraph will only perpetuate the false claim that W3C VCDM does not support selective disclosure, which has been spread at various conferences and communities in the last years. The claim that SD-JWT VCDM is needed to do SIMPLE selective disclosure with W3C VCDM is equally untrue, as you can also just use plain SD-JWT if you really want. The introduction should explain this to avoid risk of further confusion and deception.