second attempt to add sd-jwt vcdm #147

Sakurann · 2024-12-19T17:31:20Z

resolves #128

intended as an altenative that supercedes #134

todo:

[] provide more details on the processing steps advisory (@awoie )
[] clean up the examples according to that (Kristina)

alenhorvat · 2024-12-19T17:56:27Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+{
+  "vct": "https://credentials.example.com/identity_credential",
+  //W3C VCDM 2.0 compliant claims
+  "vcdm": {


per https://github.com/openid/oid4vc-haip/pull/147/files#r1915527670

resolving since discussion is continuing in another thread

alenhorvat · 2024-12-19T17:56:55Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+  //W3C VCDM 2.0 compliant claims
+  "vcdm": {
+    "@context": ["https://www.w3.org/ns/credentials/v2"],
+    "type": ["VerifiableCredential", "https://credentials.example.com/identity_credential"],


should be top level and relationship with vct must be explained

There are various options, see above, but it seems that only one is reasonable.

I disagree. See my question on data model governance: https://github.com/openid/oid4vc-haip/pull/147/files#r1922674086

openid4vc-high-assurance-interoperability-profile-1_0.md

Sakurann · 2025-01-14T19:54:40Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+
+SD-JWT VCDM is a data model that follows IETF SD-JWT VC [@!I-D.ietf-oauth-sd-jwt-vc], but allows the usage of [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0]. When IETF SD-JWT VC is mentioned in this specification, SD-JWT VCDM define in this section MAY be used.
+
+For backward compatibility with JWT processors, the following registered JWT claims MUST be used, instead of their respective counterpart properties in [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0]:


need to add a paragraph on vct claim and type property

option 1: keep completely independent. implementations need to define both - easiest to request via DCQL even if harder for the issuers.
option 2: redefine sd-jwt vc to make vct optional - would impact the rest of sd-jwt vc implementations
option 3: static vct for this case - makes it impossible to request using DCQL
option 4: define how to determine a vct value based on type values - hard to define

based on the discussion with @c2bo @danielfett @awoie @bc-pi choosing option 1.

The data model should not be impacted by DCQL. If it is, there's an issue in the design and should be resolved.

added this:
Implementaters of SD-JWT VCDM MUST use valid values for both vctClaim defined in IETF SD-JWT VC [@!I-D.ietf-oauth-sd-jwt-vc] andtype proprty defined in W3C VCDM [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0].

openid4vc-high-assurance-interoperability-profile-1_0.md

peacekeeper · 2025-01-16T19:15:06Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+
+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.


How is "vcdm" different from the good old "vc" claim?

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)

The vcdm claim is there to allow JSON-LD processors to process the vcdm object which has to be a valid JSON-LD object in compact form. Some JSON-LD processors would have issues with terms that are not included in a context definition. There might be some SD-JWT and SD-JWT VC claims today or in the future that are not included and therefore cause issues. By encapsulating the JSON-LD stuff within vcdm, we guarantee this won't cause any issues. See my processing model suggestions https://github.com/openid/oid4vc-haip/pull/147/files#r1922554997.

By encapsulating the JSON-LD stuff within vcdm

Isn't that exactly the same reason why you introduced vc a few years ago? Why not re-use that?

I guess vc would be fine, but it is an IANA-registered claim that's defined for use in a different context. Might be okay to re-use though. vcdm would make it clear that this claim is to be used with the processing model in mind that @awoie describes in one of the other suggested changes.

If implementations had issues
a) what are the issues?
b) can we contact them and learn more about the issues?

I think vc won't be used. It would be "vcdm": { VCDM 1.1 or VCDM 2.0 stuff }.

But @Sakurann said:

IANA reserved vc for w3c vcdm 1.1

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)?

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 vcdm claim.

any claim name would work

So are you saying if an Issuer wants to use VCDM 1.1 wrapped inside a JWT, they could use either the vc or vcdm claim, since both serve the same purpose? And would Verifiers also be expected to support both? Or pick one of the two?

I meant to say that we can define any claim name here, without much impact on implementations. Whether they process vcdm, vc or foo doesn't matter. Of course we need to settle on one.

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.

