add sd-jwt vcld

[awoie]

Implements DCP WG meeting / OSW decision on SD-JWT VCDM.

Fixes #445

@alenhorvat @steffenschwalm

[alenhorvat]

How is this proposal different from the W3C in B.1?

[steffenschwalm]

should be changed into "incorporate existing data mdels" and "while enabling uncomplicate approach to selective disclosure"

[awoie]

uncomplicate

resolved

[awoie]

B.1

It is an SD-JWT VC that can or cannot contain any JSON-LD object.

[steffenschwalm]

@awoie @Sakurann What the purpose of this work you are proposing here?

[peacekeeper]

@peacekeeper can you please re-review given this change? f3da03a

f3da03a is good, but "type" also needs to be removed from the examples.

[peacekeeper]

Overall, I continue to think that the whole SD-JWT-* family of things is a bad idea that will complicate life for a lot of people and for existing implementations, contrary to the proclaimed "simple is a feature" philosophy. This here is something that's wanted for some intransparent political and business reasons and doesn't make much sense from a technology perspective.

I still see various problems and potential security holes with this, e.g. around Type Metadata and processing of JSON-LD @context. I can easily imagine examples where a JWT processor and a JSON-LD processor will interpret payloads differently. But I guess nobody cares, and the JWT camp and JSON-LD camp will just blame each other when that happens.

I think I said at IIW that I would approve if there are no more ambiguities with core W3C VCDM properties, and I think that's clearer now, so here we go (please still remove "type" from examples, and don't add it back in later, thanks).

[steffenschwalm]

@peacekeeper I partially agree to your statement. Unfortunately the current draft does not cover the agreed requirements like integration of W3C VC Data Model in SD-JWT VC (not only certain parts). avoidance of issues e.g. processing JSON-LD, inclusion of subjects like micro credentials, defining the SD-JWT VCDM option not as may (in case use W3CVCDM in SD_JWT VC needed) but as (Conditional) Must)

Personally it becomes more and more interesting how decisions made in this WG " think I said at IIW that I would approve if..." - why not everybody got this information in advance? Are information shared only to selected members of the WG - as ths information not given to everybody.

Beside this: The wording " This extension is specifically targeted towards existing data models that use linked data" is misleading as not only W3CVCDM use linked data but also mDoc... and this is not included.

