first attempt of sd-jwt vcdm #134

Sakurann · 2024-11-28T23:25:08Z

resolves #128

danielfett · 2024-11-29T10:24:40Z

openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md

+## SD-JWT VCDM
+
+SD-JWT VCDM MAY be used. SD-JWT VCDM is a data model that follows [@!I-D.ietf-oauth-sd-jwt-vc], but is compatible with the [@!W3C.VCDM2.0].
+
+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]:


Since SD-JWT VC DM is not a specification, I would say "in accordance with the SD-JWT VC DM proposal, " or similar.

but I don't think we should point to a private repo. so i am reluctant to mention SD-JWT VC DM proposal at all

the point is to define SD-JWT VCDM in HAIP, here, from scratch

Should the authors contribute?

Why is the sd-jwt vcdm being moved here? Was there an agreement with the authors?

Instead of rewriting from scratch, I believe we should adapt the original idea to the new reality of the EUDI Wallet and ARF. This means ensuring compatibility with SD-JWT and W3C VC DM, while not leaving behind the use cases that have been developed in environments such as education or powers of representation (mainly within the EBSI ecosystem), and iterating.

I am convinced that together we can create an open profile for VCs that anyone can adopt to address the complex reality of use cases that will arise in the coming years.

Let’s open this line of work where the original authors can guide the development of the specification at a low level.

openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md

awoie · 2024-11-29T10:43:58Z

openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md

@@ -272,11 +267,79 @@ 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 VCDM


Suggested change

## SD-JWT VCDM

## SD-JWT VC Data Model (VCDM)

openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md

awoie · 2024-11-29T10:45:27Z

openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md

+  "iss": "https://example.com/issuer",
+  "issuer": "https://example.com/issuer",


Is there a way to not have these duplicates, e.g., changes to SD-JWT VC itself?

Although the jwt encoding for w3c vcs was definitely a lot simpler than the JSON-LD counterpart, the thing i disliked about it the most was the duplication of values and the issues it caused in validation. Every duplicated parameter introduces a chance of inconsistent data in the credential. So i agree with @awoie here

Is there a way to not have these duplicates, e.g., changes to SD-JWT VC itself?

if we want a data structure that is compliant to ietf sd-jwt vc and w3c vcdm as-is, that is the only way I think?

awoie · 2024-11-29T11:19:46Z

openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md

@@ -272,11 +267,79 @@ 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 VCDM


We should clearly say something about the goals of SD-JWT VCDM and who can consume it. For example, we should define what of the following scenarios are possible:

SD-JWT VC processor without JSON-LD processing

SD-JWT VC processor with JSON-LD processing

W3C VCDM 2.0 processor (which requires JSON-LD), with securing mechanism verification. This might be an issue because of the external context definitions will be required, and because SD-JWT VC has to be defined as a W3C VCDM 2.0 securing mechanism.

W3C VCDM 2.0 processor without securing mechanism verification; just do SD-JWT VC verification. This will also require external context definitions for all public/private JWT claims which are not defined in the W3C VCDM 2.0 context already.

any other options?

After this PR got merged: w3c/vc-data-model#1520, VCDM 2.0 requires all claims to be defined explicitly in dedicated @context definitions referenced by the @context array. This is required because all VCDM 2.0 credentials have to be JSON-LD compliant. Before this PR, this was not strictly required (although kind of recommended). Not having these properly defined in these context definitions would break VCDM 2.0 processors. The VCDM 2.0 context does have definitions for all the standard SD-JWT terms but does not have definitions of SD-JWT VC claims such as status, schema etc. Previously all these claims got added the default context as issuer-dependent terms via the "@vocab": "https://www.w3.org/ns/credentials/issuer-dependent#" statement in the W3C VCDM 2.0 context.

can we re-introduce "@vocab": "https://www.w3.org/ns/credentials/issuer-dependent#" here?

It is possible to add a default vocab in HAIP but it should be noted that this MUST NOT be done if Data Integrity Proofs are used. I'm not sure yet if this is a good idea though.

However, we would need to use a different IRI for the value of @vocab since https://www.w3.org/ns/credentials/issuer-dependent#" does not go anywhere.

openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md

Co-authored-by: Timo Glastra <[email protected]> Co-authored-by: Oliver Terbu <[email protected]>

tlodderstedt · 2024-12-03T20:44:39Z

@Sakurann wouldn't we aim for VCDM 1.1 support?

tlodderstedt · 2024-12-03T20:52:37Z

Discussion during WG Call:

VCDM 1.1 and/or 2.0?
Are we aiming for VCDM compliance (would require 2.0 and definition of securing mechanisms ...) or support for implementers wanting to add selective disclosure to 1.1/2.0 VCs?

Sakurann · 2024-12-05T02:49:45Z

at least my intention was to allow using JSON-LD. i think we can do it in a way that does not require VCDM compliance, especially given 1.1/2.0 confusion. will try refactor the PR in that direction.

javereec

Quick review

openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md

ssanchocanela · 2024-12-06T06:40:41Z