openid4vc-high-assurance-interoperability-profile-1_0.md

awoie · 2025-01-20T17:16:31Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+  //W3C VCDM 2.0 compliant claims
+  "vcdm": {
+    "@context": ["https://www.w3.org/ns/credentials/v2"],
+    "type": ["VerifiableCredential", "https://credentials.example.com/identity_credential"],


I would remove the relationship between vct and type. We should acknowledge that the typing can be different. I assume that JSON-LD processors want their JSON-LD type system. To guarantee interop on the protocol level, e.g., query credentials in OID4VP, the vct value has to be used.

Suggested change

"type": ["VerifiableCredential", "https://credentials.example.com/identity_credential"],

"type": ["VerifiableCredential", "IdentityCredential"],

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?

To guarantee interop on the protocol level, e.g., query credentials in OID4VP, the vct value has to be used.

I always thought OID4VP supports different credential formats? Is it now getting more tightly coupled to SD-JWT VC?

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?

@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 vct value and business logic object would align. For instance, this could be done via vct Type Metadata where the Type Metadata would say that for a given vct value the type property has to have certain values as well.

I always thought OID4VP supports different credential formats? Is it now getting more tightly coupled to SD-JWT VC?

@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.

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."

The goal is to have the selective disclosure capabilities of SD-JWT VC, but re-use existing data structures in W3C VCDM format.

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?

So why SD JWT VCDM

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.

@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

base data format is JSON

if use cases want to use JSON-LD, JSON-LD should cover all the definitions needed to successfully process the data model (again, depending on for what purpose JSON-LD is used)

JSON-LD context MUST be treated as any referenced content in the data model (integrity protection, ability to share the data as unsigned payload); See related discussion: Data Integrity -> external resources w3c/vc-data-integrity#323 (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.

openid4vc-high-assurance-interoperability-profile-1_0.md

… clarify that the verifier has a choice

peacekeeper · 2025-01-28T12:30:06Z

openid4vc-high-assurance-interoperability-profile-1_0.md


 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.

-For backward compatibility with JWT processors, the following registered JWT claims MUST be used, instead of their respective counterpart properties in [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0]:
+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].


Do they have to match or not? What happens if one client processes the vct claim, and another processes the type claim, and they arrive at different conclusions? To me it sounds like a huge source of ambiguity and potential problems if a data model contains basically the same concept twice ("type of a Verifiable Credential"). Especially if not only the values can be different, but also the way how the values are being expressed is different.

Saying that "it's the responsibility of the issuer" is a bit naïve I think...

peacekeeper · 2025-01-28T12:53:14Z

openid4vc-high-assurance-interoperability-profile-1_0.md

@@ -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.


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.

openid4vc-high-assurance-interoperability-profile-1_0.md

…enid-specs-digital-credentials-protocols/Week-of-Mon-20250127/000628.html

bc-pi · 2025-01-28T20:09:10Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+
+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].


Suggested change

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].