so in alignment with @alenhorvat as he`s co-author of the fundamental draft this spec here is based on I strongly disagree to this draft and require improvement according to the comments

[jogu]

Note we currently plan to include this PR on the agenda for Thursday's regular DCP working group meeting (17th April) - anyone interested to join can find the WG call on the OIDF calendar. (And for clarity as there was some discussion about process last week: this is fully compliant with ODIF process, discussing or merging a PR into a draft is not a "Core Decision" that requires 7 days notice, the formal decision about publishing a specification happens later in the process.)

[danielfett]

I think I said at IIW that I would approve if there are no more ambiguities with core W3C VCDM properties, and I think that's clearer now, so here we go (please still remove "type" from examples, and don't add it back in later, thanks).

For the record, I'm fine with removing type. And I'm also totally fine with people discussing things in my absence at IIW :-D

[danielfett]

(please still remove "type" from examples, and don't add it back in later, thanks).

Done.

[jogu]

To respond only to the process points (I will leave others who are more knowledgeable to respond to other points):

@peacekeeper I partially agree to your statement. Unfortunately the current draft does not cover the agreed requirements like integration of W3C VC Data Model in SD-JWT VC (not only certain parts). avoidance of issues e.g. processing JSON-LD, inclusion of subjects like micro credentials, defining the SD-JWT VCDM option not as may (in case use W3CVCDM in SD_JWT VC needed) but as (Conditional) Must)

As I mentioned above, the only requirements I am aware of that have been agreed in/with the working group are:

https://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/Week-of-Mon-20250203/000659.html

and:

the scope of work the WG agreed on: "To expand the number of use-case, define how to combine sd-jwt vc and json-ld based payload in way that uses sd-jwt vc as a securing mechanism, and allows to used w3c vcdm claims for business processing (compliance to w3c vcdm is not required)"

I do not see any agreement that micro credentials would be included. There was no agreement to make SD-JWT VCDM mandatory to use when using SD-JWTs. You are of course welcome to make the case that these should be requirements, but my opinion would be the WG is unlikely to treat them as requirements unless you explain why they are needed.

Personally it becomes more and more interesting how decisions made in this WG " think I said at IIW that I would approve if..." - why not everybody got this information in advance? Are information shared only to selected members of the WG - as ths information not given to everybody.

As I stated on Friday's WG call, side meetings and discussions to resolve strong differences of opinion are a normal part of standards development at every SDO I've been involved with. I understand that you have yourself taken part in a number of such discussions, I am genuinely at a loss to understand why you object so strongly to other people also doing so. As you're aware, no working group decisions are made at such meetings, decisions are only taken via GitHub, in official WG meetings or via the working group mailing list. Markus, or anyone else, should consider themselves free to express to anyone who will listen what changes could be made to a PR to make it acceptable to them.

Going forward, can we please focus on resolving the technical points? For example, if there are use cases where micro credentials are needed in a credential format that supports selective disclosure, please do share what they are.

[steffenschwalm]

@jogu the following requirements were agreed between @Sakurann@danielfett @awoie @bc-pi @alenhorvat Sancho Canela, Nacho Alamillo, Lluis Arino (our background strategic ecosystems in alignment with EC) in a call on 1912.2024. It was agreed to work commonly on an SD-JWT VCDM with exactly these content within DCP WG in OIDF.

"- ability to reuse existing vcdm 1.1 code is important

• ability to transition from vcdm 1.1 code to sd-jwt vcdm code is important
• strict compliance to vcdm 2.0 is not necessary
• should work both with and without json-ld processing

This updated design is very similar to vcdm 1.1 "instead of" approach in vc-jwt - it is much cleaner without duplications, and closer to the original agreement from earlier this year (the one in Daniel's personal repo). I also have an intuition this might work better with JSON serialization - need to confirm that separately.

I would like to close the old PR, so that we are all reviewing the same version and to prevent confusion - please let me know if you want me to keep the old one open too, for now."

it was not as @tlodderstedt assumed to ensure Selective Disclosure in VCDM using SD-JWAT VC as SD is already possible like also @peacekeeper never becomes tired to mention

This was the basement for the work based on on the previous work done by @alenhorvat and especially Lluis Arino in European Projects and later together with @danielfett & @awoie

As we are not the chairs of this WG we cannot inform the WG about this agreement. This would have been the task of @Sakurann and/or @tlodderstedt. Obviously it was not done! This seems the core issue in the whole project. We do not know why the WG was not informed.

In meeting on 05.02.2025 (same team as 19.12.2024 + @tlodderstedt the scope was agreed again, also presentation from @alenhorvat in February at DCP WG is no in contradiction. So @jogu: We fully understand your confusion which seems caused in the obviously omited information about the scope of this PR by @Sakurann and/or @tlodderstedt. Maybe there was also information lost between Daniel/Oliver/Kristina and Torsten.

• ability to reuse existing vcdm 1.1 code is important
• ability to transition from vcdm 1.1 code to sd-jwt vcdm code is important
• strict compliance to vcdm 2.0 is not necessary
• should work both with and without json-ld processing

This updated design is very similar to vcdm 1.1 "instead of" approach in vc-jwt - it is much cleaner without duplications, and closer to the original agreement from earlier this year (the one in Daniel's personal repo). I also have an intuition this might work better with JSON serialization - need to confirm that separately.

The current version does not help the use cases (B2B, education, data sharing, OrgID etc.) and contains technical incompatibilities (e.g. assumption all data models with linked data covered). So we strongly recommend to skip the PR.

So @jogu " As you're aware, no working group decisions are made at such meetings, decisions are only taken via GitHub, in official WG meetings or via the working group mailing list."

If we cant trust in agreements with parts of chairs as basement for this specification (as tits based on results co-funded by Comission) anymore the question arise how trustable is the spec for European needs (as it does not match with them) . I apologize if you may not have been informed by your co-chairs, but exactly this difference between agreements with Co-Chairs and the work here seems to be the core issue,

[steffenschwalm]

Note we currently plan to include this PR on the agenda for Thursday's regular DCP working group meeting (17th April) - anyone interested to join can find the WG call on the OIDF calendar. (And for clarity as there was some discussion about process last week: this is fully compliant with ODIF process, discussing or merging a PR into a draft is not a "Core Decision" that requires 7 days notice, the formal decision about publishing a specification happens later in the process.)

thanks. According to Section 4.10 of OIDF process document: "A WG meeting may be called at any time by any of its Editor(s) (or by any other Contributor, if thereis no Editor) on at least seven days’ notice to all Contributors to that WG. 4.10 obviously does not make difference kind of decisions when referring to 7 days timeline.

https://openid.net/wp-content/uploads/2024/10/OIDF_Process-Document_Final_2024-10-19.pdf

But happy that it`s earlier tahan 03.30 AM CEST as last time and now seemingly without prejudicing the result seemingly aimed by parts of the chairs, Seems we are on better way in terms of formal subjects.-

[tlodderstedt]

I suggest to remove sub as it belongs to the credential payload, in the case od VCLD within theld element.

[danielfett]

@jogu the following requirements were agreed between @Sakurann@danielfett @awoie @bc-pi @alenhorvat Sancho Canela, Nacho Alamillo, Lluis Arino (our background strategic ecosystems in alignment with EC) in a call on 1912.2024. It was agreed to work commonly on an SD-JWT VCDM with exactly these content within DCP WG in OIDF.

