diff --git a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md index 6822171..1542f93 100644 --- a/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md +++ b/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.md @@ -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 IETF SD-JWT VC 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 @@ -272,14 +267,84 @@ 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 + +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"], + "@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", + "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` claim 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 +* IETF SD-JWT VC +* SD-JWT VCDM * Wallet Instance Attestation * DPoP -* HB JWT +* Key Binding JWT * Authorization request during presentation SHA256 MUST be supported by all the entities as the hash algorithm to generate and validate the digests in the SD-JWT VC. @@ -399,6 +464,37 @@ Note: When using this profile with other cryptosuites, it is recommended to be e + + + Verifiable Credentials Data Model v2.0 + + Digital Bazaar + + + OpenLink Software + + + W3C + + + Invited Expert + + + Block + + + Digital Bazaar + + + University of Kent + + + Transmute + + + + + # Combined Issuance of SD-JWT VC and mdocs * If combined issuance is required, the Batch Credential Endpoint MUST be supported.