Implementers 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` property defined in W3C VCDM [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0].

bc-pi · 2025-01-29T16:11:17Z

openid4vc-high-assurance-interoperability-profile-1_0.md

@@ -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.


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

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.

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 a consistent approach to selective disclosure.

false cry

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.

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.

bc-pi · 2025-01-29T16:16:28Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+```json
+{
+  "vct": "https://credentials.example.com/identity_credential",
+  "vcdm": {    //W3C VCDM 2.0 compliant claims


Suggested change

"vcdm": { //W3C VCDM 2.0 compliant claims

"vcdm": { //W3C VCDM 2.0 or 1.1 compliant claims

What does this mean for:

IANA reserved vc for w3c vcdm 1.1

bc-pi · 2025-01-29T16:20:49Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+}
+```
+
+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:


Still not sure this sentience makes sense but the "an"s here weren't helping.

Suggested change

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:

The following is a non-normative example of how the unsecured payload of the SD-JWT VCDM above can be used for the SD-JWT:

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":

bc-pi · 2025-01-29T16:25:38Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+```json
+{
+  "_sd": [
+    "vwUhdFvpylx9Sqi2YNBV1dfVK6lCbhXvkH0nThfKFT0"


I realize it's just a "a non-normative example" but to my naïve little mind this implies that the vcdm claim is the only thing made selectively disclosable. And that doesn't make much sense to me.

TimoGlastra · 2025-01-29T16:52:31Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+
+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].


Suggested change

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].

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` property defined in W3C VCDM [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0].

TimoGlastra · 2025-01-29T16:54:47Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+
+* `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.
+
+The following outlines a suggested non-normative processing steps for SD-JWT VCDM:


Suggested change

The following outlines a suggested non-normative processing steps for SD-JWT VCDM:

The following outlines a suggested non-normative set of processing steps for SD-JWT VCDM:

peacekeeper · 2025-01-30T11:06:34Z

Since there are discussions about the relationship between the vc and vcdm claims, I also wonder what all of this means for the vp claim?

Does SD-JWT VCDM support Verifiable Presentations?

awoie · 2025-01-30T12:23:45Z

Since there are discussions about the relationship between the vc and vcdm claims, I also wonder what all of this means for the vp claim?

Does SD-JWT VCDM support Verifiable Presentations?

IMO, the vp claim is out of scope for this work and highly unlikely to be used. The VP, as defined in the W3C VCDM 2.0 for SD-JWT, is a fascinatingly unnecessary construct with a purpose that remains a mystery. For those who haven't had the pleasure, it's a JSON-LD object that wraps a base64url-encoded SD-JWT—for reasons that are, at best, questionable. Because VPs refer to the protocol layer, the SD-JWT (VC) representation should be used instead.

peacekeeper · 2025-02-03T11:51:29Z

JSON-LD object that wraps a base64url-encoded SD-JWT

That sounds pretty useless indeed, where is that defined? :)

But I was asking about Verifiable Presentations in general, I assume you wouldn't consider those an "unnecessary construct"? There are many projects and applications that use Verifiable Presentations. The Verifiable Credentials Data Model defines BOTH Verifiable Credentials and Verifiable Presentations.

Would it be correct to say that SD-JWT VC DM only supports the Verifiable Credentials part, but not the Verifiable Presentations part?

filip26 · 2025-02-03T18:46:33Z

IMO, the vp claim is out of scope for this work and highly unlikely to be used. The VP, as defined in the W3C VCDM 2.0 for SD-JWT, is a fascinatingly unnecessary construct with a purpose that remains a mystery.

With all due respect, this is yet another unnecessary false claim. We should avoid such statements, as they detract from the quality of the discussion and tend to favor those who shout the loudest over those who present reasoned arguments.

The W3C VP enables the combination of multiple credentials into a single presentation, which is signed by the holder and then presented to a verifier. This mechanism plays a critical role in the interaction between the holder and the verifier.

As an independent open-source engineer and a European - directly affected by these issues - it's disheartening to see critical technologies being discussed in this manner, where valid points are diminished by false claims and dismissive rhetoric.

awoie · 2025-02-05T12:59:56Z

IMO, the vp claim is out of scope for this work and highly unlikely to be used. The VP, as defined in the W3C VCDM 2.0 for SD-JWT, is a fascinatingly unnecessary construct with a purpose that remains a mystery.

With all due respect, this is yet another unnecessary false claim. We should avoid such statements, as they detract from the quality of the discussion and tend to favor those who shout the loudest over those who present reasoned arguments.

The W3C VP enables the combination of multiple credentials into a single presentation, which is signed by the holder and then presented to a verifier. This mechanism plays a critical role in the interaction between the holder and the verifier.

As an independent open-source engineer and a European - directly affected by these issues - it's disheartening to see critical technologies being discussed in this manner, where valid points are diminished by false claims and dismissive rhetoric.

The reason this is unnecessary in this context (OID4VP as a transmission protocol) is something I should have explained better—my apologies for that. While it has some value when combined with Data Integrity Proofs, it does not add any value when used with COSE/JOSE/SD-JWT. Here’s why:

The W3C VCDM 2.0 defines EnvelopedVerifiablePresentation and EnvelopedVerifiableCredential as envelopes for credentials and presentations when using COSE/JOSE/SD-JWT as the security mechanism. Both of these objects are JSON-LD structures, but any additional properties (or claims, in JOSE terms) added to them would remain unsigned, since the signature is encapsulated within the base64url-encoded blob inside the envelope.

Example: `EnvelopedVerifiableCredential` object using SD-JWT:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": "VerifiablePresentation",
  "verifiableCredential": [{
    "@context": "https://www.w3.org/ns/credentials/v2",
    "type": "EnvelopedVerifiableCredential",
    "id": "data:application/vc+sd-jwt,eyJra...~"
  }]
}

Example: `EnvelopedVerifiablePresentation` object using SD-JWT:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": "EnvelopedVerifiablePresentation",
  "id": "data:application/vp+sd-jwt,eyJhbGc...~"
}

