Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

first attempt of sd-jwt vcdm #134

Closed
wants to merge 4 commits into from
Closed

first attempt of sd-jwt vcdm #134

Changes from 3 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
713a059
align the text to the latest sd-jwt vc spec text
Nov 28, 2024
ded0273
add examples of sd-jwt vcdm
Nov 28, 2024
54421dd
Apply suggestions from code review
Sakurann Dec 3, 2024
cef216d
Apply suggestions from code review
Sakurann Dec 19, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
121 changes: 108 additions & 13 deletions openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -221,29 +221,24 @@ To authenticate the user, subject identifier in a Self-Issued ID Token MUST be u
* As a way to invoke the Wallet, at least a custom URL scheme `haip://` MUST be supported. Implementations MAY support other ways to invoke the wallets as agreed by trust frameworks/ecosystems/jurisdictions, not limited to using other custom URL schemes.
* `subject_syntax_types_supported` value MUST be `urn:ietf:params:oauth:jwk-thumbprint`

# SD-JWT VCs {#sd-jwt-vc}
# SD-JWT VC {#sd-jwt-vc}

As credential format, SD-JWT VCs as defined in [@!I-D.ietf-oauth-sd-jwt-vc] MUST be used.

In addition, this profile defines the following additional requirements.
This profile defines the following additional requirements for SD-JWT VCs as defined in [@!I-D.ietf-oauth-sd-jwt-vc].

* Compact serialization MUST be supported as defined in [@!I-D.ietf-oauth-selective-disclosure-jwt]. JSON serialization MAY be supported.
* The following JWT Claims MUST be supported Content (differentiate issuance & presentation)
* The following JWT Claims MUST be supported in addition to the requirements in Section 3.2.2.2 in [@!I-D.ietf-oauth-sd-jwt-vc]:

| Claim | SD-JWT as issued by the Issuer | Normative Definition |
|:--- |:--- |:--- |
|iss |MUST |[@!RFC7519], Section 4.1.1 |
|iat |MUST |[@!RFC7519], Section 4.1.6 |
| exp | SHOULD (at the discretion of the issuer) | [@!RFC7519], Section 4.1.4 |
|cnf| MUST| [@!RFC7800]|
|vct| MUST| [@!I-D.ietf-oauth-sd-jwt-vc]|
|exp | SHOULD (at the discretion of the issuer) | [@!RFC7519], Section 4.1.4 |
|status|SHOULD (at the discretion of the issuer)| [@!I-D.ietf-oauth-status-list]|

* The Issuer MUST NOT make any of the JWT Claims in the table above to be selectively disclosable, so that they are always present in the SD-JWT-VC presented by the Holder.
* It is at the discretion of the Issuer whether to use `exp` claim and/or a `status` claim to express the validity period of an SD-JWT-VC. The wallet and the verifier MUST support both mechanisms.
* The Issuer MUST NOT make any of the JWT Claims in the table above to be selectively disclosable, so that they are always present in the SD-JWT VC presented by the Holder.
* It is at the discretion of the Issuer whether to use `exp` claim and/or a `status` claim to express the validity period of an SD-JWT VC. The Issuer MUST use one of the mechanisms. The wallet and the verifier MUST support both mechanisms.
* 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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


Expand Down Expand Up @@ -272,11 +267,80 @@ 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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## SD-JWT VCDM
## SD-JWT VC Data Model (VCDM)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


SD-JWT VCDM is a data model that follows [@!I-D.ietf-oauth-sd-jwt-vc], but is compatible with the [@!W3C.VCDM2.0]. SD-JWT VCDM MAY be used.

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

```json
{
"vct": "https://credentials.example.com/identity_credential",

//W3C VCDM 2.0 compliant claims
"type": ["VerifiableCredential", "https://credentials.example.com/identity_credential"],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would remove this duplication since it is not required.

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

"@context": ["https://www.w3.org/ns/credentials/v2"],
"issuer": "https://example.com/issuer",
"credentialSubject": {
"given_name": "John",
"family_name": "Doe",
"email": "johndoe@example.com",
"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:

```json
{
"_sd": [
"vwUhdFvpylx9Sqi2YNBV1dfVK6lCbhXvkH0nThfKFT0"
],
"iss": "https://example.com/issuer",
"issuer": "https://example.com/issuer",
Comment on lines +310 to +311
Copy link
Collaborator

@awoie awoie Nov 29, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

"iat": 1683000000,
"exp": 1883000000,
"vct": "https://credentials.example.com/identity_credential",
"type": ["VerifiableCredential", "https://credentials.example.com/identity_credential"],
"@context": ["https://www.w3.org/ns/credentials/v2"],
"_sd_alg": "sha-256",
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
"y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
}
}
}
```

* One of the values in `type` array MUST equal the value in `vct` claim.
* The value of `issuer` clam MUST equal the value in `iss` claim.

The following mechanisms defined in [@!I-D.ietf-oauth-sd-jwt-vc] MUST be used instead of their W3C VCDM 2.0 counter part:

* Status management (e.g., revoked, suspended, etc.)
* Schema
* Display information
* Validity information

# Crypto Suites

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:

* SD-JWT-VC
* SD-JWT VC
* Wallet Instance Attestation
* DPoP
* HB JWT
Expand Down Expand Up @@ -399,6 +463,37 @@ 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/vc-data-model-2.0/">
<front>
<title>Verifiable Credentials Data Model v2.0</title>
<author fullname="Manu Sporny">
<organization>Digital Bazaar</organization>
</author>
<author fullname="Ted Thibodeau Jr">
<organization>OpenLink Software</organization>
</author>
<author fullname="Ivan Herman">
<organization>W3C</organization>
</author>
<author fullname="Michael B. Jones">
<organization>Invited Expert</organization>
</author>
<author fullname="Gabe Cohen">
<organization>Block</organization>
</author>
<author fullname="Dave Longley">
<organization>Digital Bazaar</organization>
</author>
<author fullname="David Chadwick">
<organization>University of Kent</organization>
</author>
<author fullname="Orie Steele">
<organization>Transmute</organization>
</author>
<date day="19" month="October" year="2024"/>
</front>
</reference>

# Combined Issuance of SD-JWT VC and mdocs

* If combined issuance is required, the Batch Credential Endpoint MUST be supported.
Expand Down
Loading