"- ability to reuse existing vcdm 1.1 code is important

* ability to transition from vcdm 1.1 code to sd-jwt vcdm code is important

* strict compliance to vcdm 2.0 is not necessary

* should work both with and without json-ld processing

This updated design is very similar to vcdm 1.1 "instead of" approach in vc-jwt - it is much cleaner without duplications, and closer to the original agreement from earlier this year (the one in Daniel's personal repo). I also have an intuition this might work better with JSON serialization - need to confirm that separately.

I would like to close the old PR, so that we are all reviewing the same version and to prevent confusion - please let me know if you want me to keep the old one open too, for now."

In my view, this PR fulfills these requirements.

This was the basement for the work based on on the previous work done by @alenhorvat and especially Lluis Arino in European Projects and later together with @danielfett & @awoie

As we are not the chairs of this WG we cannot inform the WG about this agreement. This would have been the task of @Sakurann and/or @tlodderstedt. Obviously it was not done! This seems the core issue in the whole project. We do not know why the WG was not informed.

In meeting on 05.02.2025 (same team as 19.12.2024 + @tlodderstedt the scope was agreed again, also presentation from @alenhorvat in February at DCP WG is no in contradiction. So @jogu: We fully understand your confusion which seems caused in the obviously omited information about the scope of this PR by @Sakurann and/or @tlodderstedt. Maybe there was also information lost between Daniel/Oliver/Kristina and Torsten.

* ability to reuse existing vcdm 1.1 code is important

* ability to transition from vcdm 1.1 code to sd-jwt vcdm code is important

* strict compliance to vcdm 2.0 is not necessary

* should work both with and without json-ld processing

This updated design is very similar to vcdm 1.1 "instead of" approach in vc-jwt - it is much cleaner without duplications, and closer to the original agreement from earlier this year (the one in Daniel's personal repo). I also have an intuition this might work better with JSON serialization - need to confirm that separately.

The current version does not help the use cases (B2B, education, data sharing, OrgID etc.) and contains technical incompatibilities (e.g. assumption all data models with linked data covered). So we strongly recommend to skip the PR.

So @jogu " As you're aware, no working group decisions are made at such meetings, decisions are only taken via GitHub, in official WG meetings or via the working group mailing list."

If we cant trust in agreements with parts of chairs as basement for this specification (as tits based on results co-funded by Comission) anymore the question arise how trustable is the spec for European needs (as it does not match with them) . I apologize if you may not have been informed by your co-chairs, but exactly this difference between agreements with Co-Chairs and the work here seems to be the core issue,

We agreed to bring these ideas and requirements to the working group, which we did. But, as you made very clear in the last days again and again, technical decisions are not made between a small subgroup of people, or "parts of chairs", but by working group consensus. I remember that I made this clear in our small group meeting — we can agree to work in a direction, but ultimately, decisions need to be made in the working group. As far as I remember, you did not attend any working group meeting to discuss this PR or your requirements before Friday last week.

Alen used the opportunity to present all the requirements to the working group at the OSW meeting. In that meeting, the consensus in the working group was to proceed in the direction of this PR (details captured in the meeting minutes).

On the "European needs": The most important source of EU requirements is our liaison with the EC. The EC sent an official letter to the OIDF determining the scope of the work of this WG in support of the EUDIW. Additionally, EC representatives regularly attend our meetings. Besides that, a lot of WG participants work in European projects and bring their requirements to the table. Last but not least, we have a liaison with ETSi to jointly support the EU. Clearly, your contributions are also welcome.

[jogu]

thanks. According to Section 4.10 of OIDF process document: "A WG meeting may be called at any time by any of its Editor(s) (or by any other Contributor, if thereis no Editor) on at least seven days’ notice to all Contributors to that WG. 4.10 obviously does not make difference kind of decisions when referring to 7 days timeline.

These are standing regular meetings. They do not need to be re-noticed each week. They've been present on the working group web page, the OIDF calendar, etc for over year - the schedule was agreed with the working group and communicated out on the mailing list over a year ago, which is significantly more than 7 days. Calendar invites were sent out to the mailing list, most recently on 14th March 2025.

[steffenschwalm]

@danielfett many text but unfortunately many wrong assumptions. As defined in the minutest

https://docs.google.com/document/d/1y3milcqMkAHqf4862ANoCA7irg6gNaDI3aNOVaZMoVY/edit?tab=t.0

• “The goal is to add W3C VCDM data model and processing to this defined credential - secured by SD JWT”

Exactly this is not achieved with current specification.

Beside this: As usual ininternational standardization the experts agreeing on something in advance use open and transparent communication to inform each other in case of core changes made in (obviously not WG meetings as change obviously not documented) certain meetings not everybody took part. We do this in ISO, CEN, ETSI since years successfully.

As we know you, , @Sakurann @tlodderstedt @awoie @bc-pi in particular is trustable and highly professional too we assumed that you may act in same way. If this assumptipon has been a mistake from us please apologize.

[Sakurann]

WG discussion:

• Authors of the PR believe that all properties of VCDM are maintained, but Steffen representing EBSI project disagrees
  • Steffen believes that the following properties are not met
    - atomic credentials: possible with sd-jwt vcld per credential
    - DID: this PR does not define sub value. you can use DID
    - fine-grained localization:
    - multiple renders (multi-language)
    - Audience restriction (advanced)/ Terms of use: support to express sharing and presentation policies, restrictions and similar information. not included for VCDM use Cases the current draft is meaningless
• However a lot on the call were not able to understand technical details why this is not possible
• next steps:
  • merge this PR noting the objection
  • test it (there is already one prototype implementation from Hopae)
    • @steffenschwalm to take this to EBSI projects to test and tell why this works or does not work, (especially for w3c vcdm 1.1)
  • understand Steffen/EBSI/B2B mental model and specific technical proposals that reuse existing mechanisms

[alenhorvat]

"you can use DID"
iss value can be a DID?

[steffenschwalm]

@Sakurann Your summary is wrong and was not discussed in the meeting:

• DID is not possible as the spec relies 100% on SD-JWT VC specification which does not specify how to use DID as we all know
• Atomic Credential is not possible as OID4VP B1 as Daniel suggested does not help if you need the bundling from the time of issuance. exactly the bundling where you need multiple contexts/scopes & fine-grained localization as possible in VCDM is not included in the spec

So strongly recommend to document here what was discussed not what you may wish have been discussed.

[cre8]

"you can use DID" iss value can be a DID?

Yes, see the spec for sd-jwt vc :

iss
- REQUIRED. The Issuer of the Verifiable Credential. The value
of iss MUST be a URI. See [RFC7519] for more information.

And DIDs are URIs, no reason to mention it specifically. It is also mentioned in the document resolution when using DIDs.

[alenhorvat]

DIDs are back in the sd-jwt vc :) let's see how long.

And they are gone again :D
https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/299/files

[cre8]

• DID is not possible as the spec relies 100% on SD-JWT VC specification which does not specify how to use DID as we all know

as mentioned, iss can be a DIDs since URIs are allowed. For sub there is no limitation set, so you can also use DIDs. The only thing where you can not use them is in the cnf where JWK is required. But you are able to reference the used key in the sub via the fragment.

So I see no problem with the summary of @Sakurann

[alenhorvat]

@cre8 , challenge for you oauth-wg/oauth-sd-jwt-vc#253 (comment)

:) it's been open for a while

[cre8]

DIDs are back in the sd-jwt vc :) let's see how long.