Why This Adds No Value:

Unsigned Data is Meaningless

Any new properties added to EnvelopedVerifiablePresentation or EnvelopedVerifiableCredential remain unsigned and therefore lack cryptographic integrity.
In practice, this information is already conveyed at the protocol level (OID4VP), making its inclusion redundant.

Incompatibility with OID4VP Query Mechanisms

The W3C VCDM VP object is not a suitable container for multiple SD-JWT presentations because OID4VP has the vp_token for this.
It would break compatibility with query languages already defined in OID4VP, leading to unnecessary complexity without added benefit.

I hope this explanation makes more sense now, and I apologize if my previous articulation was unclear. Let me know if you have any further questions!

peacekeeper · 2025-02-05T14:00:58Z

I fully agree "EnvelopedVerifiableCredential" and "EnvelopedVerifiablePresentation" are "fascinatingly unnecessary constructs with a purpose that remains a mystery".

The same is true for this SD-JWT VCDM work.

In both cases, two incompatible data models are being mixed up in a complicated way, without any clear explanation other than "people want it".

OR13 · 2025-02-07T21:31:28Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+
+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].


Suggested change

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].

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` property defined in W3C VCDM [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0].

OR13 · 2025-02-07T21:33:29Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+
+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].


Suggested change

* 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].

* To represent the validity period of SD-JWT VCDM (i.e., cryptographic signature), `exp`/`nbf` 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].

See:

https://www.rfc-editor.org/rfc/rfc7519.html#section-4.1.5

https://www.w3.org/TR/vc-data-model-2.0/#validity-period

iat is the time the token is issued, not the time at which the token is to be considered valid.

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.

Could there be valid scenarios where exp, iat, nbf, validFrom, validTo all have different values?

Or is the idea that validFrom, validTo are ignored, just like this PR also proposes to ignore other VC properties?

related eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework#160 (comment)

OR13 · 2025-02-07T21:40:47Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+* 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].
+* `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.


Suggested change

* `sub` Claim MUST represent the `id` property of `credentialSubject` property. `credentialSubject` property MUST be ignored if present.

* `sub` Claim MUST represent the `id` property of `credentialSubject` property. `credentialSubject` property MUST be ignored if present. There is no support for the case where `credentialSubject` is an array.

OR13 · 2025-02-07T21:43:36Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+
+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.


Don't do this.

Just let the claimset be defined as a JWT claimset.
And allow any properties that are not understood to be ignored.
Do not introduce a nested object, it breaks compatibility with the TR defined here:

https://www.w3.org/TR/vc-jose-cose/#securing-with-sd-jwt

Agree with @OR13 , inserting one data model as a nested object inside another data model will lead to interop problems.

OR13 · 2025-02-07T21:45:32Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+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.


Just say that when vct is present it overrides any application profile type specific processing that might have been implied by type as described in https://www.w3.org/TR/vc-data-model-2.0/#types

OR13 · 2025-02-07T21:48:32Z

openid4vc-high-assurance-interoperability-profile-1_0.md