That looks great to me.
I agree with @tlodderstedt that we should mention W3C VCDM 1.1 and point to 2.0. Current eIDAS2 IAs approved include W3C VCDM 1.1 but the intention looking at the roadmap is to replace it with 2.0 when ready.

openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md

javereec · 2024-12-13T07:15:48Z

openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md

 * The `iss` claim MUST be an HTTPS URL. The `iss` value is used to obtain Issuer’s signing key as defined in (#issuer-key-resolution).
-* The `vct` JWT claim as defined in [@!I-D.ietf-oauth-sd-jwt-vc].
-* The `cnf` claim [@!RFC7800] MUST conform to the definition given in [@!I-D.ietf-oauth-sd-jwt-vc]. Implementations conforming to this profile MUST include the JSON Web Key [@!RFC7517] in the `jwk` sub claim.
+* The `cnf` claim [@!RFC7800] MUST include the JSON Web Key [@!RFC7517] in the `jwk` sub claim.

 Note: Currently this profile only supports presentation of credentials with cryptographic Holder Binding: the holder's signature is required to proof the credential is presented by the holder it was issued to. This profile might support claim-based and biometrics-based holder binding once OpenID for Verifiable Credentials adds support for other forms of Holder Binding. See https://bitbucket.org/openid/connect/issues/1537/presenting-vc-without-a-vp-using-openid4vp


Should this section be removed? Feels like it's using old POV and references an old issue

Co-authored-by: Jan Vereecken <[email protected]>

Sakurann · 2024-12-19T13:46:31Z

input that we would probably need to define sd-jwt vcdm for json serialization, too.

awoie · 2024-12-19T13:49:53Z

openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md

+  "vct": "https://credentials.example.com/identity_credential",
+
+  //W3C VCDM 2.0 compliant claims
+  "type": ["VerifiableCredential", "https://credentials.example.com/identity_credential"],


I would remove this duplication since it is not required.

Suggested change

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

"type": ["VerifiableCredential"],

Sakurann · 2024-12-23T10:40:50Z

closing in favor of #147. will incorporate relevant comments on this PR into a new one

Kristina Yasuda added 2 commits November 28, 2024 22:56

align the text to the latest sd-jwt vc spec text

713a059

add examples of sd-jwt vcdm

ded0273

Sakurann requested review from danielfett, awoie and bc-pi November 28, 2024 23:25

danielfett reviewed Nov 29, 2024

View reviewed changes

awoie requested changes Nov 29, 2024

View reviewed changes

TimoGlastra reviewed Nov 29, 2024

View reviewed changes

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

Apply suggestions from code review

54421dd

Co-authored-by: Timo Glastra <[email protected]> Co-authored-by: Oliver Terbu <[email protected]>

javereec reviewed Dec 5, 2024

View reviewed changes

javereec reviewed Dec 13, 2024

View reviewed changes

Apply suggestions from code review

cef216d

Co-authored-by: Jan Vereecken <[email protected]>

awoie reviewed Dec 19, 2024

View reviewed changes

Sakurann mentioned this pull request Dec 19, 2024

second attempt to add sd-jwt vcdm #147

Open

Sakurann closed this Dec 23, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

first attempt of sd-jwt vcdm #134

first attempt of sd-jwt vcdm #134

Sakurann commented Nov 28, 2024

danielfett Nov 29, 2024

Sakurann Dec 3, 2024

Sakurann Dec 3, 2024

alenhorvat Dec 6, 2024

alenhorvat Dec 6, 2024

ssanchocanela Dec 6, 2024

awoie Nov 29, 2024

awoie Nov 29, 2024 •

edited

Loading

TimoGlastra Nov 29, 2024

Sakurann Dec 3, 2024

awoie Nov 29, 2024

Sakurann Dec 3, 2024

awoie Dec 3, 2024

tlodderstedt commented Dec 3, 2024

tlodderstedt commented Dec 3, 2024 •

edited

Loading

Sakurann commented Dec 5, 2024

javereec left a comment

ssanchocanela commented Dec 6, 2024

javereec Dec 13, 2024

Sakurann commented Dec 19, 2024

awoie Dec 19, 2024

Sakurann commented Dec 23, 2024

		@@ -272,11 +267,79 @@ 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 VCDM

		"iss": "https://example.com/issuer",
		"issuer": "https://example.com/issuer",

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

first attempt of sd-jwt vcdm #134

first attempt of sd-jwt vcdm #134

Conversation

Sakurann commented Nov 28, 2024

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 Nov 29, 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

tlodderstedt commented Dec 3, 2024

tlodderstedt commented Dec 3, 2024 • edited Loading

Sakurann commented Dec 5, 2024

javereec left a comment

Choose a reason for hiding this comment

ssanchocanela commented Dec 6, 2024

Choose a reason for hiding this comment

Sakurann commented Dec 19, 2024

Choose a reason for hiding this comment

Sakurann commented Dec 23, 2024

awoie Nov 29, 2024 •

edited

Loading

tlodderstedt commented Dec 3, 2024 •

edited

Loading