And they are gone again :D https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/299/files

I think you mean it is just getting updated ;)

[jogu]

@Sakurann Your summary is wrong and was not discussed in the meeting:

The summary Kristina added looks to me like the one she created whilst sharing her screen during the meeting, and corrected several times as the discussion evolved, and I don't recall any objections to it being raised. As always corrections are welcome but it is always helpful if they can be raised in a positive way please, we're all trying to do our best here.

• DID is not possible as the spec relies 100% on SD-JWT VC specification which does not specify how to use DID as we all know

I think/hope this one is okay given comments since? But I'll note there is a different between "not possible" and "not fully specified". "Not fully specified" means it is possible but further detail needs to be defined to make it interoperable. I'm not aware that there's really been any discussion where the detail should be defined. If it seems like it should be in an OpenID spec it's probably worth raising an issue so it can be discussed in the working group.

• Atomic Credential is not possible as OID4VP B1 as Daniel suggested does not help if you need the bundling from the time of issuance. exactly the bundling where you need multiple contexts/scopes & fine-grained localization as possible in VCDM is not included in the spec

I suggest you open a new issue for this topic (and any others, it's good to keep to one issue for each topic unless the problems or solutions look to be strongly related). As we discussed on the call it would be really helpful to share with the WG the exact use case for Atomic Credentials and an example of a credential that does not work, ideally including the payloads and a description of which bit doesn't work, and ideally a suggestion on a minimal change that would resolve the issue.

[peacekeeper]

And they are gone again :D
https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/299/files

If that gets merged, I guess we'll just have to get it unmerged again.

[jogu]

I'm going to lock this one before it veers too off-topic. I think we've all said our pieces now and the next step is for the people that think we might need further changes to the OID4VP specification to open new issues for those things (anyone that has signed the IPR agreement is welcome to raise an issue).

Thank you everyone for your contributions in getting us to this point, and especially thanks to Oliver for doing the pull request!

(Github locking technically doesn't apply to people with write access, but I'd ask them to respect it too please :) )