+    "type": ["VerifiableCredential", "https://credentials.example.com/identity_credential"],
+    "credentialSubject": {
+      "given_name": "John",
+      "family_name": "Doe",


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:

"@context": [ "https://www.w3.org/ns/credentials/v2", "https://credentials.example.com/ns/credentials/examples/v2" ],

or

"@context": [ "https://www.w3.org/ns/credentials/v2", { "@vocab": "https://schema.org/" } ],

For example: https://github.com/schemaorg/schemaorg/blob/9aa7bd2b51717bceb825a3ef551fca89016e1e1f/data/sdo-soso-dataset-examples.txt#L22

OR13

Drop the "vcdm" claim... Or... use the existing "vc" claim which at one point was planned to be deprecated, and now its unclear how it would relate to this PR... I filled w3c/vc-jose-cose#329

selfissued

@leecam commented during today's working group call that anything we put in HAIP effectively creates implementation requirements for all ecosystem participants. Therefore, there should be a high bar for deciding to add things to HAIP. I agree.

Personally, I don't think that creating an implementation requirement for VCDM 1.1 would be a step forward. I'd therefore prefer not to add this.

steffenschwalm · 2025-02-13T17:58:04Z

@leecam commented during today's working group call that anything we put in HAIP effectively creates implementation requirements for all ecosystem participants. Therefore, there should be a high bar for deciding to add things to HAIP. I agree.

Personally, I don't think that creating an implementation requirement for VCDM 1.1 would be a step forward. I'd therefore prefer not to add this.

As long as HAIP should be used in eIDAS Framework the SD-JWT VCDM is essential in order to achieve legal compliance and interoperability with existing ecosystems and standardization framework. But as it´s focused on Europe maybe it might be better to shift the standardization work on this subject to European standardization body to avoid affects for non-European parties.
@tlodderstedt

David-Chadwick · 2025-02-14T15:38:56Z

@selfissued Presumably you comment does not apply to VCDM 2.0? (which is why I gave it a thumbs up)

second attempt to add sd-jwt vcdm

faa61c1

Sakurann requested review from danielfett, c2bo, awoie and bc-pi December 19, 2024 17:31

Sakurann marked this pull request as ready for review December 19, 2024 17:31

alenhorvat reviewed Dec 19, 2024

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

alenhorvat reviewed Dec 19, 2024

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

alenhorvat reviewed Dec 19, 2024

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

Sakurann mentioned this pull request Dec 23, 2024

first attempt of sd-jwt vcdm #134

Closed

Sakurann commented Jan 14, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

Sakurann commented Jan 14, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

Sakurann commented Jan 14, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Show resolved Hide resolved

Sakurann commented Jan 16, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

Sakurann added 2 commits January 16, 2025 18:35

Apply suggestions from code review

e3a2310

removing the schema related text

c363732

peacekeeper reviewed Jan 16, 2025

View reviewed changes

awoie reviewed Jan 20, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Show resolved Hide resolved

awoie reviewed Jan 20, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

awoie reviewed Jan 20, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

alenhorvat reviewed Jan 20, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Show resolved Hide resolved

awoie reviewed Jan 20, 2025

View reviewed changes

peacekeeper reviewed Jan 21, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

Kristina Yasuda and others added 4 commits January 28, 2025 12:14

allow both signed and unsigned requests. mandate both for the wallet,…

90f1854

… clarify that the verifier has a choice

resolve merge conflict

b923559

fix rebasing

b4b4dc1

add requirements on iat and exp

87ea4e1

Kristina Yasuda added 2 commits January 28, 2025 12:47

format processing steps section

818a29e

add a sentence on type and vct

1fbef98

peacekeeper reviewed Jan 28, 2025

View reviewed changes

openid4vc-high-assurance-interoperability-profile-1_0.md Outdated Show resolved Hide resolved

bc-pi and others added 3 commits January 28, 2025 11:50

AFAIK -02 was put out yesterday https://lists.openid.net/pipermail/op…

f9fc560

…enid-specs-digital-credentials-protocols/Week-of-Mon-20250127/000628.html

fix refs

9b31b9a

add validFrom and validTo properties

ac0f777

bc-pi reviewed Jan 28, 2025

View reviewed changes

bc-pi reviewed Jan 29, 2025

View reviewed changes

TimoGlastra reviewed Jan 29, 2025

View reviewed changes

OR13 reviewed Feb 7, 2025

View reviewed changes

OR13 suggested changes Feb 7, 2025

View reviewed changes

selfissued requested changes Feb 13, 2025

View reviewed changes


		SD-JWT VCDM is a data model that follows IETF SD-JWT VC [@!I-D.ietf-oauth-sd-jwt-vc], but allows the usage of [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0]. When IETF SD-JWT VC is mentioned in this specification, SD-JWT VCDM define in this section MAY be used.

		For backward compatibility with JWT processors, the following registered JWT claims MUST be used, instead of their respective counterpart properties in [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0]:


		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.

	"type": ["VerifiableCredential", "https://credentials.example.com/identity_credential"],
	"type": ["VerifiableCredential", "IdentityCredential"],


		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].

	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].
	Implementers 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` property defined in W3C VCDM [@!W3C.VCDM1.1] or [@!W3C.VCDM2.0].

	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.
	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 a consistent approach to selective disclosure.

	"vcdm": { //W3C VCDM 2.0 compliant claims
	"vcdm": { //W3C VCDM 2.0 or 1.1 compliant claims

	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:
	The following is a non-normative example of how the unsecured payload of the SD-JWT VCDM above can be used for the SD-JWT:


		* `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.

		The following outlines a suggested non-normative processing steps for SD-JWT VCDM:


		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].

	* `sub` Claim MUST represent the `id` property of `credentialSubject` property. `credentialSubject` property MUST be ignored if present.
	* `sub` Claim MUST represent the `id` property of `credentialSubject` property. `credentialSubject` property MUST be ignored if present. There is no support for the case where `credentialSubject` is an array.

second attempt to add sd-jwt vcdm #147

Are you sure you want to change the base?

second attempt to add sd-jwt vcdm #147

Conversation

Sakurann commented Dec 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

awoie Jan 20, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danielfett Feb 5, 2025 • edited Loading

Choose a reason for hiding this comment

awoie Jan 20, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

awoie Jan 21, 2025 • edited Loading

Choose a reason for hiding this comment

awoie Jan 21, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peacekeeper Jan 21, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peacekeeper Jan 28, 2025 • edited Loading

Choose a reason for hiding this comment

bc-pi Jan 28, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peacekeeper commented Jan 30, 2025

awoie commented Jan 30, 2025 • edited Loading

peacekeeper commented Feb 3, 2025

filip26 commented Feb 3, 2025 • edited Loading

awoie commented Feb 5, 2025 • edited Loading

Example: EnvelopedVerifiableCredential object using SD-JWT:

Example: EnvelopedVerifiablePresentation object using SD-JWT:

Why This Adds No Value:

Unsigned Data is Meaningless

Incompatibility with OID4VP Query Mechanisms

peacekeeper commented Feb 5, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

OR13 Feb 7, 2025 • edited Loading

Choose a reason for hiding this comment

OR13 left a comment

Choose a reason for hiding this comment

Sakurann commented Dec 19, 2024 •

edited

Loading

awoie Jan 20, 2025 •

edited

Loading

danielfett Feb 5, 2025 •

edited

Loading

awoie Jan 20, 2025 •

edited

Loading

awoie Jan 21, 2025 •

edited

Loading

awoie Jan 21, 2025 •

edited

Loading

peacekeeper Jan 21, 2025 •

edited

Loading

peacekeeper Jan 28, 2025 •

edited

Loading

bc-pi Jan 28, 2025 •

edited

Loading

awoie commented Jan 30, 2025 •

edited

Loading

filip26 commented Feb 3, 2025 •

edited

Loading

awoie commented Feb 5, 2025 •

edited

Loading

Example: `EnvelopedVerifiableCredential` object using SD-JWT:

Example: `EnvelopedVerifiablePresentation` object using SD-JWT:

OR13 Feb 7, 2025 •

edited

Loading