diff --git a/78-sd-jwt-vc-credential-offer-leftovers/draft-oid4vc-haip-sd-jwt-vc.html b/78-sd-jwt-vc-credential-offer-leftovers/draft-oid4vc-haip-sd-jwt-vc.html deleted file mode 100644 index ad61eae..0000000 --- a/78-sd-jwt-vc-credential-offer-leftovers/draft-oid4vc-haip-sd-jwt-vc.html +++ /dev/null @@ -1,2312 +0,0 @@ - - - - - - -OpenID4VC High Assurance Interoperability Profile with SD-JWT VC - - - - - - - - - - - - - - - - - - - - - - - - - - -
oid4vc-haip-sd-jwt-vcNovember 2023
Yasuda & LodderstedtStandards Track[Page]
-
-
-
-
Workgroup:
-
OpenID Connect
-
Published:
-
- -
-
Authors:
-
-
-
K. Yasuda
-
Microsoft
-
-
-
T. Lodderstedt
-
sprind.org
-
-
-
-
-

OpenID4VC High Assurance Interoperability Profile with SD-JWT VC

-
-

Abstract

-

This document defines a profile of OpenID for Verifiable Credentials in combination with the credential format SD-JWT VC. The aim is to select features and to define a set of requirements for the existing specifications to enable interoperability among Issuers, Wallets and Verifiers of Credentials where a high level of security and privacy is required. The profiled specifications include OpenID for Verifiable Credential Issuance [OIDF.OID4VCI], OpenID for Verifiable Presentations [OIDF.OID4VP], Self-Issued OpenID Provider v2 [OIDF.SIOPv2], and SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc].

-
-
-
- ▲

-Table of Contents -

- -
-
-
-
-

-1. Introduction -

-

This document defines a set of requirements for the existing specifications to enable interoperability among Issuers, Wallets and Verifiers of Credentials where a high level of security and privacy is required. This document is an interoperability profile that can be used by implementations in various contexts, be it a certain industry or a certain regulatory environment.

-

This document is not a specification, but a profile. It refers to the specifications required for implementations to interoperate among each other and for the optionalities mentioned in the referenced specifications, defines the set of features to be mandatory to implement.

-

The profile uses OpenID for Verifiable Credential Issuance [OIDF.OID4VCI] and OpenID for Verifiable Presentations [OIDF.OID4VP] as the base protocols for issuance and presentation of Credentials, respectively. The credential format used is SD-JWT VC as specified in [I-D.ietf-oauth-sd-jwt-vc]. Additionally, considerations are given on how deployments can perform a combined issuance of credentials in both SD-JWT VC and ISO mdoc [ISO.18013-5] formats.

-

A full list of the open standards used in this profile can be found in Overview of the Open Standards Requirements (reference).

-
-
-

-1.1. Audience Target audience/Usage -

-

The audience of the document is implementers that require a high level of security and privacy for their solutions. A non-exhaustive list of the interested parties includes eIDAS 2.0, California Department of Motor Vehicles, Open Wallet Foundation (OWF), IDunion, GAIN, and the Trusted Web project of the Japanese government, but is expected to grow to include other jurisdictions and private sector companies.

-
-
-
-
-
-
-

-2. Terminology -

-

This specification uses the terms "Holder", "Issuer", "Verifier", and "Verifiable Credential" as defined in [I-D.ietf-oauth-sd-jwt-vc].

-
-
-
-
-

-3. Scope -

-

The following aspects are in scope of this interoperability profile:

- -

Assumptions made are the following:

- -
-
-

-3.1. Out of Scope -

-

The following items are out of scope for the current version of this document, but might be added in future versions:

-
    -
  • Trust Management, i.e. authorization of an issuer to issue certain types of credentials, authorization of the Wallet to be issued certain types of credentials, authorization of the Verifier to receive certain types of credentials. -
    • -
  • Protocol for presentation of Verifiable Credentials for offline use-cases, e.g. over BLE. -
    • -
-
-
-
-
-

-3.2. Scenarios/Business Requirements -

-
    -
  • Combined Issuance of SD-JWT VC and mdoc -
    • -
  • Both issuer-initiated and wallet-initiated issuance -
    • -
  • eIDAS PID and (Q)EAA as defined in eIDAS ARF 1.0 -
    • -
-
-
-
-
-

-3.3. Standards Requirements -

-

Unless explicitly stated, all normative requirements apply to all participating entities: Issuers, Wallets and Verifiers.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 1
(as defined in this profile)IssuerWalletVerifier
OID4VPN/AMUSTMUST
OID4VCIMUSTMUSTN/A
SIOPv2N/AMUSTSHOULD
SD-JWT VC profile as defined in Section 7 -MUSTMUSTMUST
-
-
-
-
-
-
-

-4. OpenID for Verifiable Credential Issuance -

-

Implementations of this profile:

- -

Both Wallet initiated and Issuer initiated issuance is supported.

-
-
-

-4.1. Credential Offer -

-
    -
  • The Grant Types authorization_code and urn:ietf:params:oauth:grant-type:pre-authorized_code MUST be supported as defined in Section 4.1.1 in [OIDF.OID4VCI] -
    • -
  • For Grant Type authorization_code, the Issuer MUST include a scope value in order to allow the Wallet to identify the desired credential type. The wallet MUST use that value in the scope Authorization parameter. For Grant Type urn:ietf:params:oauth:grant-type:pre-authorized_code, the pre-authorized code is used by the issuer to identify the credential type(s). -
    • -
  • 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. -
    • -
-

Note: The Authorization Code flow does not require a Credential Offer from the Issuer to the Wallet. However, it is included in the feature set of the Credential Offer because it might be easier to implement with existing libraries and on top of existing implementations than the pre-authorized code Grant Type.

-

Both sending Credential Offer same-device and cross-device is supported.

-
-
-
-
-

-4.2. Authorization Endpoint -

-
    -
  • MUST use Pushed Authorization Requests (PAR) [RFC9126] to send the Authorization Request. -
    • -
  • Wallets MUST authenticate itself at the PAR endpoint using the same rules as defined in Section 4.3 for client authentication at the token endpoint. -
    • -
  • MUST use the scope parameter to communicate credential type(s) to be issued. The scope value MUST map to a specific Credential type. The scope value may be pre-agreed, obtained from the Credential Offer, or the Credential Issuer Metadata. -
    • -
  • The client_id value in the PAR request MUST be a string that the Wallet has used as the sub value in the client attestation JWT. -
    • -
-
-
-
-
-

-4.3. Token Endpoint -

-
    -
  • The Wallets MUST perform client authentication as defined in [I-D.ietf-oauth-attestation-based-client-auth]. -
    • -
  • Refresh tokens MUST be supported for credential refresh. -
    • -
  • Wallets MUST support deferred authorization by being able to process the Token error response parameters authorization_pending and slow_down, and the credential offer parameter interval. -
    • -
  • The Wallet Attestation JWT scheme is defined in Section 4.3.1. -
    • -
-

Note: It is RECOMMENDED to use ephemeral client attestation JWTs for client authentication in order to prevent linkability across Credential Issuers.

-

Note: Issuers should be mindful of how long the usage of the refresh token is allowed to refresh a credential, as opposed to starting the issuance flow from the beginning. For example, if the User is trying to refresh a credential more than a year after its original issuance, the usage of the refresh tokens is NOT RECOMMENDED.

-
-
-

-4.3.1. Wallet Attestation Schema -

-

Wallets MUST use attestations following the definition given in [I-D.ietf-oauth-attestation-based-client-auth].

-

In addition to this definition, the Wallet Attestation MAY contain the following claims in the cnf element:

-
    -
  • -

    key_type: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to manage the private key associated with the public key given in the cnf claim. This mechanism is based on the capabilities of the execution environent of the Wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud Wallet). This specification defines the following values for key_type:

    -
      -
    • - software: It MUST be used when the Wallet uses software-based key management. -
      • -
    • - hardware: It MUST be used when the wallet uses hardware-based key management. -
      • -
    • - tee: It SHOULD be used when the Wallet uses the Trusted Execution Environment for key management. -
      • -
    • - secure_enclave: It SHOULD be used when the Wallet uses the Secure Enclave for key management. -
      • -
    • - strong_box: It SHOULD be used when the Wallet uses the Strongbox for key management. -
      • -
    • - secure_element: It SHOULD be used when the Wallet uses a Secure Element for key management. -
      • -
    • - hsm: It SHOULD be used when the Wallet uses Hardware Security Module (HSM). -
      • -
    -
    • -
  • -

    user_authentication: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to authenticate the user to authorize access to the private key associated with the public key given in the cnf claim. This specification defines the following values for user_authentication:

    -
      -
    • - system_biometry: It MUST be used when the key usage is authorized by the mobile operating system using a biometric factor. -
      • -
    • - system_pin: It MUST be used when the key usage is authorized by the mobile operating system using personal identification number (PIN). -
      • -
    • - internal_biometry: It MUST be used when the key usage is authorized by the Wallet using a biometric factor. -
      • -
    • - internal_pin: It MUST be used when the key usage is authorized by the Wallet using PIN. -
      • -
    • - secure_element_pin It MUST be used when the key usage is authorized by the secure element managing the key itself using PIN. -
      • -
    -
    • -
-

The Wallet Attestation MAY also contain the following claim:

-
    -
  • - aal: OPTIONAL. JSON String asserting the authentication level of the Wallet and the key as asserted in the cnf claim. -
    • -
-

To obtain the issuer's Public key for verification, wallet attestions MUST support web-based key resolution as defined in Section 5 of [I-D.terbu-sd-jwt-vc]. The JOSE header kid MUST be used to identify the respective key.

-

This is an example of a Wallet Instance Attestation:

-
-
{
-  "typ": "wallet-attestation+jwt",
-  "alg": "ES256",
-  "kid": "1"
-}
-.
-{
-  "iss": "<identifier of the issuer of this wallet attestation>",
-  "sub": "<`client_id` of the OAuth client>",
-  "iat": 1516247022,
-  "exp": 1541493724,
-  "aal" : "https://trust-list.eu/aal/high",
-  "cnf": {
-    "jwk": {
-      "kty": "EC",
-      "crv": "P-256",
-      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
-      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
-    },
-    "key_type": "strong_box",
-    "user_authentication": "system_pin",
-  }
-}
-
-
-
-
-
-
-
-
-
-

-4.4. Credential Endpoint -

-
    -
  • The JWT proof type MUST be supported. -
    • -
-
-
-
-
-

-4.5. Server Metadata -

-
    -
  • The Credential Issuer MUST publish a mapping of every Credential Type it supports to a scope value. -
    • -
-
-
-
-
-
-
-

-5. OpenID for Verifiable Presentations -

- -
-
-
-
-

-6. Self-Issued OP v2 -

-

To authenticate the user, subject identifier in a Self-Issued ID Token MUST be used as defined in [OIDF.SIOPv2].

- -
-
-
-
-

-7. SD-JWT VCs -

-

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.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 2
ClaimSD-JWT as issued by the IssuerNormative Definition
issMUST - [RFC7519], Section 4.1.1
iatMUST - [RFC7519], Section 4.1.6
expSHOULD (at the discretion of the issuer) - [RFC7519], Section 4.1.4
cnf MUST - [RFC7800] -
vct MUST - [I-D.ietf-oauth-sd-jwt-vc] -
statusSHOULD (at the discretion of the issuer) - [I-D.ietf-oauth-status-list] -
- -

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

-

Note: Re-using the same Credential across Verifiers, or re-using the same JWK value across multiple Credentials gives colluding Verifiers a mechanism to correlate the User. There are currently two known ways to address this with SD-JWT VCs. First is to issue multiple instances of the same credentials with different JWK values, so that if each instance of the credential is used at only one Verifier, it can be reused multiple times. Another is to use each credential only once (ephemeral credentials). It is RECOMMENDED to adopt one of these mechanisms.

-

Note: If there is a requirement to communicate information about the verification status and identity assurance data of the claims about the subject, the syntax defined by [OIDF.ekyc-ida] SHOULD be used. It is up to each jurisdiction and ecosystem, whether to require it to the implementers of this profile.

-

Note: If there is a requirement to provide the Subject’s identifier assigned and maintained by the Issuer, the sub claim MAY be used. There is no requirement for a binding to exist between the sub and cnf claims. See the Implementation Considerations section in [I-D.ietf-oauth-sd-jwt-vc].

-

Note: In some credential types, it is not desirable to include an expiration date (eg: diploma attestation). Therefore, this profile leaves its inclusion to the Issuer, or the body defining the respective credential type.

-
-
-

-7.1. Issuer identification and key resolution to validate an issued Credential -

-

This profile supports two ways to represent and resolve the key required to validate the issuer signature of an SD-JWT VC, the web PKI-based key resolution and the x.509 certificates.

-
    -
  • Web-based key resolution: The key used to validate the Issuer’s signature on the SD-JWT VC MUST be obtained from the SD-JWT VC issuer's metadata as defined in Section 5 of [I-D.ietf-oauth-sd-jwt-vc]. The JOSE header kid MUST be used to identify the respective key. -
    • -
  • x.509 certificates: the SD-JWT VC contains the issuer's certificate along with a trust chain in the x5c JOSE header. In this case, the iss value MUST be an URL with a FQDN matching a dNSName Subject Alternative Name (SAN) [RFC5280] entry in the leaf certificate. -
    • -
-

Note: The issuer MAY decide to support both options. In which case, it is at the discretion of the Wallet and the Verifier which key to use for the issuer signature validation.

-
-
-

-7.1.1. Cryptographic Holder Binding between VC and VP -

-
    -
  • For Cryptographic Holder Binding, a KB-JWT, as defined in [I-D.ietf-oauth-sd-jwt-vc], MUST always be present when presenting an SD-JWT VC. -
    • -
-
-
-
-
-
-
-

-7.2. OpenID4VC Credential Format Profile -

-

This section specifies how SD-JWT VCs as defined in [I-D.ietf-oauth-sd-jwt-vc] are used in conjunction with the OpenID4VC specifications.

-
-
-

-7.2.1. Format Identifier -

-

The Credential format identifier is vc+sd-jwt. This format identifier is used in issuance and presentation requests.

-
-
-
-
-

-7.2.2. Credential Issuer Metadata -

-

The following additional Credential Issuer metadata are defined for this Credential format to be used in addition to those defined in Section 10.2 of [OIDF.OID4VCI].

-
    -
  • -

    credential_definition: REQUIRED. JSON object containing the detailed description of the credential type. It consists at least of the following three sub elements:

    -
      -
    • - vct: REQUIRED. JSON string designating the type of a credential as defined in [I-D.ietf-oauth-sd-jwt-vc], Section 4.2.2.1. -
      • -
    • -

      claims: OPTIONAL. A JSON object containing a list of name/value pairs, where each name identifies a claim offered in the Credential. The value can be another such object (nested data structures), or an array of such objects. To express the specifics about the claim, the most deeply nested value MAY be a JSON object that includes a following non-exhaustive list of parameters defined by this specification:

      -
        -
      • - mandatory: OPTIONAL. Boolean which when set to true indicates the claim MUST be present in the issued Credential. If the mandatory property is omitted its default should be assumed to be false. -
        • -
      • - value_type: OPTIONAL. String value determining type of value of the claim. A non-exhaustive list of valid values defined by this specification are string, number, and image media types such as image/jpeg as defined in IANA media type registry for images (https://www.iana.org/assignments/media-types/media-types.xhtml#image). -
        • -
      • -

        display: OPTIONAL. An array of objects, where each object contains display properties of a certain claim in the Credential for a certain language. Below is a non-exhaustive list of valid parameters that MAY be included:

        -
          -
        • - name: OPTIONAL. String value of a display name for the claim. -
          • -
        • - locale: OPTIONAL. String value that identifies language of this object represented as language tag values defined in BCP47 [RFC5646]. There MUST be only one object for each language identifier. -
          • -
        -
        • -
      -
      • -
    -
    • -
  • - order: OPTIONAL. An array of claims.display.name values that lists them in the order they should be displayed by the Wallet. -
    • -
-

The following is a non-normative example of an object comprising credentials_supported parameter of Credential format vc+sd-jwt.

-
-
{
-    "format": "vc+sd-jwt",
-    "scope": "IdentityCredential_SD-JWT-VC",
-    "cryptographic_binding_methods_supported": [
-        "did:example"
-    ],
-    "cryptographic_suites_supported": [
-        "ES256K"
-    ],
-    "display": [
-        {
-            "name": "IdentityCredential",
-            "locale": "en-US",
-            "background_color": "#12107c",
-            "text_color": "#FFFFFF"
-        }
-    ],
-    "credential_definition": {
-        "vct": "IdentityCredential",
-        "claims": {
-            "given_name": {
-                "display": [
-                    {
-                        "name": "Given Name",
-                        "locale": "en-US"
-                    },
-                    {
-                        "name": "Vorname",
-                        "locale": "de-DE"
-                    }
-                ]
-            },
-            "last_name": {
-                "display": [
-                    {
-                        "name": "Surname",
-                        "locale": "en-US"
-                    },
-                    {
-                        "name": "Nachname",
-                        "locale": "de-DE"
-                    }
-                ]
-            },
-            "email": {},
-            "phone_number": {},
-            "address": {
-                "street_address": {},
-                "locality": {},
-                "region": {},
-                "country": {}
-            },
-            "birthdate": {},
-            "is_over_18": {},
-            "is_over_21": {},
-            "is_over_65": {}
-        }
-    }
-}
-
-
-{
-    "vct": "IdentityCredential",
-    "given_name": "John",
-    "family_name": "Doe",
-}
-
-
-
-
-
-
-
-

-7.2.3. Credential Offer -

-

The following is a non-normative example of an object comprising credentials_supported parameter of Credential format vc+sd-jwt.

-
-
{
-    "credential_issuer": "https://credential-issuer.example.com",
-    "credentials": [
-        "IdentityCredential_SD-JWT-VC"
-    ],
-    "grants": {
-        "authorization_code": {
-            "issuer_state": "eyJhbGciOiJSU0Et...FYUaBy"
-        }
-    }
-}
-
-
-
-
-
-
-
-

-7.2.4. Authorization Details -

-

The following additional claims are defined for authorization details of type openid_credential and this Credential format.

-
    -
  • - credential_definition: REQUIRED. JSON object containing the detailed description of the credential type. It MUST contain at least vct property as defined in Section 7.2.2. It MAY contain claims property as defined in Section 7.2.2. -
    • -
-

The following is a non-normative example of an authorization details object with Credential format vc+sd-jwt.

-
-
[
-    {
-        "type": "openid_credential",
-        "format": "vc+sd-jwt",
-        "credential_definition": {
-            "vct": "IdentityCredential"
-        }
-    }
-]
-
-
-
-
-
-
-
-

-7.2.5. Credential Request -

-

The following additional parameters are defined for Credential Requests and this Credential format.

-
    -
  • - credential_definition: REQUIRED. JSON object containing the detailed description of the credential type. It MUST contain at least vct property as defined in Section 7.2.2. It MAY contain claims property as defined in Section 7.2.2. -
    • -
-

The following is a non-normative example of a Credential Request with Credential format vc+sd-jwt.

-
-
{
-   "format": "vc+sd-jwt",
-   "credential_definition": {
-      "vct": "IdentityCredential"
-   },
-   "proof": {
-      "proof_type": "jwt",
-      "jwt":"eyJraWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEva2V5cy8
-      xIiwiYWxnIjoiRVMyNTYiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR
-      0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJpYXQiOiIyMDE4LTA5LTE0VDIxOjE5OjEwWiIsIm5vbm
-      NlIjoidFppZ25zbkZicCJ9.ewdkIkPV50iOeBUqMXCC_aZKPxgihac0aW9EkL1nOzM"
-   }
-}
-
-
-
-
-
-
-
-

-7.2.6. Credential Response -

-

The value of the credential claim in the Credential Response MUST be a JSON string that is an SD-JWT VC. Credentials of this format are already suitable for transfer and, therefore, they need not and MUST NOT be re-encoded.

-

The following is a non-normative example of a Credential Response with Credential format vc+sd-jwt.

-
-
-
-
-

-7.2.7. Verifier Metadata -

-

The Verifier SHOULD add a vp_formats element to its metadata (e.g. in the client_metadata authorization request parameter) to let the wallet know what protection algorithms it supports in conjunction with SD-JWT VCs. The format element MUST have the key vc+sd-jwt, the value is an object consisting of the following elements:

-
    -
  • - sd-jwt_alg_values: OPTIONAL. A JSON array containing identifiers of cryptographic algorithms the verifier supports for protection of a SD-JWT. If present, the alg JOSE header (as defined in [RFC7515]) of the presented SD-JWT MUST match one of the array values. -
    • -
  • - kb-jwt_alg_values: OPTIONAL. A JSON array containing identifiers of cryptographic algorithms the verifier supports for protection of a KB-JWT. If present, the alg JOSE header (as defined in [RFC7515]) of the presented KB-JWT MUST match one of the array values. -
    • -
-

The following is a non-normative example of client_metadata request parameter value in a request to present a SD-JWT VC.

-
-
{
-    "vp_formats": {
-        "vc+sd-jwt": {
-            "sd-jwt_alg_values": [
-                "ES256",
-                "ES384"
-            ],
-            "kb-jwt_alg_values": [
-                "ES256",
-                "ES384"
-            ]
-        }
-    }
-}
-
-
-
-
-
-
-
-

-7.2.8. Presentation Definition -

-

The presentation of a SD-JWT VC is requested by adding an object named vc+sd-jwt to the format object of an input_descriptor. The object is empty.

-

The following is a non-normative example of a presentation definition for a SD-JWT VC.

-
-
{
-    "id": "d76c51b7-ea90-49bb-8368-6b3d194fc131",
-    "input_descriptors": [
-        {
-            "id": "IdentityCredential",
-            "format": {
-                "vc+sd-jwt": {}
-            },
-            "constraints": {
-                "limit_disclosure": "required",
-                "fields": [
-                    {
-                        "path": [
-                            "$.vct"
-                        ],
-                        "filter": {
-                            "type": "string",
-                            "const": "IdentityCredential"
-                        }
-                    },
-                    {
-                        "path": [
-                            "$.family_name"
-                        ]
-                    },
-                    {
-                        "path": [
-                            "$.given_name"
-                        ]
-                    }
-                ]
-            }
-        }
-    ]
-}
-
-
-
-
-
-
-
-
-
-
-
-

-8. 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:

- -

SHA256 MUST be supported by all the entities as the hash algorithm to generate and validate the digests in the SD-JWT VC.

-

Note: When using this profile with other cryptosuites, it is recommended to be explicit about which entity is required to support which curve for signing and/or signature validation

-
-
-
-
-

-9. Implementations Considerations -

-
-
-

-9.1. Validity Period of the Signature and the Claim Values -

-

iat and exp JWT claims express both the validity period of both the signature and the claims about the subject, unless there is a separate claim used to express the validity of the claims.

-
-
-
-
-
-

-10. References -

-
-

-10.1. Normative References -

-
-
[I-D.ietf-oauth-attestation-based-client-auth]
-
-Looker, T. and P. Bastian, "OAuth 2.0 Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-attestation-based-client-auth-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-01>.
-
-
[I-D.ietf-oauth-sd-jwt-vc]
-
-Terbu, O. and D. Fett, "SD-JWT-based Verifiable Credentials (SD-JWT VC)", Work in Progress, Internet-Draft, draft-ietf-oauth-sd-jwt-vc-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-01>.
-
-
[I-D.ietf-oauth-selective-disclosure-jwt]
-
-Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-Draft, draft-ietf-oauth-selective-disclosure-jwt-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-06>.
-
-
[I-D.ietf-oauth-status-list]
-
-Looker, T., Bastian, P., and C. Bormann, "OAuth Status List", Work in Progress, Internet-Draft, draft-ietf-oauth-status-list-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-status-list-00>.
-
-
[I-D.terbu-sd-jwt-vc]
-
-Terbu, O. and D. Fett, "SD-JWT-based Verifiable Credentials with JSON payloads (SD-JWT VC)", Work in Progress, Internet-Draft, draft-terbu-sd-jwt-vc-02, , <https://datatracker.ietf.org/doc/html/draft-terbu-sd-jwt-vc-02>.
-
-
[OIDF.OID4VCI]
-
-Lodderstedt, T., Yasuda, K., and T. Looker, "OpenID for Verifiable Credential Issuance", , <https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html>.
-
-
[OIDF.OID4VP]
-
-Terbu, O., Lodderstedt, T., Yasuda, K., Lemmon, A., and T. Looker, "OpenID for Verifiable Presentations", , <https://openid.net/specs/openid-4-verifiable-presentations-1_0.html>.
-
-
[OIDF.SIOPv2]
-
-Microsoft, Jones, M. B., and T. Lodderstedt, "Self-Issued OpenID Provider V2", , <https://openid.net/specs/openid-connect-self-issued-v2-1_0.html>.
-
-
[OIDF.ekyc-ida]
-
-yes, Fett, D., Haine, M., Pulido, A., Lehmann, K., and K. Koiwai, "OpenID Connect for Identity Assurance 1.0", , <https://openid.net/specs/openid-connect-4-identity-assurance-1_0-ID4.html>.
-
-
[RFC5280]
-
-Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/info/rfc5280>.
-
-
[RFC5646]
-
-Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, , <https://www.rfc-editor.org/info/rfc5646>.
-
-
[RFC7515]
-
-Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/info/rfc7515>.
-
-
[RFC7517]
-
-Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, , <https://www.rfc-editor.org/info/rfc7517>.
-
-
[RFC7519]
-
-Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/info/rfc7519>.
-
-
[RFC7636]
-
-Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, , <https://www.rfc-editor.org/info/rfc7636>.
-
-
[RFC7800]
-
-Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, , <https://www.rfc-editor.org/info/rfc7800>.
-
-
[RFC9101]
-
-Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)", RFC 9101, DOI 10.17487/RFC9101, , <https://www.rfc-editor.org/info/rfc9101>.
-
-
[RFC9126]
-
-Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, , <https://www.rfc-editor.org/info/rfc9126>.
-
-
[RFC9449]
-
-Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, , <https://www.rfc-editor.org/info/rfc9449>.
-
-
-
-
-

-10.2. Informative References -

-
-
[ISO.18013-5]
-
-ISO/IEC JTC 1/SC 17 Cards and security devices for personal identification, "ISO/IEC 18013-5:2021 Personal identification — ISO-compliant driving license — Part 5: Mobile driving license (mDL) application", , <https://www.iso.org/standard/69084.html>.
-
-
-
-
-
-
-

-Appendix A. Combined Issuance of SD-JWT VC and mdocs -

- -
-
-
-
-

-Appendix B. JSON Schema for the supported Presentation Definition properties -

-
-
{
-    "$schema": "http://json-schema.org/draft-07/schema#",
-    "title": "Presentation Definition for a High Assurance Profile",
-    "type": "object",
-    "properties": {
-      "presentation_definition": {
-        "$ref": "#/definitions/presentation_definition"
-      }
-    },
-    "definitions": {
-      "presentation_definition": {
-        "type": "object",
-        "properties": {
-          "id": {
-            "type": "string"
-          },
-          "input_descriptors": {
-            "type": "array",
-            "items": {
-              "$ref": "#/definitions/input_descriptor"
-            }
-          },
-          "submission_requirements": {
-            "type": "array",
-            "items": {
-              "$ref": "#/definitions/submission_requirement"
-            }
-          }
-        },
-        "required": [
-          "id",
-          "input_descriptors"
-        ],
-        "additionalProperties": false
-      },
-      "input_descriptor": {
-        "type": "object",
-        "additionalProperties": false,
-        "properties": {
-          "id": {
-            "type": "string"
-          },
-          "name": {
-            "type": "string"
-          },
-          "purpose": {
-            "type": "string"
-          },
-          "format": {
-            "$ref": "http://identity.foundation/claim-format-registry/schemas/presentation-definition-claim-format-designations.json"
-          },
-          "group": {
-            "type": "array",
-            "items": {
-              "type": "string"
-            }
-          },
-          "constraints": {
-            "type": "object",
-            "additionalProperties": false,
-            "properties": {
-              "limit_disclosure": {
-                "type": "string",
-                "enum": [
-                  "required",
-                  "preferred"
-                ]
-              },
-              "fields": {
-                "type": "array",
-                "items": {
-                  "path": {
-                    "type": "array",
-                    "items": {
-                      "type": "string"
-                    }
-                  },
-                  "filter": {
-                    "$ref": "http://json-schema.org/draft-07/schema#"
-                  }
-                }
-              }
-            }
-          }
-        },
-        "required": [
-          "id",
-          "constraints"
-        ]
-      },
-      "submission_requirement": {
-        "type": "object",
-        "oneOf": [
-          {
-            "properties": {
-              "name": {
-                "type": "string"
-              },
-              "rule": {
-                "type": "string",
-                "enum": [
-                  "pick"
-                ]
-              },
-              "count": {
-                "type": "integer",
-                "minimum": 1
-              },
-              "from": {
-                "type": "string"
-              }
-            },
-            "required": [
-              "rule",
-              "from"
-            ],
-            "additionalProperties": false
-          }
-        ]
-      }
-    }
-  }
-
-
-
-
-
-
-
-
-

-Authors' Addresses -

-
-
Kristina Yasuda
-
Microsoft
- -
-
-
Torsten Lodderstedt
-
sprind.org
- -
-
-
- - - diff --git a/78-sd-jwt-vc-credential-offer-leftovers/draft-oid4vc-haip-sd-jwt-vc.txt b/78-sd-jwt-vc-credential-offer-leftovers/draft-oid4vc-haip-sd-jwt-vc.txt deleted file mode 100644 index 05c1414..0000000 --- a/78-sd-jwt-vc-credential-offer-leftovers/draft-oid4vc-haip-sd-jwt-vc.txt +++ /dev/null @@ -1,1089 +0,0 @@ - - - - -OpenID Connect K. Yasuda - Microsoft - T. Lodderstedt - sprind.org - 23 November 2023 - - - OpenID4VC High Assurance Interoperability Profile with SD-JWT VC - draft-oid4vc-haip-sd-jwt-vc-latest - -Abstract - - This document defines a profile of OpenID for Verifiable Credentials - in combination with the credential format SD-JWT VC. The aim is to - select features and to define a set of requirements for the existing - specifications to enable interoperability among Issuers, Wallets and - Verifiers of Credentials where a high level of security and privacy - is required. The profiled specifications include OpenID for - Verifiable Credential Issuance [OIDF.OID4VCI], OpenID for Verifiable - Presentations [OIDF.OID4VP], Self-Issued OpenID Provider v2 - [OIDF.SIOPv2], and SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc]. - -Table of Contents - - 1. Introduction - 1.1. Audience Target audience/Usage - 2. Terminology - 3. Scope - 3.1. Out of Scope - 3.2. Scenarios/Business Requirements - 3.3. Standards Requirements - 4. OpenID for Verifiable Credential Issuance - 4.1. Credential Offer - 4.2. Authorization Endpoint - 4.3. Token Endpoint - 4.3.1. Wallet Attestation Schema - 4.4. Credential Endpoint - 4.5. Server Metadata - 5. OpenID for Verifiable Presentations - 6. Self-Issued OP v2 - 7. SD-JWT VCs - 7.1. Issuer identification and key resolution to validate an - issued Credential - 7.1.1. Cryptographic Holder Binding between VC and VP - 7.2. OpenID4VC Credential Format Profile - 7.2.1. Format Identifier - 7.2.2. Credential Issuer Metadata - 7.2.3. Credential Offer - 7.2.4. Authorization Details - 7.2.5. Credential Request - 7.2.6. Credential Response - 7.2.7. Verifier Metadata - 7.2.8. Presentation Definition - 8. Crypto Suites - 9. Implementations Considerations - 9.1. Validity Period of the Signature and the Claim Values - 10. References - 10.1. Normative References - 10.2. Informative References - Appendix A. Combined Issuance of SD-JWT VC and mdocs - Appendix B. JSON Schema for the supported Presentation Definition - properties - Authors' Addresses - -1. Introduction - - This document defines a set of requirements for the existing - specifications to enable interoperability among Issuers, Wallets and - Verifiers of Credentials where a high level of security and privacy - is required. This document is an interoperability profile that can - be used by implementations in various contexts, be it a certain - industry or a certain regulatory environment. - - This document is not a specification, but a profile. It refers to - the specifications required for implementations to interoperate among - each other and for the optionalities mentioned in the referenced - specifications, defines the set of features to be mandatory to - implement. - - The profile uses OpenID for Verifiable Credential Issuance - [OIDF.OID4VCI] and OpenID for Verifiable Presentations [OIDF.OID4VP] - as the base protocols for issuance and presentation of Credentials, - respectively. The credential format used is SD-JWT VC as specified - in [I-D.ietf-oauth-sd-jwt-vc]. Additionally, considerations are - given on how deployments can perform a combined issuance of - credentials in both SD-JWT VC and ISO mdoc [ISO.18013-5] formats. - - A full list of the open standards used in this profile can be found - in Overview of the Open Standards Requirements (reference). - -1.1. Audience Target audience/Usage - - The audience of the document is implementers that require a high - level of security and privacy for their solutions. A non-exhaustive - list of the interested parties includes eIDAS 2.0, California - Department of Motor Vehicles, Open Wallet Foundation (OWF), IDunion, - GAIN, and the Trusted Web project of the Japanese government, but is - expected to grow to include other jurisdictions and private sector - companies. - -2. Terminology - - This specification uses the terms "Holder", "Issuer", "Verifier", and - "Verifiable Credential" as defined in [I-D.ietf-oauth-sd-jwt-vc]. - -3. Scope - - The following aspects are in scope of this interoperability profile: - - * Protocol for issuance of the Verifiable Credentials (can be both - remote and in-person) (OID4VCI) - * Protocol for online presentation of Verifiable Credentials (can be - both remote and in-person) (OID4VP) - * Protocol for User Authentication by the Wallet at a Verifier (SIOP - v2) - * Wallet Attestation (during Credential issuance) - * Credential Format (SD-JWT VC) - * Status Management of the Credentials, including revocation - * Cryptographic Holder Binding - * Issuer key resolution - * Issuer identification (as prerequisite for trust management) - * Crypto Suites - - Assumptions made are the following: - - * The issuers and verifiers cannot pre-discover wallet’s capability - * The issuer is talking to the wallet supporting the features - defined in this profile (via wallet invocation mechanism) - * There are mechanisms in place for the verifiers and issuers to - discover each other’s capability - -3.1. Out of Scope - - The following items are out of scope for the current version of this - document, but might be added in future versions: - - * Trust Management, i.e. authorization of an issuer to issue certain - types of credentials, authorization of the Wallet to be issued - certain types of credentials, authorization of the Verifier to - receive certain types of credentials. - * Protocol for presentation of Verifiable Credentials for offline - use-cases, e.g. over BLE. - -3.2. Scenarios/Business Requirements - - * Combined Issuance of SD-JWT VC and mdoc - * Both issuer-initiated and wallet-initiated issuance - * eIDAS PID and (Q)EAA as defined in eIDAS ARF 1.0 - -3.3. Standards Requirements - - Unless explicitly stated, all normative requirements apply to all - participating entities: Issuers, Wallets and Verifiers. - - +==============================+========+========+==========+ - | (as defined in this profile) | Issuer | Wallet | Verifier | - +==============================+========+========+==========+ - | OID4VP | N/A | MUST | MUST | - +------------------------------+--------+--------+----------+ - | OID4VCI | MUST | MUST | N/A | - +------------------------------+--------+--------+----------+ - | SIOPv2 | N/A | MUST | SHOULD | - +------------------------------+--------+--------+----------+ - | SD-JWT VC profile as defined | MUST | MUST | MUST | - | in Section 7 | | | | - +------------------------------+--------+--------+----------+ - - Table 1 - -4. OpenID for Verifiable Credential Issuance - - Implementations of this profile: - - * MUST support both pre-auth code flow and authorization code flow. - * MUST support protocol extensions for the SD-JWT VC credential - format profile as defined in Section 7.2. - * MUST support sender-constrained tokens using the mechanism defined - in [RFC9449]. - * MUST support [RFC7636] with S256 as the code challenge method. - - Both Wallet initiated and Issuer initiated issuance is supported. - -4.1. Credential Offer - - * The Grant Types authorization_code and - urn:ietf:params:oauth:grant-type:pre-authorized_code MUST be - supported as defined in Section 4.1.1 in [OIDF.OID4VCI] - * For Grant Type authorization_code, the Issuer MUST include a scope - value in order to allow the Wallet to identify the desired - credential type. The wallet MUST use that value in the scope - Authorization parameter. For Grant Type - urn:ietf:params:oauth:grant-type:pre-authorized_code, the pre- - authorized code is used by the issuer to identify the credential - type(s). - * 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. - - Note: The Authorization Code flow does not require a Credential Offer - from the Issuer to the Wallet. However, it is included in the - feature set of the Credential Offer because it might be easier to - implement with existing libraries and on top of existing - implementations than the pre-authorized code Grant Type. - - Both sending Credential Offer same-device and cross-device is - supported. - -4.2. Authorization Endpoint - - * MUST use Pushed Authorization Requests (PAR) [RFC9126] to send the - Authorization Request. - * Wallets MUST authenticate itself at the PAR endpoint using the - same rules as defined in Section 4.3 for client authentication at - the token endpoint. - * MUST use the scope parameter to communicate credential type(s) to - be issued. The scope value MUST map to a specific Credential - type. The scope value may be pre-agreed, obtained from the - Credential Offer, or the Credential Issuer Metadata. - * The client_id value in the PAR request MUST be a string that the - Wallet has used as the sub value in the client attestation JWT. - -4.3. Token Endpoint - - * The Wallets MUST perform client authentication as defined in - [I-D.ietf-oauth-attestation-based-client-auth]. - * Refresh tokens MUST be supported for credential refresh. - * Wallets MUST support deferred authorization by being able to - process the Token error response parameters authorization_pending - and slow_down, and the credential offer parameter interval. - * The Wallet Attestation JWT scheme is defined in Section 4.3.1. - - Note: It is RECOMMENDED to use ephemeral client attestation JWTs for - client authentication in order to prevent linkability across - Credential Issuers. - - Note: Issuers should be mindful of how long the usage of the refresh - token is allowed to refresh a credential, as opposed to starting the - issuance flow from the beginning. For example, if the User is trying - to refresh a credential more than a year after its original issuance, - the usage of the refresh tokens is NOT RECOMMENDED. - -4.3.1. Wallet Attestation Schema - - Wallets MUST use attestations following the definition given in - [I-D.ietf-oauth-attestation-based-client-auth]. - - In addition to this definition, the Wallet Attestation MAY contain - the following claims in the cnf element: - - * key_type: OPTIONAL. JSON String that asserts the security - mechanism the Wallet uses to manage the private key associated - with the public key given in the cnf claim. This mechanism is - based on the capabilities of the execution environent of the - Wallet, this might be a secure element (in case of a wallet - residing on a smartphone) or a Cloud-HSM (in case of a cloud - Wallet). This specification defines the following values for - key_type: - - software: It MUST be used when the Wallet uses software-based - key management. - - hardware: It MUST be used when the wallet uses hardware-based - key management. - - tee: It SHOULD be used when the Wallet uses the Trusted - Execution Environment for key management. - - secure_enclave: It SHOULD be used when the Wallet uses the - Secure Enclave for key management. - - strong_box: It SHOULD be used when the Wallet uses the - Strongbox for key management. - - secure_element: It SHOULD be used when the Wallet uses a Secure - Element for key management. - - hsm: It SHOULD be used when the Wallet uses Hardware Security - Module (HSM). - * user_authentication: OPTIONAL. JSON String that asserts the - security mechanism the Wallet uses to authenticate the user to - authorize access to the private key associated with the public key - given in the cnf claim. This specification defines the following - values for user_authentication: - - system_biometry: It MUST be used when the key usage is - authorized by the mobile operating system using a biometric - factor. - - system_pin: It MUST be used when the key usage is authorized by - the mobile operating system using personal identification - number (PIN). - - internal_biometry: It MUST be used when the key usage is - authorized by the Wallet using a biometric factor. - - internal_pin: It MUST be used when the key usage is authorized - by the Wallet using PIN. - - secure_element_pin It MUST be used when the key usage is - authorized by the secure element managing the key itself using - PIN. - - The Wallet Attestation MAY also contain the following claim: - - * aal: OPTIONAL. JSON String asserting the authentication level of - the Wallet and the key as asserted in the cnf claim. - - To obtain the issuer's Public key for verification, wallet attestions - MUST support web-based key resolution as defined in Section 5 of - [I-D.terbu-sd-jwt-vc]. The JOSE header kid MUST be used to identify - the respective key. - - This is an example of a Wallet Instance Attestation: - - { - "typ": "wallet-attestation+jwt", - "alg": "ES256", - "kid": "1" - } - . - { - "iss": "", - "sub": "<`client_id` of the OAuth client>", - "iat": 1516247022, - "exp": 1541493724, - "aal" : "https://trust-list.eu/aal/high", - "cnf": { - "jwk": { - "kty": "EC", - "crv": "P-256", - "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", - "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" - }, - "key_type": "strong_box", - "user_authentication": "system_pin", - } - } - -4.4. Credential Endpoint - - * The JWT proof type MUST be supported. - -4.5. Server Metadata - - * The Credential Issuer MUST publish a mapping of every Credential - Type it supports to a scope value. - -5. OpenID for Verifiable Presentations - - * MUST support protocol extensions for SD-JWT VC credential format - profile as defined in this specification Section 7.2. - - * 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. - - * Response type MUST be vp_token. - - * Response mode MUST be direct_post with redirect_uri as defined in - Section 6.2 of [OIDF.OID4VP]. - - * Authorization Request MUST be sent using the request_uri parameter - as defined in JWT-Secured Authorization Request (JAR) [RFC9101]. - - * client_id_scheme parameter MUST be present in the Authorization - Request. - - * client_id_scheme value MUST be either x509_san_dns or - verifier_attestation. The Wallet MUST support both. The Verifier - MUST support at least one. - - * To obtain the issuer's public key for verification, verifiers MUST - support Web-based key resolution, as defined in Section 5 of - [I-D.ietf-oauth-sd-jwt-vc]. The JOSE header kid MUST be used to - identify the respective key. - - * Presentation Definition JSON object MUST be sent using a - presentation_definition parameter. - - * The following features from the DIF Presentation Exchange v2.0.0 - MUST be supported. A JSON schema for the supported features is in - Appendix B: - - - In the presentation_definition object, id, input_descriptors - and submission_requirements properties MUST be supported. - - In the input-descriptors object, id, name, purpose, group, - format, and constraints properties MUST be supported. In the - constraints object, limit_disclosure, and fields properties - MUST be supported. In the fields object, path and filter - properties MUST be supported. A path MUST contain exactly one - entry with a static path to a certain claim. A filter MUST - only contain type elements of value string and const elements. - - In the submission_requirements object, name, rule (pickonly), - count, from properties MUST be supported. - -6. Self-Issued OP v2 - - To authenticate the user, subject identifier in a Self-Issued ID - Token MUST be used as defined in [OIDF.SIOPv2]. - - * 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 - -7. SD-JWT VCs - - 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. - - * 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) - - +========+===========================+==============================+ - | Claim | SD-JWT as issued | Normative Definition | - | | by the Issuer | | - +========+===========================+==============================+ - | iss | MUST | [RFC7519], Section 4.1.1 | - +--------+---------------------------+------------------------------+ - | iat | MUST | [RFC7519], Section 4.1.6 | - +--------+---------------------------+------------------------------+ - | exp | SHOULD (at the | [RFC7519], Section 4.1.4 | - | | discretion of | | - | | the issuer) | | - +--------+---------------------------+------------------------------+ - | cnf | MUST | [RFC7800] | - +--------+---------------------------+------------------------------+ - | vct | MUST | [I-D.ietf-oauth-sd-jwt-vc] | - +--------+---------------------------+------------------------------+ - | status | SHOULD (at the | [I-D.ietf-oauth-status-list] | - | | discretion of | | - | | the issuer) | | - +--------+---------------------------+------------------------------+ - - Table 2 - - * 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 iss claim MUST be an HTTPS URL. The iss value is used to - obtain Issuer’s signing key as defined in Section 7.1. - * 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. - - 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 - (https://bitbucket.org/openid/connect/issues/1537/presenting-vc- - without-a-vp-using-openid4vp) - - Note: Re-using the same Credential across Verifiers, or re-using the - same JWK value across multiple Credentials gives colluding Verifiers - a mechanism to correlate the User. There are currently two known - ways to address this with SD-JWT VCs. First is to issue multiple - instances of the same credentials with different JWK values, so that - if each instance of the credential is used at only one Verifier, it - can be reused multiple times. Another is to use each credential only - once (ephemeral credentials). It is RECOMMENDED to adopt one of - these mechanisms. - - Note: If there is a requirement to communicate information about the - verification status and identity assurance data of the claims about - the subject, the syntax defined by [OIDF.ekyc-ida] SHOULD be used. - It is up to each jurisdiction and ecosystem, whether to require it to - the implementers of this profile. - - Note: If there is a requirement to provide the Subject’s identifier - assigned and maintained by the Issuer, the sub claim MAY be used. - There is no requirement for a binding to exist between the sub and - cnf claims. See the Implementation Considerations section in - [I-D.ietf-oauth-sd-jwt-vc]. - - Note: In some credential types, it is not desirable to include an - expiration date (eg: diploma attestation). Therefore, this profile - leaves its inclusion to the Issuer, or the body defining the - respective credential type. - -7.1. Issuer identification and key resolution to validate an issued - Credential - - This profile supports two ways to represent and resolve the key - required to validate the issuer signature of an SD-JWT VC, the web - PKI-based key resolution and the x.509 certificates. - - * Web-based key resolution: The key used to validate the Issuer’s - signature on the SD-JWT VC MUST be obtained from the SD-JWT VC - issuer's metadata as defined in Section 5 of - [I-D.ietf-oauth-sd-jwt-vc]. The JOSE header kid MUST be used to - identify the respective key. - * x.509 certificates: the SD-JWT VC contains the issuer's - certificate along with a trust chain in the x5c JOSE header. In - this case, the iss value MUST be an URL with a FQDN matching a - dNSName Subject Alternative Name (SAN) [RFC5280] entry in the leaf - certificate. - - Note: The issuer MAY decide to support both options. In which case, - it is at the discretion of the Wallet and the Verifier which key to - use for the issuer signature validation. - -7.1.1. Cryptographic Holder Binding between VC and VP - - * For Cryptographic Holder Binding, a KB-JWT, as defined in - [I-D.ietf-oauth-sd-jwt-vc], MUST always be present when presenting - an SD-JWT VC. - -7.2. OpenID4VC Credential Format Profile - - This section specifies how SD-JWT VCs as defined in - [I-D.ietf-oauth-sd-jwt-vc] are used in conjunction with the OpenID4VC - specifications. - -7.2.1. Format Identifier - - The Credential format identifier is vc+sd-jwt. This format - identifier is used in issuance and presentation requests. - -7.2.2. Credential Issuer Metadata - - The following additional Credential Issuer metadata are defined for - this Credential format to be used in addition to those defined in - Section 10.2 of [OIDF.OID4VCI]. - - * credential_definition: REQUIRED. JSON object containing the - detailed description of the credential type. It consists at least - of the following three sub elements: - - vct: REQUIRED. JSON string designating the type of a - credential as defined in [I-D.ietf-oauth-sd-jwt-vc], - Section 4.2.2.1. - - claims: OPTIONAL. A JSON object containing a list of name/ - value pairs, where each name identifies a claim offered in the - Credential. The value can be another such object (nested data - structures), or an array of such objects. To express the - specifics about the claim, the most deeply nested value MAY be - a JSON object that includes a following non-exhaustive list of - parameters defined by this specification: - o mandatory: OPTIONAL. Boolean which when set to true - indicates the claim MUST be present in the issued - Credential. If the mandatory property is omitted its - default should be assumed to be false. - o value_type: OPTIONAL. String value determining type of - value of the claim. A non-exhaustive list of valid values - defined by this specification are string, number, and image - media types such as image/jpeg as defined in IANA media type - registry for images (https://www.iana.org/assignments/media- - types/media-types.xhtml#image - (https://www.iana.org/assignments/media-types/media- - types.xhtml#image)). - o display: OPTIONAL. An array of objects, where each object - contains display properties of a certain claim in the - Credential for a certain language. Below is a non- - exhaustive list of valid parameters that MAY be included: - + name: OPTIONAL. String value of a display name for the - claim. - + locale: OPTIONAL. String value that identifies language - of this object represented as language tag values defined - in BCP47 [RFC5646]. There MUST be only one object for - each language identifier. - * order: OPTIONAL. An array of claims.display.name values that - lists them in the order they should be displayed by the Wallet. - - The following is a non-normative example of an object comprising - credentials_supported parameter of Credential format vc+sd-jwt. - - { - "format": "vc+sd-jwt", - "scope": "IdentityCredential_SD-JWT-VC", - "cryptographic_binding_methods_supported": [ - "did:example" - ], - "cryptographic_suites_supported": [ - "ES256K" - ], - "display": [ - { - "name": "IdentityCredential", - "locale": "en-US", - "background_color": "#12107c", - "text_color": "#FFFFFF" - } - ], - "credential_definition": { - "vct": "IdentityCredential", - "claims": { - "given_name": { - "display": [ - { - "name": "Given Name", - "locale": "en-US" - }, - { - "name": "Vorname", - "locale": "de-DE" - } - ] - }, - "last_name": { - "display": [ - { - "name": "Surname", - "locale": "en-US" - }, - { - "name": "Nachname", - "locale": "de-DE" - } - ] - }, - "email": {}, - "phone_number": {}, - "address": { - "street_address": {}, - "locality": {}, - "region": {}, - "country": {} - }, - "birthdate": {}, - "is_over_18": {}, - "is_over_21": {}, - "is_over_65": {} - } - } - } - - - { - "vct": "IdentityCredential", - "given_name": "John", - "family_name": "Doe", - } - -7.2.3. Credential Offer - - The following is a non-normative example of an object comprising - credentials_supported parameter of Credential format vc+sd-jwt. - - { - "credential_issuer": "https://credential-issuer.example.com", - "credentials": [ - "IdentityCredential_SD-JWT-VC" - ], - "grants": { - "authorization_code": { - "issuer_state": "eyJhbGciOiJSU0Et...FYUaBy" - } - } - } - -7.2.4. Authorization Details - - The following additional claims are defined for authorization details - of type openid_credential and this Credential format. - - * credential_definition: REQUIRED. JSON object containing the - detailed description of the credential type. It MUST contain at - least vct property as defined in Section 7.2.2. It MAY contain - claims property as defined in Section 7.2.2. - - The following is a non-normative example of an authorization details - object with Credential format vc+sd-jwt. - - [ - { - "type": "openid_credential", - "format": "vc+sd-jwt", - "credential_definition": { - "vct": "IdentityCredential" - } - } - ] - -7.2.5. Credential Request - - The following additional parameters are defined for Credential - Requests and this Credential format. - - * credential_definition: REQUIRED. JSON object containing the - detailed description of the credential type. It MUST contain at - least vct property as defined in Section 7.2.2. It MAY contain - claims property as defined in Section 7.2.2. - - The following is a non-normative example of a Credential Request with - Credential format vc+sd-jwt. - - { - "format": "vc+sd-jwt", - "credential_definition": { - "vct": "IdentityCredential" - }, - "proof": { - "proof_type": "jwt", - "jwt":"eyJraWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEva2V5cy8 - xIiwiYWxnIjoiRVMyNTYiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR - 0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJpYXQiOiIyMDE4LTA5LTE0VDIxOjE5OjEwWiIsIm5vbm - NlIjoidFppZ25zbkZicCJ9.ewdkIkPV50iOeBUqMXCC_aZKPxgihac0aW9EkL1nOzM" - } - } - -7.2.6. Credential Response - - The value of the credential claim in the Credential Response MUST be - a JSON string that is an SD-JWT VC. Credentials of this format are - already suitable for transfer and, therefore, they need not and MUST - NOT be re-encoded. - - The following is a non-normative example of a Credential Response - with Credential format vc+sd-jwt. - -7.2.7. Verifier Metadata - - The Verifier SHOULD add a vp_formats element to its metadata (e.g. in - the client_metadata authorization request parameter) to let the - wallet know what protection algorithms it supports in conjunction - with SD-JWT VCs. The format element MUST have the key vc+sd-jwt, the - value is an object consisting of the following elements: - - * sd-jwt_alg_values: OPTIONAL. A JSON array containing identifiers - of cryptographic algorithms the verifier supports for protection - of a SD-JWT. If present, the alg JOSE header (as defined in - [RFC7515]) of the presented SD-JWT MUST match one of the array - values. - * kb-jwt_alg_values: OPTIONAL. A JSON array containing identifiers - of cryptographic algorithms the verifier supports for protection - of a KB-JWT. If present, the alg JOSE header (as defined in - [RFC7515]) of the presented KB-JWT MUST match one of the array - values. - - The following is a non-normative example of client_metadata request - parameter value in a request to present a SD-JWT VC. - - { - "vp_formats": { - "vc+sd-jwt": { - "sd-jwt_alg_values": [ - "ES256", - "ES384" - ], - "kb-jwt_alg_values": [ - "ES256", - "ES384" - ] - } - } - } - -7.2.8. Presentation Definition - - The presentation of a SD-JWT VC is requested by adding an object - named vc+sd-jwt to the format object of an input_descriptor. The - object is empty. - - The following is a non-normative example of a presentation definition - for a SD-JWT VC. - - { - "id": "d76c51b7-ea90-49bb-8368-6b3d194fc131", - "input_descriptors": [ - { - "id": "IdentityCredential", - "format": { - "vc+sd-jwt": {} - }, - "constraints": { - "limit_disclosure": "required", - "fields": [ - { - "path": [ - "$.vct" - ], - "filter": { - "type": "string", - "const": "IdentityCredential" - } - }, - { - "path": [ - "$.family_name" - ] - }, - { - "path": [ - "$.given_name" - ] - } - ] - } - } - ] - } - -8. 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 - * Wallet Instance Attestation - * DPoP - * HB 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. - - Note: When using this profile with other cryptosuites, it is - recommended to be explicit about which entity is required to support - which curve for signing and/or signature validation - -9. Implementations Considerations - -9.1. Validity Period of the Signature and the Claim Values - - iat and exp JWT claims express both the validity period of both the - signature and the claims about the subject, unless there is a - separate claim used to express the validity of the claims. - -10. References - -10.1. Normative References - - [I-D.ietf-oauth-attestation-based-client-auth] - Looker, T. and P. Bastian, "OAuth 2.0 Attestation-Based - Client Authentication", Work in Progress, Internet-Draft, - draft-ietf-oauth-attestation-based-client-auth-01, 23 - October 2023, . - - [I-D.ietf-oauth-sd-jwt-vc] - Terbu, O. and D. Fett, "SD-JWT-based Verifiable - Credentials (SD-JWT VC)", Work in Progress, Internet- - Draft, draft-ietf-oauth-sd-jwt-vc-01, 23 October 2023, - . - - [I-D.ietf-oauth-selective-disclosure-jwt] - Fett, D., Yasuda, K., and B. Campbell, "Selective - Disclosure for JWTs (SD-JWT)", Work in Progress, Internet- - Draft, draft-ietf-oauth-selective-disclosure-jwt-06, 23 - October 2023, . - - [I-D.ietf-oauth-status-list] - Looker, T., Bastian, P., and C. Bormann, "OAuth Status - List", Work in Progress, Internet-Draft, draft-ietf-oauth- - status-list-00, 23 October 2023, - . - - [I-D.terbu-sd-jwt-vc] - Terbu, O. and D. Fett, "SD-JWT-based Verifiable - Credentials with JSON payloads (SD-JWT VC)", Work in - Progress, Internet-Draft, draft-terbu-sd-jwt-vc-02, 26 May - 2023, . - - [OIDF.OID4VCI] - Lodderstedt, T., Yasuda, K., and T. Looker, "OpenID for - Verifiable Credential Issuance", 20 June 2022, - . - - [OIDF.OID4VP] - Terbu, O., Lodderstedt, T., Yasuda, K., Lemmon, A., and T. - Looker, "OpenID for Verifiable Presentations", 20 June - 2022, . - - [OIDF.SIOPv2] - Microsoft, Jones, M. B., and T. Lodderstedt, "Self-Issued - OpenID Provider V2", 18 December 2021, - . - - [OIDF.ekyc-ida] - yes, Fett, D., Haine, M., Pulido, A., Lehmann, K., and K. - Koiwai, "OpenID Connect for Identity Assurance 1.0", 19 - August 2022, . - - [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., - Housley, R., and W. Polk, "Internet X.509 Public Key - Infrastructure Certificate and Certificate Revocation List - (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, - . - - [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying - Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, - September 2009, . - - [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web - Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May - 2015, . - - [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, - DOI 10.17487/RFC7517, May 2015, - . - - [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token - (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, - . - - [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key - for Code Exchange by OAuth Public Clients", RFC 7636, - DOI 10.17487/RFC7636, September 2015, - . - - [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- - Possession Key Semantics for JSON Web Tokens (JWTs)", - RFC 7800, DOI 10.17487/RFC7800, April 2016, - . - - [RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 - Authorization Framework: JWT-Secured Authorization Request - (JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021, - . - - [RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., - and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", - RFC 9126, DOI 10.17487/RFC9126, September 2021, - . - - [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., - Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of - Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, - September 2023, . - -10.2. Informative References - - [ISO.18013-5] - ISO/IEC JTC 1/SC 17 Cards and security devices for - personal identification, "ISO/IEC 18013-5:2021 Personal - identification — ISO-compliant driving license — Part 5: - Mobile driving license (mDL) application", 2021, - . - -Appendix A. Combined Issuance of SD-JWT VC and mdocs - - * If combined issuance is required, the Batch Credential Endpoint - MUST be supported. - -Appendix B. JSON Schema for the supported Presentation Definition - properties - - { - "$schema": "http://json-schema.org/draft-07/schema#", - "title": "Presentation Definition for a High Assurance Profile", - "type": "object", - "properties": { - "presentation_definition": { - "$ref": "#/definitions/presentation_definition" - } - }, - "definitions": { - "presentation_definition": { - "type": "object", - "properties": { - "id": { - "type": "string" - }, - "input_descriptors": { - "type": "array", - "items": { - "$ref": "#/definitions/input_descriptor" - } - }, - "submission_requirements": { - "type": "array", - "items": { - "$ref": "#/definitions/submission_requirement" - } - } - }, - "required": [ - "id", - "input_descriptors" - ], - "additionalProperties": false - }, - "input_descriptor": { - "type": "object", - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "name": { - "type": "string" - }, - "purpose": { - "type": "string" - }, - "format": { - "$ref": "http://identity.foundation/claim-format-registry/schemas/presentation-definition-claim-format-designations.json" - }, - "group": { - "type": "array", - "items": { - "type": "string" - } - }, - "constraints": { - "type": "object", - "additionalProperties": false, - "properties": { - "limit_disclosure": { - "type": "string", - "enum": [ - "required", - "preferred" - ] - }, - "fields": { - "type": "array", - "items": { - "path": { - "type": "array", - "items": { - "type": "string" - } - }, - "filter": { - "$ref": "http://json-schema.org/draft-07/schema#" - } - } - } - } - } - }, - "required": [ - "id", - "constraints" - ] - }, - "submission_requirement": { - "type": "object", - "oneOf": [ - { - "properties": { - "name": { - "type": "string" - }, - "rule": { - "type": "string", - "enum": [ - "pick" - ] - }, - "count": { - "type": "integer", - "minimum": 1 - }, - "from": { - "type": "string" - } - }, - "required": [ - "rule", - "from" - ], - "additionalProperties": false - } - ] - } - } - } - -Authors' Addresses - - Kristina Yasuda - Microsoft - Email: kristina.yasuda@microsoft.com - - - Torsten Lodderstedt - sprind.org - Email: torsten@lodderstedt.net diff --git a/78-sd-jwt-vc-credential-offer-leftovers/index.html b/78-sd-jwt-vc-credential-offer-leftovers/index.html deleted file mode 100644 index 6992851..0000000 --- a/78-sd-jwt-vc-credential-offer-leftovers/index.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - vcstuff/oid4vc-haip-sd-jwt-vc 78-sd-jwt-vc-credential-offer-leftovers preview - - - - -

Editor's drafts for 78-sd-jwt-vc-credential-offer-leftovers branch of vcstuff/oid4vc-haip-sd-jwt-vc

- - - - - - -
oid4vc-haip-sd-jwt-vcplain textsame as main
- - - diff --git a/draft-oid4vc-haip-sd-jwt-vc.html b/draft-oid4vc-haip-sd-jwt-vc.html index c241e4f..4e3a4e9 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.html +++ b/draft-oid4vc-haip-sd-jwt-vc.html @@ -10,25 +10,25 @@ - + @@ -1044,7 +1044,7 @@
OpenID Connect
Published:
- +
Authors:
@@ -2059,7 +2059,7 @@

[I-D.ietf-oauth-selective-disclosure-jwt]
-Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-Draft, draft-ietf-oauth-selective-disclosure-jwt-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-06>.
+Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-Draft, draft-ietf-oauth-selective-disclosure-jwt-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-07>.

[I-D.ietf-oauth-status-list]
diff --git a/draft-oid4vc-haip-sd-jwt-vc.txt b/draft-oid4vc-haip-sd-jwt-vc.txt index fdf3fea..264760f 100644 --- a/draft-oid4vc-haip-sd-jwt-vc.txt +++ b/draft-oid4vc-haip-sd-jwt-vc.txt @@ -6,7 +6,7 @@ OpenID Connect K. Yasuda Microsoft T. Lodderstedt sprind.org - 3 December 2023 + 28 December 2023 OpenID4VC High Assurance Interoperability Profile with SD-JWT VC @@ -855,9 +855,9 @@ Table of Contents [I-D.ietf-oauth-selective-disclosure-jwt] Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JWTs (SD-JWT)", Work in Progress, Internet- - Draft, draft-ietf-oauth-selective-disclosure-jwt-06, 23 - October 2023, . + Draft, draft-ietf-oauth-selective-disclosure-jwt-07, 11 + December 2023, . [I-D.ietf-oauth-status-list] Looker, T., Bastian, P., and C. Bormann, "OAuth Status diff --git a/index.html b/index.html index ef2351a..c91ac06 100644 --- a/index.html +++ b/index.html @@ -17,8 +17,8 @@

Editor's drafts for main branch of saved issues, or the latest GitHub issues and pull requests in the repo.

- - + + @@ -27,37 +27,11 @@

Editor's drafts for main branch of adopt-draft-naming

oid4vc-haip-sd-jwt-vcplain textoid4vc-haip-sd-jwt-vcplain text datatracker diff with last submission
- - + +
oid4vc-haip-sd-jwt-vcplain textoid4vc-haip-sd-jwt-vcplain text diff with main
-

Preview for branch pb

-

Preview for branch pb/issuerMetadata

- - - - - - -
oid4vc-haip-sd-jwt-vcplain textdiff with main
-

Preview for branch tl

-

Preview for branch tl/change_affiliation

- - - - - - -
oid4vc-haip-sd-jwt-vcplain textdiff with main
-

Preview for branch 78-sd-jwt-vc-credential-offer-leftovers

- - - - - - -
oid4vc-haip-sd-jwt-vcplain textdiff with main
- - diff --git a/pb/issuerMetadata/draft-oid4vc-haip-sd-jwt-vc.txt b/pb/issuerMetadata/draft-oid4vc-haip-sd-jwt-vc.txt deleted file mode 100644 index 010458c..0000000 --- a/pb/issuerMetadata/draft-oid4vc-haip-sd-jwt-vc.txt +++ /dev/null @@ -1,1102 +0,0 @@ - - - - -OpenID Connect K. Yasuda - Microsoft - T. Lodderstedt - yes.com - 14 November 2023 - - - OpenID4VC High Assurance Interoperability Profile with SD-JWT VC - draft-oid4vc-haip-sd-jwt-vc-latest - -Abstract - - This document defines a profile of OpenID for Verifiable Credentials - in combination with the credential format SD-JWT VC. The aim is to - select features and to define a set of requirements for the existing - specifications to enable interoperability among Issuers, Wallets and - Verifiers of Credentials where a high level of security and privacy - is required. The profiled specifications include OpenID for - Verifiable Credential Issuance [OIDF.OID4VCI], OpenID for Verifiable - Presentations [OIDF.OID4VP], Self-Issued OpenID Provider v2 - [OIDF.SIOPv2], and SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc]. - -Table of Contents - - 1. Introduction - 1.1. Audience Target audience/Usage - 2. Terminology - 3. Scope - 3.1. Out of Scope - 3.2. Scenarios/Business Requirements - 3.3. Standards Requirements - 4. OpenID for Verifiable Credential Issuance - 4.1. Credential Offer - 4.2. Authorization Endpoint - 4.3. Token Endpoint - 4.3.1. Wallet Attestation Schema - 4.4. Credential Endpoint - 4.5. Server Metadata - 5. OpenID for Verifiable Presentations - 6. Self-Issued OP v2 - 7. SD-JWT VCs - 7.1. Issuer identification and key resolution to validate an - issued Credential - 7.1.1. Cryptographic Holder Binding between VC and VP - 7.2. OpenID4VC Credential Format Profile - 7.2.1. Format Identifier - 7.2.2. Credential Issuer Metadata - 7.2.3. Credential Offer - 7.2.4. Authorization Details - 7.2.5. Credential Request - 7.2.6. Credential Response - 7.2.7. Verifier Metadata - 7.2.8. Presentation Definition - 8. Crypto Suites - 9. Implementations Considerations - 9.1. Validity Period of the Signature and the Claim Values - 10. References - 10.1. Normative References - 10.2. Informative References - Appendix A. Combined Issuance of SD-JWT VC and mdocs - Appendix B. JSON Schema for the supported Presentation Definition - properties - Authors' Addresses - -1. Introduction - - This document defines a set of requirements for the existing - specifications to enable interoperability among Issuers, Wallets and - Verifiers of Credentials where a high level of security and privacy - is required. This document is an interoperability profile that can - be used by implementations in various contexts, be it a certain - industry or a certain regulatory environment. - - This document is not a specification, but a profile. It refers to - the specifications required for implementations to interoperate among - each other and for the optionalities mentioned in the referenced - specifications, defines the set of features to be mandatory to - implement. - - The profile uses OpenID for Verifiable Credential Issuance - [OIDF.OID4VCI] and OpenID for Verifiable Presentations [OIDF.OID4VP] - as the base protocols for issuance and presentation of Credentials, - respectively. The credential format used is SD-JWT VC as specified - in [I-D.ietf-oauth-sd-jwt-vc]. Additionally, considerations are - given on how deployments can perform a combined issuance of - credentials in both SD-JWT VC and ISO mdoc [ISO.18013-5] formats. - - A full list of the open standards used in this profile can be found - in Overview of the Open Standards Requirements (reference). - -1.1. Audience Target audience/Usage - - The audience of the document is implementers that require a high - level of security and privacy for their solutions. A non-exhaustive - list of the interested parties includes eIDAS 2.0, California - Department of Motor Vehicles, Open Wallet Foundation (OWF), IDunion, - GAIN, and the Trusted Web project of the Japanese government, but is - expected to grow to include other jurisdictions and private sector - companies. - -2. Terminology - - This specification uses the terms "Holder", "Issuer", "Verifier", and - "Verifiable Credential" as defined in [I-D.ietf-oauth-sd-jwt-vc]. - -3. Scope - - The following aspects are in scope of this interoperability profile: - - * Protocol for issuance of the Verifiable Credentials (can be both - remote and in-person) (OID4VCI) - * Protocol for online presentation of Verifiable Credentials (can be - both remote and in-person) (OID4VP) - * Protocol for User Authentication by the Wallet at a Verifier (SIOP - v2) - * Wallet Attestation (during Credential issuance) - * Credential Format (SD-JWT VC) - * Status Management of the Credentials, including revocation - * Cryptographic Holder Binding - * Issuer key resolution - * Issuer identification (as prerequisite for trust management) - * Crypto Suites - - Assumptions made are the following: - - * The issuers and verifiers cannot pre-discover wallet’s capability - * The issuer is talking to the wallet supporting the features - defined in this profile (via wallet invocation mechanism) - * There are mechanisms in place for the verifiers and issuers to - discover each other’s capability - -3.1. Out of Scope - - The following items are out of scope for the current version of this - document, but might be added in future versions: - - * Trust Management, i.e. authorization of an issuer to issue certain - types of credentials, authorization of the Wallet to be issued - certain types of credentials, authorization of the Verifier to - receive certain types of credentials. - * Protocol for presentation of Verifiable Credentials for offline - use-cases, e.g. over BLE. - -3.2. Scenarios/Business Requirements - - * Combined Issuance of SD-JWT VC and mdoc - * Both issuer-initiated and wallet-initiated issuance - * eIDAS PID and (Q)EAA as defined in eIDAS ARF 1.0 - -3.3. Standards Requirements - - Unless explicitly stated, all normative requirements apply to all - participating entities: Issuers, Wallets and Verifiers. - - +==============================+========+========+==========+ - | (as defined in this profile) | Issuer | Wallet | Verifier | - +==============================+========+========+==========+ - | OID4VP | N/A | MUST | MUST | - +------------------------------+--------+--------+----------+ - | OID4VCI | MUST | MUST | N/A | - +------------------------------+--------+--------+----------+ - | SIOPv2 | N/A | MUST | SHOULD | - +------------------------------+--------+--------+----------+ - | SD-JWT VC profile as defined | MUST | MUST | MUST | - | in Section 7 | | | | - +------------------------------+--------+--------+----------+ - - Table 1 - -4. OpenID for Verifiable Credential Issuance - - Implementations of this profile: - - * MUST support both pre-auth code flow and authorization code flow. - * MUST support protocol extensions for SD-JWT VC credential format - profile as defined in this specification Section 7.2. - * MUST support sender-constrained Tokens using a mechanism as - defined in [I-D.ietf-oauth-dpop]. - * MUST support [RFC7636] with S256 as the code challenge method. - - Both Wallet initiated and Issuer initiated issuance is supported. - -4.1. Credential Offer - - * The Grant Types authorization_code and - urn:ietf:params:oauth:grant-type:pre-authorized_code MUST be - supported as defined in Section 4.1.1 in [OIDF.OID4VCI] - * For Grant Type authorization_code, the Issuer MUST include a scope - value in order to allow the Wallet to identify the desired - credential type. The wallet MUST use that value in the scope - Authorization parameter. For Grant Type - urn:ietf:params:oauth:grant-type:pre-authorized_code, the pre- - authorized code is used by the issuer to identify the credential - type(s). (pending OID4VCI PR#519) - * 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. - - Note: The Authorization Code flow does not require a Credential Offer - from the Issuer to the Wallet. However, it is included in the - feature set of the Credential Offer because it might be easier to - implement with existing libraries and on top of existing - implementations than the pre-authorized code Grant Type. - - Both sending Credential Offer same-device and cross-device is - supported. - -4.2. Authorization Endpoint - - * MUST use Pushed Authorization Requests (PAR) [RFC9126] to send the - Authorization Request. - * Wallets MUST authenticate itself at the PAR endpoint using the - same rules as defined in Section 4.3 for client authentication at - the token endpoint. - * MUST use scope parameter to communicate credential type(s) to be - issued. The scope value MUST map to a specific Credential type. - The scope value may be pre-agreed, obtained from the Credential - Offer, or the Credential Issuer Metadata. - * The client_id value in the PAR request MUST be a string that the - Wallet has used as the sub value in the client attestation JWT. - -4.3. Token Endpoint - - * The Wallets MUST perform client authentication as defined in - [I-D.ietf-oauth-attestation-based-client-auth]. - * Refresh tokens MUST be supported for credential refresh. - * Wallets MUST support deferred authorization by being able to - process the Token error response parameters authorization_pending - and slow_down, and the credential offer parameter interval. - * The Wallet Attestation JWT scheme is defined in Section 4.3.1. - - Note: It is RECOMMENDED to use ephemeral client attestation JWTs for - client authentication in order to prevent linkability across - Credential Issuers. - - Note: Issuers should be mindful of how long the usage of the refresh - token is allowed to refresh a credential, as opposed to starting the - issuance flow from the beginning. For example, if the User is trying - to refresh a credential more than a year after its original issuance, - the usage of the refresh tokens is NOT RECOMMENDED. - -4.3.1. Wallet Attestation Schema - - Wallets MUST use attestations following the definition given in - [I-D.ietf-oauth-attestation-based-client-auth]. - - In addition to this definition, the Wallet Attestation MAY contain - the following claims in the cnf element: - - * key_type: OPTIONAL. JSON String that asserts the security - mechanism the Wallet uses to manage the private key associated - with the public key given in the cnf claim. This mechanism is - based on the capabilities of the execution environent of the - Wallet, this might be a secure element (in case of a wallet - residing on a smartphone) or a Cloud-HSM (in case of a cloud - Wallet). This specification defines the following values for - key_type: - - software: It MUST be used when the Wallet uses software-based - key management. - - hardware: It MUST be used when the wallet uses hardware-based - key management. - - tee: It SHOULD be used when the Wallet uses the Trusted - Execution Environment for key management. - - secure_enclave: It SHOULD be used when the Wallet uses the - Secure Enclave for key management. - - strong_box: It SHOULD be used when the Wallet uses the - Strongbox for key management. - - secure_element: It SHOULD be used when the Wallet uses a Secure - Element for key management. - - hsm: It SHOULD be used when the Wallet uses Hardware Security - Module (HSM). - * user_authentication: OPTIONAL. JSON String that asserts the - security mechanism the Wallet uses to authenticate the user to - authorize access to the private key associated with the public key - given in the cnf claim. This specification defines the following - values for user_authentication: - - system_biometry: It MUST be used when the key usage is - authorized by the mobile operating system using a biometric - factor. - - system_pin: It MUST be used when the key usage is authorized by - the mobile operating system using personal identification - number (PIN). - - internal_biometry: It MUST be used when the key usage is - authorized by the Wallet using a biometric factor. - - internal_pin: It MUST be used when the key usage is authorized - by the Wallet using PIN. - - secure_element_pin It MUST be used when the key usage is - authorized by the secure element managing the key itself using - PIN. - - The Wallet Attestation MAY also contain the following claim: - - * aal: OPTIONAL. JSON String asserting the authentication level of - the Wallet and the key as asserted in the cnf claim. - - To obtain the issuer's Public key for verification, wallet attestions - MUST support web-based key resolution as defined in Section 5 of - [I-D.terbu-sd-jwt-vc]. The JOSE header kid MUST be used to identify - the respective key. - - This is an example of a Wallet Instance Attestation: - - { - "typ": "wallet-attestation+jwt", - "alg": "ES256", - "kid": "1" - } - . - { - "iss": "", - "sub": "<`client_id` of the OAuth client>", - "iat": 1516247022, - "exp": 1541493724, - "aal" : "https://trust-list.eu/aal/high", - "cnf": { - "jwk": { - "kty": "EC", - "crv": "P-256", - "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", - "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" - }, - "key_type": "strong_box", - "user_authentication": "system_pin", - } - } - -4.4. Credential Endpoint - - * The JWT proof type MUST be supported. - -4.5. Server Metadata - - * The Credential Issuer MUST publish a mapping of every Credential - Type it supports to a scope value. - -5. OpenID for Verifiable Presentations - - * MUST support protocol extensions for SD-JWT VC credential format - profile as defined in this specification Section 7.2. - - * 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. - - * Response type MUST be vp_token. - - * Response mode MUST be direct_post with redirect_uri as defined in - Section 6.2 of [OIDF.OID4VP]. - - * Authorization Request MUST be sent using the request_uri parameter - as defined in JWT-Secured Authorization Request (JAR) [RFC9101]. - - * client_id_scheme parameter MUST be present in the Authorization - Request. - - * client_id_scheme value MUST be either x509_san_dns or - verifier_attestation. Wallet MUST support both. Verifier MUST - support at least one. (pending OID4VCI PR #524 for - verifier_attestation) - - * To obtain the issuer's public key for verification, verifiers MUST - support web-based key resolution as defined in Section 5 of - [I-D.ietf-oauth-sd-jwt-vc]. The JOSE header kid MUST be used to - identify the respective key. - - * Presentation Definition JSON object MUST be sent using a - presentation_definition parameter. - - * The following features from the DIF Presentation Exchange v2.0.0 - MUST be supported. A JSON schema for the supported features is in - Appendix B: - - - In the presentation_definition object, id, input_descriptors - and submission_requirements properties MUST be supported. - - In the input-descriptors object, id, name, purpose, group, - format, and constraints properties MUST be supported. In the - constraints object, limit_disclosure, and fields properties - MUST be supported. In the fields object, path and filter - properties MUST be supported. A path MUST contain exactly one - entry with a static path to a certain claim. A filter MUST - only contain type elements of value string and const elements. - - In the submission_requirements object, name, rule (pickonly), - count, from properties MUST be supported. - -6. Self-Issued OP v2 - - To authenticate the user, subject identifier in a Self-Issued ID - Token MUST be used as defined in [OIDF.SIOPv2]. - - * 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 - -7. SD-JWT VCs - - 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. - - * 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) - - +========+================+========================================+ - | Claim | SD-JWT as | Normative Definition | - | | issued by the | | - | | Issuer | | - +========+================+========================================+ - | iss | MUST | [RFC7519], Section 4.1.1 | - +--------+----------------+----------------------------------------+ - | iat | MUST | [RFC7519], Section 4.1.6 | - +--------+----------------+----------------------------------------+ - | exp | SHOULD (at the | [RFC7519], Section 4.1.4 | - | | discretion of | | - | | the issuer) | | - +--------+----------------+----------------------------------------+ - | cnf | MUST | [RFC7800] | - +--------+----------------+----------------------------------------+ - | vct | MUST | [I-D.ietf-oauth-sd-jwt-vc] | - +--------+----------------+----------------------------------------+ - | status | SHOULD (at the | [I-D.looker-oauth-jwt-cwt-status-list] | - | | discretion of | | - | | the issuer) | | - +--------+----------------+----------------------------------------+ - - Table 2 - - * 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 iss claim MUST be an HTTPS URL. The iss value is used to - obtain Issuer’s signing key as defined in Section 7.1. - * 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. - - 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 - (https://bitbucket.org/openid/connect/issues/1537/presenting-vc- - without-a-vp-using-openid4vp) - - Note: Re-using the same Credential across Verifiers, or re-using the - same JWK value across multiple Credentials gives colluding Verifiers - a mechanism to correlate the User. There are currently two known - ways to address this with SD-JWT VCs. First is to issue multiple - instances of the same credentials with different JWK values, so that - if each instance of the credential is used at only one Verifier, it - can be reused multiple times. Another is to use each credential only - once (ephemeral credentials). It is RECOMMENDED to adopt one of - these mechanisms. - - Note: If there is a requirement to communicate information about the - verification status and identity assurance data of the claims about - the subject, the syntax defined by [OIDF.ekyc-ida] SHOULD be used. - It is up to each jurisdiction and ecosystem, whether to require it to - the implementers of this profile. - - Note: If there is a requirement to provide the Subject’s identifier - assigned and maintained by the Issuer, sub claim MAY be used. There - is no requirement for a binding to exist between sub and cnf claims. - See Implementation Considerations section in - [I-D.ietf-oauth-sd-jwt-vc]. - - Note: In some credential types, it is not desirable to include an - expiration date (eg: diploma attestation). Therefore, this profile - leaves its inclusion to the Issuer, or the body defining the - respective credential type. - -7.1. Issuer identification and key resolution to validate an issued - Credential - - This profile supports two ways to represent and resolve the key - required to validate the issuer signature of an SD-JWT VC, the web - PKI-based key resolution and the x.509 certificates. - - * Web-based key resolution: The key used to validate the Issuer’s - signature on the SD-JWT VC MUST be obtained from the SD-JWT VC - issuer's metadata as defined in Section 5 of - [I-D.ietf-oauth-sd-jwt-vc]. The JOSE header kid MUST be used to - identify the respective key. - * x.509 certificates: the SD-JWT VC contains the issuer's - certificate along with a trust chain in the x5c JOSE header. In - this case, the iss value MUST be an URL with a FQDN matching a - dNSName Subject Alternative Name (SAN) [RFC5280] entry in the leaf - certificate. - - Note: The issuer MAY decide to support both options. In which case, - it is at the discretion of the Wallet and the Verifier which key to - use for the issuer signature validation. - -7.1.1. Cryptographic Holder Binding between VC and VP - - * For Cryptographic Holder Binding, a KB-JWT as defined in - [I-D.ietf-oauth-sd-jwt-vc] MUST always be present when presenting - an SD-JWT VC. - -7.2. OpenID4VC Credential Format Profile - - This section specifies how SD-JWT VCs as defined in - [I-D.ietf-oauth-sd-jwt-vc] are used in conjunction with the OpenID4VC - specifications. - -7.2.1. Format Identifier - - The Credential format identifier is vc+sd-jwt. This format - identifier is used in issuance and presentation requests. - -7.2.2. Credential Issuer Metadata - - The following additional Credential Issuer metadata are defined for - this Credential format to be used in addition to those defined in - Section 10.2 of [OIDF.OID4VCI]. - - * credential_definition: REQUIRED. JSON object containing the - detailed description of the credential type. It consists at least - of the following three sub elements: - - vct: REQUIRED. JSON string designating the type of a - credential as defined in [I-D.ietf-oauth-sd-jwt-vc], - Section 4.2.2.1. - - claims: OPTIONAL. A JSON object containing a list of name/ - value pairs, where each name identifies a claim offered in the - Credential. The value can be another such object (nested data - structures), or an array of such objects. To express the - specifics about the claim, the most deeply nested value MAY be - a JSON object that includes a following non-exhaustive list of - parameters defined by this specification: - o mandatory: OPTIONAL. Boolean which when set to true - indicates the claim MUST be present in the issued - Credential. If the mandatory property is omitted its - default should be assumed to be false. - o value_type: OPTIONAL. String value determining type of - value of the claim. A non-exhaustive list of valid values - defined by this specification are string, number, and image - media types such as image/jpeg as defined in IANA media type - registry for images (https://www.iana.org/assignments/media- - types/media-types.xhtml#image - (https://www.iana.org/assignments/media-types/media- - types.xhtml#image)). - o display: OPTIONAL. An array of objects, where each object - contains display properties of a certain claim in the - Credential for a certain language. Below is a non- - exhaustive list of valid parameters that MAY be included: - + name: OPTIONAL. String value of a display name for the - claim. - + locale: OPTIONAL. String value that identifies language - of this object represented as language tag values defined - in BCP47 [RFC5646]. There MUST be only one object for - each language identifier. - * order: OPTIONAL. An array of claims.display.name values that - lists them in the order they should be displayed by the Wallet. - - The following is a non-normative example of an object comprising - credentials_supported parameter of Credential format vc+sd-jwt. - - { - "format": "vc+sd-jwt", - "scope": "IdentityCredential_SD-JWT-VC", - "cryptographic_binding_methods_supported": [ - "did:example" - ], - "cryptographic_suites_supported": [ - "ES256K" - ], - "display": [ - { - "name": "IdentityCredential", - "locale": "en-US", - "background_color": "#12107c", - "text_color": "#FFFFFF" - } - ], - "credential_definition": { - "type": "IdentityCredential", - "claims": { - "given_name": { - "display": [ - { - "name": "Given Name", - "locale": "en-US" - }, - { - "name": "Vorname", - "locale": "de-DE" - } - ] - }, - "last_name": { - "display": [ - { - "name": "Surname", - "locale": "en-US" - }, - { - "name": "Nachname", - "locale": "de-DE" - } - ] - }, - "email": {}, - "phone_number": {}, - "address": { - "street_address": {}, - "locality": {}, - "region": {}, - "country": {} - }, - "birthdate": {}, - "is_over_18": {}, - "is_over_21": {}, - "is_over_65": {} - } - } - } - - - { - "type": "IdentityCredential", - "given_name": "John", - "family_name": "Doe", - } - -7.2.3. Credential Offer - - The following additional claims are defined for this Credential - format. - - * credential_definition: REQUIRED. JSON object containing the - detailed description of the credential type. It MUST contain at - least type property as defined in Section 7.2.2. - - The following is a non-normative example of an object comprising - credentials_supported parameter of Credential format vc+sd-jwt. - - { - "credential_issuer": "https://credential-issuer.example.com", - "credentials": [ - "IdentityCredential_SD-JWT-VC" - ], - "grants": { - "authorization_code": { - "issuer_state": "eyJhbGciOiJSU0Et...FYUaBy" - } - } - } - -7.2.4. Authorization Details - - The following additional claims are defined for authorization details - of type openid_credential and this Credential format. - - * credential_definition: REQUIRED. JSON object containing the - detailed description of the credential type. It MUST contain at - least type property as defined in Section 7.2.2. It MAY contain - claims property as defined in Section 7.2.2. - - The following is a non-normative example of an authorization details - object with Credential format vc+sd-jwt. - - [ - { - "type": "openid_credential", - "format": "vc+sd-jwt", - "credential_definition": { - "type": "IdentityCredential" - } - } - ] - -7.2.5. Credential Request - - The following additional parameters are defined for Credential - Requests and this Credential format. - - * credential_definition: REQUIRED. JSON object containing the - detailed description of the credential type. It MUST contain at - least vct property as defined in Section 7.2.2. It MAY contain - claims property as defined in Section 7.2.2. - - The following is a non-normative example of a Credential Request with - Credential format vc+sd-jwt. - - { - "format": "vc+sd-jwt", - "credential_definition": { - "type": "IdentityCredential" - }, - "proof": { - "proof_type": "jwt", - "jwt":"eyJraWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEva2V5cy8 - xIiwiYWxnIjoiRVMyNTYiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR - 0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJpYXQiOiIyMDE4LTA5LTE0VDIxOjE5OjEwWiIsIm5vbm - NlIjoidFppZ25zbkZicCJ9.ewdkIkPV50iOeBUqMXCC_aZKPxgihac0aW9EkL1nOzM" - } - } - -7.2.6. Credential Response - - The value of the credential claim in the Credential Response MUST be - a JSON string that is an SD-JWT VC. Credentials of this format are - already suitable for transfer and, therefore, they need not and MUST - NOT be re-encoded. - - The following is a non-normative example of a Credential Response - with Credential format vc+sd-jwt. - -7.2.7. Verifier Metadata - - The Verifier SHOULD add a vp_formats_supported element to its - metadata (e.g. in the client_metadata authorization request - parameter) to let the wallet know what protection algorithms it - supports in conjunction with SD-JWT VCs. The format element MUST - have the key vc+sd-jwt, the value is an object consisting of the - following elements: - - * sd-jwt_alg_values: OPTIONAL. A JSON array containing identifiers - of cryptographic algorithms the verifier supports for protection - of a SD-JWT. If present, the alg JOSE header (as defined in - [RFC7515]) of the presented SD-JWT MUST match one of the array - values. - * kb-jwt_alg_values: OPTIONAL. A JSON array containing identifiers - of cryptographic algorithms the verifier supports for protection - of a KB-JWT. If present, the alg JOSE header (as defined in - [RFC7515]) of the presented KB-JWT MUST match one of the array - values. - - The following is a non-normative example of client_metadata request - parameter value in a request to present a SD-JWT VC. - - { - "vp_formats": { - "vc+sd-jwt": { - "sd-jwt_alg_values": [ - "ES256", - "ES384" - ], - "kb-jwt_alg_values": [ - "ES256", - "ES384" - ] - } - } - } - -7.2.8. Presentation Definition - - The presentation of a SD-JWT VC is requested by adding an object - named vc+sd-jwt to the format object of an input_descriptor. The - object is empty. - - The following is a non-normative example of a presentation definition - for a SD-JWT VC. - - { - "id": "d76c51b7-ea90-49bb-8368-6b3d194fc131", - "input_descriptors": [ - { - "id": "IdentityCredential", - "format": { - "vc+sd-jwt": {} - }, - "constraints": { - "limit_disclosure": "required", - "fields": [ - { - "path": [ - "$.type" - ], - "filter": { - "type": "string", - "const": "IdentityCredential" - } - }, - { - "path": [ - "$.family_name" - ] - }, - { - "path": [ - "$.given_name" - ] - } - ] - } - } - ] - } - -8. 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 - * Wallet Instance Attestation - * DPoP - * HB 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. - - Note: When using this profile with other cryptosuites, it is - recommended to be explicit about which entity is required to support - which curve for signing and/or signature validation - -9. Implementations Considerations - -9.1. Validity Period of the Signature and the Claim Values - - iat and exp JWT claims express both the validity period of both the - signature and the claims about the subject, unless there is a - separate claim used to express the validity of the claims. - -10. References - -10.1. Normative References - - [I-D.ietf-oauth-attestation-based-client-auth] - Looker, T. and P. Bastian, "OAuth 2.0 Attestation-Based - Client Authentication", Work in Progress, Internet-Draft, - draft-ietf-oauth-attestation-based-client-auth-01, 23 - October 2023, . - - [I-D.ietf-oauth-dpop] - Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., - Jones, M. B., and D. Waite, "OAuth 2.0 Demonstrating - Proof-of-Possession at the Application Layer (DPoP)", Work - in Progress, Internet-Draft, draft-ietf-oauth-dpop-16, 13 - April 2023, . - - [I-D.ietf-oauth-sd-jwt-vc] - Terbu, O. and D. Fett, "SD-JWT-based Verifiable - Credentials (SD-JWT VC)", Work in Progress, Internet- - Draft, draft-ietf-oauth-sd-jwt-vc-01, 23 October 2023, - . - - [I-D.ietf-oauth-selective-disclosure-jwt] - Fett, D., Yasuda, K., and B. Campbell, "Selective - Disclosure for JWTs (SD-JWT)", Work in Progress, Internet- - Draft, draft-ietf-oauth-selective-disclosure-jwt-06, 23 - October 2023, . - - [I-D.looker-oauth-jwt-cwt-status-list] - Looker, T. and P. Bastian, "JWT and CWT Status List", Work - in Progress, Internet-Draft, draft-looker-oauth-jwt-cwt- - status-list-01, 10 July 2023, - . - - [I-D.terbu-sd-jwt-vc] - Terbu, O. and D. Fett, "SD-JWT-based Verifiable - Credentials with JSON payloads (SD-JWT VC)", Work in - Progress, Internet-Draft, draft-terbu-sd-jwt-vc-02, 26 May - 2023, . - - [OIDF.OID4VCI] - Lodderstedt, T., Yasuda, K., and T. Looker, "OpenID for - Verifiable Credential Issuance", 20 June 2022, - . - - [OIDF.OID4VP] - Terbu, O., Lodderstedt, T., Yasuda, K., Lemmon, A., and T. - Looker, "OpenID for Verifiable Presentations", 20 June - 2022, . - - [OIDF.SIOPv2] - Microsoft, Jones, M. B., and T. Lodderstedt, "Self-Issued - OpenID Provider V2", 18 December 2021, - . - - [OIDF.ekyc-ida] - yes, Fett, D., Haine, M., Pulido, A., Lehmann, K., and K. - Koiwai, "OpenID Connect for Identity Assurance 1.0", 19 - August 2022, . - - [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., - Housley, R., and W. Polk, "Internet X.509 Public Key - Infrastructure Certificate and Certificate Revocation List - (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, - . - - [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying - Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, - September 2009, . - - [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web - Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May - 2015, . - - [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, - DOI 10.17487/RFC7517, May 2015, - . - - [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token - (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, - . - - [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key - for Code Exchange by OAuth Public Clients", RFC 7636, - DOI 10.17487/RFC7636, September 2015, - . - - [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- - Possession Key Semantics for JSON Web Tokens (JWTs)", - RFC 7800, DOI 10.17487/RFC7800, April 2016, - . - - [RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 - Authorization Framework: JWT-Secured Authorization Request - (JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021, - . - - [RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., - and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", - RFC 9126, DOI 10.17487/RFC9126, September 2021, - . - -10.2. Informative References - - [ISO.18013-5] - ISO/IEC JTC 1/SC 17 Cards and security devices for - personal identification, "ISO/IEC 18013-5:2021 Personal - identification — ISO-compliant driving license — Part 5: - Mobile driving license (mDL) application", 2021, - . - -Appendix A. Combined Issuance of SD-JWT VC and mdocs - - * If combined issuance is required, the Batch Credential Endpoint - MUST be supported. - -Appendix B. JSON Schema for the supported Presentation Definition - properties - - { - "$schema": "http://json-schema.org/draft-07/schema#", - "title": "Presentation Definition for a High Assurance Profile", - "type": "object", - "properties": { - "presentation_definition": { - "$ref": "#/definitions/presentation_definition" - } - }, - "definitions": { - "presentation_definition": { - "type": "object", - "properties": { - "id": { - "type": "string" - }, - "input_descriptors": { - "type": "array", - "items": { - "$ref": "#/definitions/input_descriptor" - } - }, - "submission_requirements": { - "type": "array", - "items": { - "$ref": "#/definitions/submission_requirement" - } - } - }, - "required": [ - "id", - "input_descriptors" - ], - "additionalProperties": false - }, - "input_descriptor": { - "type": "object", - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "name": { - "type": "string" - }, - "purpose": { - "type": "string" - }, - "format": { - "$ref": "http://identity.foundation/claim-format-registry/schemas/presentation-definition-claim-format-designations.json" - }, - "group": { - "type": "array", - "items": { - "type": "string" - } - }, - "constraints": { - "type": "object", - "additionalProperties": false, - "properties": { - "limit_disclosure": { - "type": "string", - "enum": [ - "required", - "preferred" - ] - }, - "fields": { - "type": "array", - "items": { - "path": { - "type": "array", - "items": { - "type": "string" - } - }, - "filter": { - "$ref": "http://json-schema.org/draft-07/schema#" - } - } - } - } - } - }, - "required": [ - "id", - "constraints" - ] - }, - "submission_requirement": { - "type": "object", - "oneOf": [ - { - "properties": { - "name": { - "type": "string" - }, - "rule": { - "type": "string", - "enum": [ - "pick" - ] - }, - "count": { - "type": "integer", - "minimum": 1 - }, - "from": { - "type": "string" - } - }, - "required": [ - "rule", - "from" - ], - "additionalProperties": false - } - ] - } - } - } - -Authors' Addresses - - Kristina Yasuda - Microsoft - Email: kristina.yasuda@microsoft.com - - - Torsten Lodderstedt - yes.com - Email: torsten@lodderstedt.net diff --git a/pb/issuerMetadata/index.html b/pb/issuerMetadata/index.html deleted file mode 100644 index 32e1f52..0000000 --- a/pb/issuerMetadata/index.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - vcstuff/oid4vc-haip-sd-jwt-vc pb/issuerMetadata preview - - - - -

Editor's drafts for pb/issuerMetadata branch of vcstuff/oid4vc-haip-sd-jwt-vc

- - - - - - -
oid4vc-haip-sd-jwt-vcplain textsame as main
- - - diff --git a/tl/change_affiliation/draft-oid4vc-haip-sd-jwt-vc.html b/tl/change_affiliation/draft-oid4vc-haip-sd-jwt-vc.html deleted file mode 100644 index f9c1370..0000000 --- a/tl/change_affiliation/draft-oid4vc-haip-sd-jwt-vc.html +++ /dev/null @@ -1,2318 +0,0 @@ - - - - - - -OpenID4VC High Assurance Interoperability Profile with SD-JWT VC - - - - - - - - - - - - - - - - - - - - - - - - - - -
oid4vc-haip-sd-jwt-vcNovember 2023
Yasuda & LodderstedtStandards Track[Page]
-
-
-
-
Workgroup:
-
OpenID Connect
-
Published:
-
- -
-
Authors:
-
-
-
K. Yasuda
-
Microsoft
-
-
-
T. Lodderstedt
-
sprind.org
-
-
-
-
-

OpenID4VC High Assurance Interoperability Profile with SD-JWT VC

-
-

Abstract

-

This document defines a profile of OpenID for Verifiable Credentials in combination with the credential format SD-JWT VC. The aim is to select features and to define a set of requirements for the existing specifications to enable interoperability among Issuers, Wallets and Verifiers of Credentials where a high level of security and privacy is required. The profiled specifications include OpenID for Verifiable Credential Issuance [OIDF.OID4VCI], OpenID for Verifiable Presentations [OIDF.OID4VP], Self-Issued OpenID Provider v2 [OIDF.SIOPv2], and SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc].

-
-
-
- ▲

-Table of Contents -

- -
-
-
-
-

-1. Introduction -

-

This document defines a set of requirements for the existing specifications to enable interoperability among Issuers, Wallets and Verifiers of Credentials where a high level of security and privacy is required. This document is an interoperability profile that can be used by implementations in various contexts, be it a certain industry or a certain regulatory environment.

-

This document is not a specification, but a profile. It refers to the specifications required for implementations to interoperate among each other and for the optionalities mentioned in the referenced specifications, defines the set of features to be mandatory to implement.

-

The profile uses OpenID for Verifiable Credential Issuance [OIDF.OID4VCI] and OpenID for Verifiable Presentations [OIDF.OID4VP] as the base protocols for issuance and presentation of Credentials, respectively. The credential format used is SD-JWT VC as specified in [I-D.ietf-oauth-sd-jwt-vc]. Additionally, considerations are given on how deployments can perform a combined issuance of credentials in both SD-JWT VC and ISO mdoc [ISO.18013-5] formats.

-

A full list of the open standards used in this profile can be found in Overview of the Open Standards Requirements (reference).

-
-
-

-1.1. Audience Target audience/Usage -

-

The audience of the document is implementers that require a high level of security and privacy for their solutions. A non-exhaustive list of the interested parties includes eIDAS 2.0, California Department of Motor Vehicles, Open Wallet Foundation (OWF), IDunion, GAIN, and the Trusted Web project of the Japanese government, but is expected to grow to include other jurisdictions and private sector companies.

-
-
-
-
-
-
-

-2. Terminology -

-

This specification uses the terms "Holder", "Issuer", "Verifier", and "Verifiable Credential" as defined in [I-D.ietf-oauth-sd-jwt-vc].

-
-
-
-
-

-3. Scope -

-

The following aspects are in scope of this interoperability profile:

-
    -
  • Protocol for issuance of the Verifiable Credentials (can be both remote and in-person) (OID4VCI) -
    • -
  • Protocol for online presentation of Verifiable Credentials (can be both remote and in-person) (OID4VP) -
    • -
  • Protocol for User Authentication by the Wallet at a Verifier (SIOP v2) -
    • -
  • Wallet Attestation (during Credential issuance) -
    • -
  • Credential Format (SD-JWT VC) -
    • -
  • Status Management of the Credentials, including revocation -
    • -
  • Cryptographic Holder Binding -
    • -
  • Issuer key resolution -
    • -
  • Issuer identification (as prerequisite for trust management) -
    • -
  • Crypto Suites -
    • -
-

Assumptions made are the following:

-
    -
  • The issuers and verifiers cannot pre-discover wallet’s capability -
    • -
  • The issuer is talking to the wallet supporting the features defined in this profile (via wallet invocation mechanism) -
    • -
  • There are mechanisms in place for the verifiers and issuers to discover each other’s capability -
    • -
-
-
-

-3.1. Out of Scope -

-

The following items are out of scope for the current version of this document, but might be added in future versions:

-
    -
  • Trust Management, i.e. authorization of an issuer to issue certain types of credentials, authorization of the Wallet to be issued certain types of credentials, authorization of the Verifier to receive certain types of credentials. -
    • -
  • Protocol for presentation of Verifiable Credentials for offline use-cases, e.g. over BLE. -
    • -
-
-
-
-
-

-3.2. Scenarios/Business Requirements -

-
    -
  • Combined Issuance of SD-JWT VC and mdoc -
    • -
  • Both issuer-initiated and wallet-initiated issuance -
    • -
  • eIDAS PID and (Q)EAA as defined in eIDAS ARF 1.0 -
    • -
-
-
-
-
-

-3.3. Standards Requirements -

-

Unless explicitly stated, all normative requirements apply to all participating entities: Issuers, Wallets and Verifiers.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 1
(as defined in this profile)IssuerWalletVerifier
OID4VPN/AMUSTMUST
OID4VCIMUSTMUSTN/A
SIOPv2N/AMUSTSHOULD
SD-JWT VC profile as defined in Section 7 -MUSTMUSTMUST
-
-
-
-
-
-
-

-4. OpenID for Verifiable Credential Issuance -

-

Implementations of this profile:

-
    -
  • MUST support both pre-auth code flow and authorization code flow. -
    • -
  • MUST support protocol extensions for SD-JWT VC credential format profile as defined in this specification Section 7.2. -
    • -
  • MUST support sender-constrained Tokens using a mechanism as defined in [I-D.ietf-oauth-dpop]. -
    • -
  • MUST support [RFC7636] with S256 as the code challenge method. -
    • -
-

Both Wallet initiated and Issuer initiated issuance is supported.

-
-
-

-4.1. Credential Offer -

-
    -
  • The Grant Types authorization_code and urn:ietf:params:oauth:grant-type:pre-authorized_code MUST be supported as defined in Section 4.1.1 in [OIDF.OID4VCI] -
    • -
  • For Grant Type authorization_code, the Issuer MUST include a scope value in order to allow the Wallet to identify the desired credential type. The wallet MUST use that value in the scope Authorization parameter. For Grant Type urn:ietf:params:oauth:grant-type:pre-authorized_code, the pre-authorized code is used by the issuer to identify the credential type(s). (pending OID4VCI PR#519) -
    • -
  • 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. -
    • -
-

Note: The Authorization Code flow does not require a Credential Offer from the Issuer to the Wallet. However, it is included in the feature set of the Credential Offer because it might be easier to implement with existing libraries and on top of existing implementations than the pre-authorized code Grant Type.

-

Both sending Credential Offer same-device and cross-device is supported.

-
-
-
-
-

-4.2. Authorization Endpoint -

-
    -
  • MUST use Pushed Authorization Requests (PAR) [RFC9126] to send the Authorization Request. -
    • -
  • Wallets MUST authenticate itself at the PAR endpoint using the same rules as defined in Section 4.3 for client authentication at the token endpoint. -
    • -
  • MUST use scope parameter to communicate credential type(s) to be issued. The scope value MUST map to a specific Credential type. The scope value may be pre-agreed, obtained from the Credential Offer, or the Credential Issuer Metadata. -
    • -
  • The client_id value in the PAR request MUST be a string that the Wallet has used as the sub value in the client attestation JWT. -
    • -
-
-
-
-
-

-4.3. Token Endpoint -

-
    -
  • The Wallets MUST perform client authentication as defined in [I-D.ietf-oauth-attestation-based-client-auth]. -
    • -
  • Refresh tokens MUST be supported for credential refresh. -
    • -
  • Wallets MUST support deferred authorization by being able to process the Token error response parameters authorization_pending and slow_down, and the credential offer parameter interval. -
    • -
  • The Wallet Attestation JWT scheme is defined in Section 4.3.1. -
    • -
-

Note: It is RECOMMENDED to use ephemeral client attestation JWTs for client authentication in order to prevent linkability across Credential Issuers.

-

Note: Issuers should be mindful of how long the usage of the refresh token is allowed to refresh a credential, as opposed to starting the issuance flow from the beginning. For example, if the User is trying to refresh a credential more than a year after its original issuance, the usage of the refresh tokens is NOT RECOMMENDED.

-
-
-

-4.3.1. Wallet Attestation Schema -

-

Wallets MUST use attestations following the definition given in [I-D.ietf-oauth-attestation-based-client-auth].

-

In addition to this definition, the Wallet Attestation MAY contain the following claims in the cnf element:

-
    -
  • -

    key_type: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to manage the private key associated with the public key given in the cnf claim. This mechanism is based on the capabilities of the execution environent of the Wallet, this might be a secure element (in case of a wallet residing on a smartphone) or a Cloud-HSM (in case of a cloud Wallet). This specification defines the following values for key_type:

    -
      -
    • - software: It MUST be used when the Wallet uses software-based key management. -
      • -
    • - hardware: It MUST be used when the wallet uses hardware-based key management. -
      • -
    • - tee: It SHOULD be used when the Wallet uses the Trusted Execution Environment for key management. -
      • -
    • - secure_enclave: It SHOULD be used when the Wallet uses the Secure Enclave for key management. -
      • -
    • - strong_box: It SHOULD be used when the Wallet uses the Strongbox for key management. -
      • -
    • - secure_element: It SHOULD be used when the Wallet uses a Secure Element for key management. -
      • -
    • - hsm: It SHOULD be used when the Wallet uses Hardware Security Module (HSM). -
      • -
    -
    • -
  • -

    user_authentication: OPTIONAL. JSON String that asserts the security mechanism the Wallet uses to authenticate the user to authorize access to the private key associated with the public key given in the cnf claim. This specification defines the following values for user_authentication:

    -
      -
    • - system_biometry: It MUST be used when the key usage is authorized by the mobile operating system using a biometric factor. -
      • -
    • - system_pin: It MUST be used when the key usage is authorized by the mobile operating system using personal identification number (PIN). -
      • -
    • - internal_biometry: It MUST be used when the key usage is authorized by the Wallet using a biometric factor. -
      • -
    • - internal_pin: It MUST be used when the key usage is authorized by the Wallet using PIN. -
      • -
    • - secure_element_pin It MUST be used when the key usage is authorized by the secure element managing the key itself using PIN. -
      • -
    -
    • -
-

The Wallet Attestation MAY also contain the following claim:

-
    -
  • - aal: OPTIONAL. JSON String asserting the authentication level of the Wallet and the key as asserted in the cnf claim. -
    • -
-

To obtain the issuer's Public key for verification, wallet attestions MUST support web-based key resolution as defined in Section 5 of [I-D.terbu-sd-jwt-vc]. The JOSE header kid MUST be used to identify the respective key.

-

This is an example of a Wallet Instance Attestation:

-
-
{
-  "typ": "wallet-attestation+jwt",
-  "alg": "ES256",
-  "kid": "1"
-}
-.
-{
-  "iss": "<identifier of the issuer of this wallet attestation>",
-  "sub": "<`client_id` of the OAuth client>",
-  "iat": 1516247022,
-  "exp": 1541493724,
-  "aal" : "https://trust-list.eu/aal/high",
-  "cnf": {
-    "jwk": {
-      "kty": "EC",
-      "crv": "P-256",
-      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
-      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
-    },
-    "key_type": "strong_box",
-    "user_authentication": "system_pin",
-  }
-}
-
-
-
-
-
-
-
-
-
-

-4.4. Credential Endpoint -

-
    -
  • The JWT proof type MUST be supported. -
    • -
-
-
-
-
-

-4.5. Server Metadata -

-
    -
  • The Credential Issuer MUST publish a mapping of every Credential Type it supports to a scope value. -
    • -
-
-
-
-
-
-
-

-5. OpenID for Verifiable Presentations -

-
    -
  • MUST support protocol extensions for SD-JWT VC credential format profile as defined in this specification Section 7.2. -
    • -
  • 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. -
    • -
  • Response type MUST be vp_token. -
    • -
  • Response mode MUST be direct_post with redirect_uri as defined in Section 6.2 of [OIDF.OID4VP]. -
    • -
  • Authorization Request MUST be sent using the request_uri parameter as defined in JWT-Secured Authorization Request (JAR) [RFC9101]. -
    • -
  • - client_id_scheme parameter MUST be present in the Authorization Request. -
    • -
  • - client_id_scheme value MUST be either x509_san_dns or verifier_attestation. Wallet MUST support both. Verifier MUST support at least one. (pending OID4VCI PR #524 for verifier_attestation) -
    • -
  • To obtain the issuer's public key for verification, verifiers MUST support web-based key resolution as defined in Section 5 of [I-D.ietf-oauth-sd-jwt-vc]. The JOSE header kid MUST be used to identify the respective key. -
    • -
  • Presentation Definition JSON object MUST be sent using a presentation_definition parameter. -
    • -
  • -

    The following features from the DIF Presentation Exchange v2.0.0 MUST be supported. A JSON schema for the supported features is in Appendix B:

    -
      -
    • In the presentation_definition object, id, input_descriptors and submission_requirements properties MUST be supported. -
      • -
    • In the input-descriptors object, id, name, purpose, group, format, and constraints properties MUST be supported. In the constraints object, limit_disclosure, and fields properties MUST be supported. In the fields object, path and filter properties MUST be supported. A path MUST contain exactly one entry with a static path to a certain claim. A filter MUST only contain type elements of value string and const elements. -
      • -
    • In the submission_requirements object, name, rule (pickonly), count, from properties MUST be supported. -
      • -
    -
    • -
-
-
-
-
-

-6. Self-Issued OP v2 -

-

To authenticate the user, subject identifier in a Self-Issued ID Token MUST be used as defined in [OIDF.SIOPv2].

-
    -
  • 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 -
    • -
-
-
-
-
-

-7. SD-JWT VCs -

-

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.

-
    -
  • 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) -
    • -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 2
ClaimSD-JWT as issued by the IssuerNormative Definition
issMUST - [RFC7519], Section 4.1.1
iatMUST - [RFC7519], Section 4.1.6
expSHOULD (at the discretion of the issuer) - [RFC7519], Section 4.1.4
cnf MUST - [RFC7800] -
vct MUST - [I-D.ietf-oauth-sd-jwt-vc] -
statusSHOULD (at the discretion of the issuer) - [I-D.looker-oauth-jwt-cwt-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 iss claim MUST be an HTTPS URL. The iss value is used to obtain Issuer’s signing key as defined in Section 7.1. -
    • -
  • 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. -
    • -
-

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

-

Note: Re-using the same Credential across Verifiers, or re-using the same JWK value across multiple Credentials gives colluding Verifiers a mechanism to correlate the User. There are currently two known ways to address this with SD-JWT VCs. First is to issue multiple instances of the same credentials with different JWK values, so that if each instance of the credential is used at only one Verifier, it can be reused multiple times. Another is to use each credential only once (ephemeral credentials). It is RECOMMENDED to adopt one of these mechanisms.

-

Note: If there is a requirement to communicate information about the verification status and identity assurance data of the claims about the subject, the syntax defined by [OIDF.ekyc-ida] SHOULD be used. It is up to each jurisdiction and ecosystem, whether to require it to the implementers of this profile.

-

Note: If there is a requirement to provide the Subject’s identifier assigned and maintained by the Issuer, sub claim MAY be used. There is no requirement for a binding to exist between sub and cnf claims. See Implementation Considerations section in [I-D.ietf-oauth-sd-jwt-vc].

-

Note: In some credential types, it is not desirable to include an expiration date (eg: diploma attestation). Therefore, this profile leaves its inclusion to the Issuer, or the body defining the respective credential type.

-
-
-

-7.1. Issuer identification and key resolution to validate an issued Credential -

-

This profile supports two ways to represent and resolve the key required to validate the issuer signature of an SD-JWT VC, the web PKI-based key resolution and the x.509 certificates.

-
    -
  • Web-based key resolution: The key used to validate the Issuer’s signature on the SD-JWT VC MUST be obtained from the SD-JWT VC issuer's metadata as defined in Section 5 of [I-D.ietf-oauth-sd-jwt-vc]. The JOSE header kid MUST be used to identify the respective key. -
    • -
  • x.509 certificates: the SD-JWT VC contains the issuer's certificate along with a trust chain in the x5c JOSE header. In this case, the iss value MUST be an URL with a FQDN matching a dNSName Subject Alternative Name (SAN) [RFC5280] entry in the leaf certificate. -
    • -
-

Note: The issuer MAY decide to support both options. In which case, it is at the discretion of the Wallet and the Verifier which key to use for the issuer signature validation.

-
-
-

-7.1.1. Cryptographic Holder Binding between VC and VP -

-
    -
  • For Cryptographic Holder Binding, a KB-JWT as defined in [I-D.ietf-oauth-sd-jwt-vc] MUST always be present when presenting an SD-JWT VC. -
    • -
-
-
-
-
-
-
-

-7.2. OpenID4VC Credential Format Profile -

-

This section specifies how SD-JWT VCs as defined in [I-D.ietf-oauth-sd-jwt-vc] are used in conjunction with the OpenID4VC specifications.

-
-
-

-7.2.1. Format Identifier -

-

The Credential format identifier is vc+sd-jwt. This format identifier is used in issuance and presentation requests.

-
-
-
-
-

-7.2.2. Credential Issuer Metadata -

-

The following additional Credential Issuer metadata are defined for this Credential format to be used in addition to those defined in Section 10.2 of [OIDF.OID4VCI].

-
    -
  • -

    credential_definition: REQUIRED. JSON object containing the detailed description of the credential type. It consists at least of the following three sub elements:

    -
      -
    • - vct: REQUIRED. JSON string designating the type of a credential as defined in [I-D.ietf-oauth-sd-jwt-vc], Section 4.2.2.1. -
      • -
    • -

      claims: OPTIONAL. A JSON object containing a list of name/value pairs, where each name identifies a claim offered in the Credential. The value can be another such object (nested data structures), or an array of such objects. To express the specifics about the claim, the most deeply nested value MAY be a JSON object that includes a following non-exhaustive list of parameters defined by this specification:

      -
        -
      • - mandatory: OPTIONAL. Boolean which when set to true indicates the claim MUST be present in the issued Credential. If the mandatory property is omitted its default should be assumed to be false. -
        • -
      • - value_type: OPTIONAL. String value determining type of value of the claim. A non-exhaustive list of valid values defined by this specification are string, number, and image media types such as image/jpeg as defined in IANA media type registry for images (https://www.iana.org/assignments/media-types/media-types.xhtml#image). -
        • -
      • -

        display: OPTIONAL. An array of objects, where each object contains display properties of a certain claim in the Credential for a certain language. Below is a non-exhaustive list of valid parameters that MAY be included:

        -
          -
        • - name: OPTIONAL. String value of a display name for the claim. -
          • -
        • - locale: OPTIONAL. String value that identifies language of this object represented as language tag values defined in BCP47 [RFC5646]. There MUST be only one object for each language identifier. -
          • -
        -
        • -
      -
      • -
    -
    • -
  • - order: OPTIONAL. An array of claims.display.name values that lists them in the order they should be displayed by the Wallet. -
    • -
-

The following is a non-normative example of an object comprising credentials_supported parameter of Credential format vc+sd-jwt.

-
-
{
-    "format": "vc+sd-jwt",
-    "scope": "IdentityCredential_SD-JWT-VC",
-    "cryptographic_binding_methods_supported": [
-        "did:example"
-    ],
-    "cryptographic_suites_supported": [
-        "ES256K"
-    ],
-    "display": [
-        {
-            "name": "IdentityCredential",
-            "locale": "en-US",
-            "background_color": "#12107c",
-            "text_color": "#FFFFFF"
-        }
-    ],
-    "credential_definition": {
-        "type": "IdentityCredential",
-        "claims": {
-            "given_name": {
-                "display": [
-                    {
-                        "name": "Given Name",
-                        "locale": "en-US"
-                    },
-                    {
-                        "name": "Vorname",
-                        "locale": "de-DE"
-                    }
-                ]
-            },
-            "last_name": {
-                "display": [
-                    {
-                        "name": "Surname",
-                        "locale": "en-US"
-                    },
-                    {
-                        "name": "Nachname",
-                        "locale": "de-DE"
-                    }
-                ]
-            },
-            "email": {},
-            "phone_number": {},
-            "address": {
-                "street_address": {},
-                "locality": {},
-                "region": {},
-                "country": {}
-            },
-            "birthdate": {},
-            "is_over_18": {},
-            "is_over_21": {},
-            "is_over_65": {}
-        }
-    }
-}
-
-
-{
-    "type": "IdentityCredential",
-    "given_name": "John",
-    "family_name": "Doe",
-}
-
-
-
-
-
-
-
-

-7.2.3. Credential Offer -

-

The following additional claims are defined for this Credential format.

-
    -
  • - credential_definition: REQUIRED. JSON object containing the detailed description of the credential type. It MUST contain at least type property as defined in Section 7.2.2. -
    • -
-

The following is a non-normative example of an object comprising credentials_supported parameter of Credential format vc+sd-jwt.

-
-
{
-    "credential_issuer": "https://credential-issuer.example.com",
-    "credentials": [
-        "IdentityCredential_SD-JWT-VC"
-    ],
-    "grants": {
-        "authorization_code": {
-            "issuer_state": "eyJhbGciOiJSU0Et...FYUaBy"
-        }
-    }
-}
-
-
-
-
-
-
-
-

-7.2.4. Authorization Details -

-

The following additional claims are defined for authorization details of type openid_credential and this Credential format.

-
    -
  • - credential_definition: REQUIRED. JSON object containing the detailed description of the credential type. It MUST contain at least type property as defined in Section 7.2.2. It MAY contain claims property as defined in Section 7.2.2. -
    • -
-

The following is a non-normative example of an authorization details object with Credential format vc+sd-jwt.

-
-
[
-    {
-        "type": "openid_credential",
-        "format": "vc+sd-jwt",
-        "credential_definition": {
-            "type": "IdentityCredential"
-        }
-    }
-]
-
-
-
-
-
-
-
-

-7.2.5. Credential Request -

-

The following additional parameters are defined for Credential Requests and this Credential format.

-
    -
  • - credential_definition: REQUIRED. JSON object containing the detailed description of the credential type. It MUST contain at least vct property as defined in Section 7.2.2. It MAY contain claims property as defined in Section 7.2.2. -
    • -
-

The following is a non-normative example of a Credential Request with Credential format vc+sd-jwt.

-
-
{
-   "format": "vc+sd-jwt",
-   "credential_definition": {
-      "type": "IdentityCredential"
-   },
-   "proof": {
-      "proof_type": "jwt",
-      "jwt":"eyJraWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEva2V5cy8
-      xIiwiYWxnIjoiRVMyNTYiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR
-      0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJpYXQiOiIyMDE4LTA5LTE0VDIxOjE5OjEwWiIsIm5vbm
-      NlIjoidFppZ25zbkZicCJ9.ewdkIkPV50iOeBUqMXCC_aZKPxgihac0aW9EkL1nOzM"
-   }
-}
-
-
-
-
-
-
-
-

-7.2.6. Credential Response -

-

The value of the credential claim in the Credential Response MUST be a JSON string that is an SD-JWT VC. Credentials of this format are already suitable for transfer and, therefore, they need not and MUST NOT be re-encoded.

-

The following is a non-normative example of a Credential Response with Credential format vc+sd-jwt.

-
-
-
-
-

-7.2.7. Verifier Metadata -

-

The Verifier SHOULD add a vp_formats_supported element to its metadata (e.g. in the client_metadata authorization request parameter) to let the wallet know what protection algorithms it supports in conjunction with SD-JWT VCs. The format element MUST have the key vc+sd-jwt, the value is an object consisting of the following elements:

-
    -
  • - sd-jwt_alg_values: OPTIONAL. A JSON array containing identifiers of cryptographic algorithms the verifier supports for protection of a SD-JWT. If present, the alg JOSE header (as defined in [RFC7515]) of the presented SD-JWT MUST match one of the array values. -
    • -
  • - kb-jwt_alg_values: OPTIONAL. A JSON array containing identifiers of cryptographic algorithms the verifier supports for protection of a KB-JWT. If present, the alg JOSE header (as defined in [RFC7515]) of the presented KB-JWT MUST match one of the array values. -
    • -
-

The following is a non-normative example of client_metadata request parameter value in a request to present a SD-JWT VC.

-
-
{
-    "vp_formats": {
-        "vc+sd-jwt": {
-            "sd-jwt_alg_values": [
-                "ES256",
-                "ES384"
-            ],
-            "kb-jwt_alg_values": [
-                "ES256",
-                "ES384"
-            ]
-        }
-    }
-}
-
-
-
-
-
-
-
-

-7.2.8. Presentation Definition -

-

The presentation of a SD-JWT VC is requested by adding an object named vc+sd-jwt to the format object of an input_descriptor. The object is empty.

-

The following is a non-normative example of a presentation definition for a SD-JWT VC.

-
-
{
-    "id": "d76c51b7-ea90-49bb-8368-6b3d194fc131",
-    "input_descriptors": [
-        {
-            "id": "IdentityCredential",
-            "format": {
-                "vc+sd-jwt": {}
-            },
-            "constraints": {
-                "limit_disclosure": "required",
-                "fields": [
-                    {
-                        "path": [
-                            "$.type"
-                        ],
-                        "filter": {
-                            "type": "string",
-                            "const": "IdentityCredential"
-                        }
-                    },
-                    {
-                        "path": [
-                            "$.family_name"
-                        ]
-                    },
-                    {
-                        "path": [
-                            "$.given_name"
-                        ]
-                    }
-                ]
-            }
-        }
-    ]
-}
-
-
-
-
-
-
-
-
-
-
-
-

-8. 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 -
    • -
  • Wallet Instance Attestation -
    • -
  • DPoP -
    • -
  • HB 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.

-

Note: When using this profile with other cryptosuites, it is recommended to be explicit about which entity is required to support which curve for signing and/or signature validation

-
-
-
-
-

-9. Implementations Considerations -

-
-
-

-9.1. Validity Period of the Signature and the Claim Values -

-

iat and exp JWT claims express both the validity period of both the signature and the claims about the subject, unless there is a separate claim used to express the validity of the claims.

-
-
-
-
-
-

-10. References -

-
-

-10.1. Normative References -

-
-
[I-D.ietf-oauth-attestation-based-client-auth]
-
-Looker, T. and P. Bastian, "OAuth 2.0 Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-attestation-based-client-auth-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-01>.
-
-
[I-D.ietf-oauth-dpop]
-
-Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M. B., and D. Waite, "OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)", Work in Progress, Internet-Draft, draft-ietf-oauth-dpop-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-16>.
-
-
[I-D.ietf-oauth-sd-jwt-vc]
-
-Terbu, O. and D. Fett, "SD-JWT-based Verifiable Credentials (SD-JWT VC)", Work in Progress, Internet-Draft, draft-ietf-oauth-sd-jwt-vc-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-01>.
-
-
[I-D.ietf-oauth-selective-disclosure-jwt]
-
-Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-Draft, draft-ietf-oauth-selective-disclosure-jwt-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-06>.
-
-
[I-D.looker-oauth-jwt-cwt-status-list]
-
-Looker, T. and P. Bastian, "JWT and CWT Status List", Work in Progress, Internet-Draft, draft-looker-oauth-jwt-cwt-status-list-01, , <https://datatracker.ietf.org/doc/html/draft-looker-oauth-jwt-cwt-status-list-01>.
-
-
[I-D.terbu-sd-jwt-vc]
-
-Terbu, O. and D. Fett, "SD-JWT-based Verifiable Credentials with JSON payloads (SD-JWT VC)", Work in Progress, Internet-Draft, draft-terbu-sd-jwt-vc-02, , <https://datatracker.ietf.org/doc/html/draft-terbu-sd-jwt-vc-02>.
-
-
[OIDF.OID4VCI]
-
-Lodderstedt, T., Yasuda, K., and T. Looker, "OpenID for Verifiable Credential Issuance", , <https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html>.
-
-
[OIDF.OID4VP]
-
-Terbu, O., Lodderstedt, T., Yasuda, K., Lemmon, A., and T. Looker, "OpenID for Verifiable Presentations", , <https://openid.net/specs/openid-4-verifiable-presentations-1_0.html>.
-
-
[OIDF.SIOPv2]
-
-Microsoft, Jones, M. B., and T. Lodderstedt, "Self-Issued OpenID Provider V2", , <https://openid.net/specs/openid-connect-self-issued-v2-1_0.html>.
-
-
[OIDF.ekyc-ida]
-
-yes, Fett, D., Haine, M., Pulido, A., Lehmann, K., and K. Koiwai, "OpenID Connect for Identity Assurance 1.0", , <https://openid.net/specs/openid-connect-4-identity-assurance-1_0-ID4.html>.
-
-
[RFC5280]
-
-Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/info/rfc5280>.
-
-
[RFC5646]
-
-Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, , <https://www.rfc-editor.org/info/rfc5646>.
-
-
[RFC7515]
-
-Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, , <https://www.rfc-editor.org/info/rfc7515>.
-
-
[RFC7517]
-
-Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, , <https://www.rfc-editor.org/info/rfc7517>.
-
-
[RFC7519]
-
-Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, , <https://www.rfc-editor.org/info/rfc7519>.
-
-
[RFC7636]
-
-Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, , <https://www.rfc-editor.org/info/rfc7636>.
-
-
[RFC7800]
-
-Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, , <https://www.rfc-editor.org/info/rfc7800>.
-
-
[RFC9101]
-
-Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)", RFC 9101, DOI 10.17487/RFC9101, , <https://www.rfc-editor.org/info/rfc9101>.
-
-
[RFC9126]
-
-Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, , <https://www.rfc-editor.org/info/rfc9126>.
-
-
-
-
-

-10.2. Informative References -

-
-
[ISO.18013-5]
-
-ISO/IEC JTC 1/SC 17 Cards and security devices for personal identification, "ISO/IEC 18013-5:2021 Personal identification — ISO-compliant driving license — Part 5: Mobile driving license (mDL) application", , <https://www.iso.org/standard/69084.html>.
-
-
-
-
-
-
-

-Appendix A. Combined Issuance of SD-JWT VC and mdocs -

-
    -
  • If combined issuance is required, the Batch Credential Endpoint MUST be supported. -
    • -
-
-
-
-
-

-Appendix B. JSON Schema for the supported Presentation Definition properties -

-
-
{
-    "$schema": "http://json-schema.org/draft-07/schema#",
-    "title": "Presentation Definition for a High Assurance Profile",
-    "type": "object",
-    "properties": {
-      "presentation_definition": {
-        "$ref": "#/definitions/presentation_definition"
-      }
-    },
-    "definitions": {
-      "presentation_definition": {
-        "type": "object",
-        "properties": {
-          "id": {
-            "type": "string"
-          },
-          "input_descriptors": {
-            "type": "array",
-            "items": {
-              "$ref": "#/definitions/input_descriptor"
-            }
-          },
-          "submission_requirements": {
-            "type": "array",
-            "items": {
-              "$ref": "#/definitions/submission_requirement"
-            }
-          }
-        },
-        "required": [
-          "id",
-          "input_descriptors"
-        ],
-        "additionalProperties": false
-      },
-      "input_descriptor": {
-        "type": "object",
-        "additionalProperties": false,
-        "properties": {
-          "id": {
-            "type": "string"
-          },
-          "name": {
-            "type": "string"
-          },
-          "purpose": {
-            "type": "string"
-          },
-          "format": {
-            "$ref": "http://identity.foundation/claim-format-registry/schemas/presentation-definition-claim-format-designations.json"
-          },
-          "group": {
-            "type": "array",
-            "items": {
-              "type": "string"
-            }
-          },
-          "constraints": {
-            "type": "object",
-            "additionalProperties": false,
-            "properties": {
-              "limit_disclosure": {
-                "type": "string",
-                "enum": [
-                  "required",
-                  "preferred"
-                ]
-              },
-              "fields": {
-                "type": "array",
-                "items": {
-                  "path": {
-                    "type": "array",
-                    "items": {
-                      "type": "string"
-                    }
-                  },
-                  "filter": {
-                    "$ref": "http://json-schema.org/draft-07/schema#"
-                  }
-                }
-              }
-            }
-          }
-        },
-        "required": [
-          "id",
-          "constraints"
-        ]
-      },
-      "submission_requirement": {
-        "type": "object",
-        "oneOf": [
-          {
-            "properties": {
-              "name": {
-                "type": "string"
-              },
-              "rule": {
-                "type": "string",
-                "enum": [
-                  "pick"
-                ]
-              },
-              "count": {
-                "type": "integer",
-                "minimum": 1
-              },
-              "from": {
-                "type": "string"
-              }
-            },
-            "required": [
-              "rule",
-              "from"
-            ],
-            "additionalProperties": false
-          }
-        ]
-      }
-    }
-  }
-
-
-
-
-
-
-
-
-

-Authors' Addresses -

-
-
Kristina Yasuda
-
Microsoft
- -
-
-
Torsten Lodderstedt
-
sprind.org
- -
-
-
- - - diff --git a/tl/change_affiliation/draft-oid4vc-haip-sd-jwt-vc.txt b/tl/change_affiliation/draft-oid4vc-haip-sd-jwt-vc.txt deleted file mode 100644 index 754d759..0000000 --- a/tl/change_affiliation/draft-oid4vc-haip-sd-jwt-vc.txt +++ /dev/null @@ -1,1102 +0,0 @@ - - - - -OpenID Connect K. Yasuda - Microsoft - T. Lodderstedt - sprind.org - 16 November 2023 - - - OpenID4VC High Assurance Interoperability Profile with SD-JWT VC - draft-oid4vc-haip-sd-jwt-vc-latest - -Abstract - - This document defines a profile of OpenID for Verifiable Credentials - in combination with the credential format SD-JWT VC. The aim is to - select features and to define a set of requirements for the existing - specifications to enable interoperability among Issuers, Wallets and - Verifiers of Credentials where a high level of security and privacy - is required. The profiled specifications include OpenID for - Verifiable Credential Issuance [OIDF.OID4VCI], OpenID for Verifiable - Presentations [OIDF.OID4VP], Self-Issued OpenID Provider v2 - [OIDF.SIOPv2], and SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc]. - -Table of Contents - - 1. Introduction - 1.1. Audience Target audience/Usage - 2. Terminology - 3. Scope - 3.1. Out of Scope - 3.2. Scenarios/Business Requirements - 3.3. Standards Requirements - 4. OpenID for Verifiable Credential Issuance - 4.1. Credential Offer - 4.2. Authorization Endpoint - 4.3. Token Endpoint - 4.3.1. Wallet Attestation Schema - 4.4. Credential Endpoint - 4.5. Server Metadata - 5. OpenID for Verifiable Presentations - 6. Self-Issued OP v2 - 7. SD-JWT VCs - 7.1. Issuer identification and key resolution to validate an - issued Credential - 7.1.1. Cryptographic Holder Binding between VC and VP - 7.2. OpenID4VC Credential Format Profile - 7.2.1. Format Identifier - 7.2.2. Credential Issuer Metadata - 7.2.3. Credential Offer - 7.2.4. Authorization Details - 7.2.5. Credential Request - 7.2.6. Credential Response - 7.2.7. Verifier Metadata - 7.2.8. Presentation Definition - 8. Crypto Suites - 9. Implementations Considerations - 9.1. Validity Period of the Signature and the Claim Values - 10. References - 10.1. Normative References - 10.2. Informative References - Appendix A. Combined Issuance of SD-JWT VC and mdocs - Appendix B. JSON Schema for the supported Presentation Definition - properties - Authors' Addresses - -1. Introduction - - This document defines a set of requirements for the existing - specifications to enable interoperability among Issuers, Wallets and - Verifiers of Credentials where a high level of security and privacy - is required. This document is an interoperability profile that can - be used by implementations in various contexts, be it a certain - industry or a certain regulatory environment. - - This document is not a specification, but a profile. It refers to - the specifications required for implementations to interoperate among - each other and for the optionalities mentioned in the referenced - specifications, defines the set of features to be mandatory to - implement. - - The profile uses OpenID for Verifiable Credential Issuance - [OIDF.OID4VCI] and OpenID for Verifiable Presentations [OIDF.OID4VP] - as the base protocols for issuance and presentation of Credentials, - respectively. The credential format used is SD-JWT VC as specified - in [I-D.ietf-oauth-sd-jwt-vc]. Additionally, considerations are - given on how deployments can perform a combined issuance of - credentials in both SD-JWT VC and ISO mdoc [ISO.18013-5] formats. - - A full list of the open standards used in this profile can be found - in Overview of the Open Standards Requirements (reference). - -1.1. Audience Target audience/Usage - - The audience of the document is implementers that require a high - level of security and privacy for their solutions. A non-exhaustive - list of the interested parties includes eIDAS 2.0, California - Department of Motor Vehicles, Open Wallet Foundation (OWF), IDunion, - GAIN, and the Trusted Web project of the Japanese government, but is - expected to grow to include other jurisdictions and private sector - companies. - -2. Terminology - - This specification uses the terms "Holder", "Issuer", "Verifier", and - "Verifiable Credential" as defined in [I-D.ietf-oauth-sd-jwt-vc]. - -3. Scope - - The following aspects are in scope of this interoperability profile: - - * Protocol for issuance of the Verifiable Credentials (can be both - remote and in-person) (OID4VCI) - * Protocol for online presentation of Verifiable Credentials (can be - both remote and in-person) (OID4VP) - * Protocol for User Authentication by the Wallet at a Verifier (SIOP - v2) - * Wallet Attestation (during Credential issuance) - * Credential Format (SD-JWT VC) - * Status Management of the Credentials, including revocation - * Cryptographic Holder Binding - * Issuer key resolution - * Issuer identification (as prerequisite for trust management) - * Crypto Suites - - Assumptions made are the following: - - * The issuers and verifiers cannot pre-discover wallet’s capability - * The issuer is talking to the wallet supporting the features - defined in this profile (via wallet invocation mechanism) - * There are mechanisms in place for the verifiers and issuers to - discover each other’s capability - -3.1. Out of Scope - - The following items are out of scope for the current version of this - document, but might be added in future versions: - - * Trust Management, i.e. authorization of an issuer to issue certain - types of credentials, authorization of the Wallet to be issued - certain types of credentials, authorization of the Verifier to - receive certain types of credentials. - * Protocol for presentation of Verifiable Credentials for offline - use-cases, e.g. over BLE. - -3.2. Scenarios/Business Requirements - - * Combined Issuance of SD-JWT VC and mdoc - * Both issuer-initiated and wallet-initiated issuance - * eIDAS PID and (Q)EAA as defined in eIDAS ARF 1.0 - -3.3. Standards Requirements - - Unless explicitly stated, all normative requirements apply to all - participating entities: Issuers, Wallets and Verifiers. - - +==============================+========+========+==========+ - | (as defined in this profile) | Issuer | Wallet | Verifier | - +==============================+========+========+==========+ - | OID4VP | N/A | MUST | MUST | - +------------------------------+--------+--------+----------+ - | OID4VCI | MUST | MUST | N/A | - +------------------------------+--------+--------+----------+ - | SIOPv2 | N/A | MUST | SHOULD | - +------------------------------+--------+--------+----------+ - | SD-JWT VC profile as defined | MUST | MUST | MUST | - | in Section 7 | | | | - +------------------------------+--------+--------+----------+ - - Table 1 - -4. OpenID for Verifiable Credential Issuance - - Implementations of this profile: - - * MUST support both pre-auth code flow and authorization code flow. - * MUST support protocol extensions for SD-JWT VC credential format - profile as defined in this specification Section 7.2. - * MUST support sender-constrained Tokens using a mechanism as - defined in [I-D.ietf-oauth-dpop]. - * MUST support [RFC7636] with S256 as the code challenge method. - - Both Wallet initiated and Issuer initiated issuance is supported. - -4.1. Credential Offer - - * The Grant Types authorization_code and - urn:ietf:params:oauth:grant-type:pre-authorized_code MUST be - supported as defined in Section 4.1.1 in [OIDF.OID4VCI] - * For Grant Type authorization_code, the Issuer MUST include a scope - value in order to allow the Wallet to identify the desired - credential type. The wallet MUST use that value in the scope - Authorization parameter. For Grant Type - urn:ietf:params:oauth:grant-type:pre-authorized_code, the pre- - authorized code is used by the issuer to identify the credential - type(s). (pending OID4VCI PR#519) - * 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. - - Note: The Authorization Code flow does not require a Credential Offer - from the Issuer to the Wallet. However, it is included in the - feature set of the Credential Offer because it might be easier to - implement with existing libraries and on top of existing - implementations than the pre-authorized code Grant Type. - - Both sending Credential Offer same-device and cross-device is - supported. - -4.2. Authorization Endpoint - - * MUST use Pushed Authorization Requests (PAR) [RFC9126] to send the - Authorization Request. - * Wallets MUST authenticate itself at the PAR endpoint using the - same rules as defined in Section 4.3 for client authentication at - the token endpoint. - * MUST use scope parameter to communicate credential type(s) to be - issued. The scope value MUST map to a specific Credential type. - The scope value may be pre-agreed, obtained from the Credential - Offer, or the Credential Issuer Metadata. - * The client_id value in the PAR request MUST be a string that the - Wallet has used as the sub value in the client attestation JWT. - -4.3. Token Endpoint - - * The Wallets MUST perform client authentication as defined in - [I-D.ietf-oauth-attestation-based-client-auth]. - * Refresh tokens MUST be supported for credential refresh. - * Wallets MUST support deferred authorization by being able to - process the Token error response parameters authorization_pending - and slow_down, and the credential offer parameter interval. - * The Wallet Attestation JWT scheme is defined in Section 4.3.1. - - Note: It is RECOMMENDED to use ephemeral client attestation JWTs for - client authentication in order to prevent linkability across - Credential Issuers. - - Note: Issuers should be mindful of how long the usage of the refresh - token is allowed to refresh a credential, as opposed to starting the - issuance flow from the beginning. For example, if the User is trying - to refresh a credential more than a year after its original issuance, - the usage of the refresh tokens is NOT RECOMMENDED. - -4.3.1. Wallet Attestation Schema - - Wallets MUST use attestations following the definition given in - [I-D.ietf-oauth-attestation-based-client-auth]. - - In addition to this definition, the Wallet Attestation MAY contain - the following claims in the cnf element: - - * key_type: OPTIONAL. JSON String that asserts the security - mechanism the Wallet uses to manage the private key associated - with the public key given in the cnf claim. This mechanism is - based on the capabilities of the execution environent of the - Wallet, this might be a secure element (in case of a wallet - residing on a smartphone) or a Cloud-HSM (in case of a cloud - Wallet). This specification defines the following values for - key_type: - - software: It MUST be used when the Wallet uses software-based - key management. - - hardware: It MUST be used when the wallet uses hardware-based - key management. - - tee: It SHOULD be used when the Wallet uses the Trusted - Execution Environment for key management. - - secure_enclave: It SHOULD be used when the Wallet uses the - Secure Enclave for key management. - - strong_box: It SHOULD be used when the Wallet uses the - Strongbox for key management. - - secure_element: It SHOULD be used when the Wallet uses a Secure - Element for key management. - - hsm: It SHOULD be used when the Wallet uses Hardware Security - Module (HSM). - * user_authentication: OPTIONAL. JSON String that asserts the - security mechanism the Wallet uses to authenticate the user to - authorize access to the private key associated with the public key - given in the cnf claim. This specification defines the following - values for user_authentication: - - system_biometry: It MUST be used when the key usage is - authorized by the mobile operating system using a biometric - factor. - - system_pin: It MUST be used when the key usage is authorized by - the mobile operating system using personal identification - number (PIN). - - internal_biometry: It MUST be used when the key usage is - authorized by the Wallet using a biometric factor. - - internal_pin: It MUST be used when the key usage is authorized - by the Wallet using PIN. - - secure_element_pin It MUST be used when the key usage is - authorized by the secure element managing the key itself using - PIN. - - The Wallet Attestation MAY also contain the following claim: - - * aal: OPTIONAL. JSON String asserting the authentication level of - the Wallet and the key as asserted in the cnf claim. - - To obtain the issuer's Public key for verification, wallet attestions - MUST support web-based key resolution as defined in Section 5 of - [I-D.terbu-sd-jwt-vc]. The JOSE header kid MUST be used to identify - the respective key. - - This is an example of a Wallet Instance Attestation: - - { - "typ": "wallet-attestation+jwt", - "alg": "ES256", - "kid": "1" - } - . - { - "iss": "", - "sub": "<`client_id` of the OAuth client>", - "iat": 1516247022, - "exp": 1541493724, - "aal" : "https://trust-list.eu/aal/high", - "cnf": { - "jwk": { - "kty": "EC", - "crv": "P-256", - "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", - "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" - }, - "key_type": "strong_box", - "user_authentication": "system_pin", - } - } - -4.4. Credential Endpoint - - * The JWT proof type MUST be supported. - -4.5. Server Metadata - - * The Credential Issuer MUST publish a mapping of every Credential - Type it supports to a scope value. - -5. OpenID for Verifiable Presentations - - * MUST support protocol extensions for SD-JWT VC credential format - profile as defined in this specification Section 7.2. - - * 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. - - * Response type MUST be vp_token. - - * Response mode MUST be direct_post with redirect_uri as defined in - Section 6.2 of [OIDF.OID4VP]. - - * Authorization Request MUST be sent using the request_uri parameter - as defined in JWT-Secured Authorization Request (JAR) [RFC9101]. - - * client_id_scheme parameter MUST be present in the Authorization - Request. - - * client_id_scheme value MUST be either x509_san_dns or - verifier_attestation. Wallet MUST support both. Verifier MUST - support at least one. (pending OID4VCI PR #524 for - verifier_attestation) - - * To obtain the issuer's public key for verification, verifiers MUST - support web-based key resolution as defined in Section 5 of - [I-D.ietf-oauth-sd-jwt-vc]. The JOSE header kid MUST be used to - identify the respective key. - - * Presentation Definition JSON object MUST be sent using a - presentation_definition parameter. - - * The following features from the DIF Presentation Exchange v2.0.0 - MUST be supported. A JSON schema for the supported features is in - Appendix B: - - - In the presentation_definition object, id, input_descriptors - and submission_requirements properties MUST be supported. - - In the input-descriptors object, id, name, purpose, group, - format, and constraints properties MUST be supported. In the - constraints object, limit_disclosure, and fields properties - MUST be supported. In the fields object, path and filter - properties MUST be supported. A path MUST contain exactly one - entry with a static path to a certain claim. A filter MUST - only contain type elements of value string and const elements. - - In the submission_requirements object, name, rule (pickonly), - count, from properties MUST be supported. - -6. Self-Issued OP v2 - - To authenticate the user, subject identifier in a Self-Issued ID - Token MUST be used as defined in [OIDF.SIOPv2]. - - * 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 - -7. SD-JWT VCs - - 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. - - * 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) - - +========+================+========================================+ - | Claim | SD-JWT as | Normative Definition | - | | issued by the | | - | | Issuer | | - +========+================+========================================+ - | iss | MUST | [RFC7519], Section 4.1.1 | - +--------+----------------+----------------------------------------+ - | iat | MUST | [RFC7519], Section 4.1.6 | - +--------+----------------+----------------------------------------+ - | exp | SHOULD (at the | [RFC7519], Section 4.1.4 | - | | discretion of | | - | | the issuer) | | - +--------+----------------+----------------------------------------+ - | cnf | MUST | [RFC7800] | - +--------+----------------+----------------------------------------+ - | vct | MUST | [I-D.ietf-oauth-sd-jwt-vc] | - +--------+----------------+----------------------------------------+ - | status | SHOULD (at the | [I-D.looker-oauth-jwt-cwt-status-list] | - | | discretion of | | - | | the issuer) | | - +--------+----------------+----------------------------------------+ - - Table 2 - - * 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 iss claim MUST be an HTTPS URL. The iss value is used to - obtain Issuer’s signing key as defined in Section 7.1. - * 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. - - 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 - (https://bitbucket.org/openid/connect/issues/1537/presenting-vc- - without-a-vp-using-openid4vp) - - Note: Re-using the same Credential across Verifiers, or re-using the - same JWK value across multiple Credentials gives colluding Verifiers - a mechanism to correlate the User. There are currently two known - ways to address this with SD-JWT VCs. First is to issue multiple - instances of the same credentials with different JWK values, so that - if each instance of the credential is used at only one Verifier, it - can be reused multiple times. Another is to use each credential only - once (ephemeral credentials). It is RECOMMENDED to adopt one of - these mechanisms. - - Note: If there is a requirement to communicate information about the - verification status and identity assurance data of the claims about - the subject, the syntax defined by [OIDF.ekyc-ida] SHOULD be used. - It is up to each jurisdiction and ecosystem, whether to require it to - the implementers of this profile. - - Note: If there is a requirement to provide the Subject’s identifier - assigned and maintained by the Issuer, sub claim MAY be used. There - is no requirement for a binding to exist between sub and cnf claims. - See Implementation Considerations section in - [I-D.ietf-oauth-sd-jwt-vc]. - - Note: In some credential types, it is not desirable to include an - expiration date (eg: diploma attestation). Therefore, this profile - leaves its inclusion to the Issuer, or the body defining the - respective credential type. - -7.1. Issuer identification and key resolution to validate an issued - Credential - - This profile supports two ways to represent and resolve the key - required to validate the issuer signature of an SD-JWT VC, the web - PKI-based key resolution and the x.509 certificates. - - * Web-based key resolution: The key used to validate the Issuer’s - signature on the SD-JWT VC MUST be obtained from the SD-JWT VC - issuer's metadata as defined in Section 5 of - [I-D.ietf-oauth-sd-jwt-vc]. The JOSE header kid MUST be used to - identify the respective key. - * x.509 certificates: the SD-JWT VC contains the issuer's - certificate along with a trust chain in the x5c JOSE header. In - this case, the iss value MUST be an URL with a FQDN matching a - dNSName Subject Alternative Name (SAN) [RFC5280] entry in the leaf - certificate. - - Note: The issuer MAY decide to support both options. In which case, - it is at the discretion of the Wallet and the Verifier which key to - use for the issuer signature validation. - -7.1.1. Cryptographic Holder Binding between VC and VP - - * For Cryptographic Holder Binding, a KB-JWT as defined in - [I-D.ietf-oauth-sd-jwt-vc] MUST always be present when presenting - an SD-JWT VC. - -7.2. OpenID4VC Credential Format Profile - - This section specifies how SD-JWT VCs as defined in - [I-D.ietf-oauth-sd-jwt-vc] are used in conjunction with the OpenID4VC - specifications. - -7.2.1. Format Identifier - - The Credential format identifier is vc+sd-jwt. This format - identifier is used in issuance and presentation requests. - -7.2.2. Credential Issuer Metadata - - The following additional Credential Issuer metadata are defined for - this Credential format to be used in addition to those defined in - Section 10.2 of [OIDF.OID4VCI]. - - * credential_definition: REQUIRED. JSON object containing the - detailed description of the credential type. It consists at least - of the following three sub elements: - - vct: REQUIRED. JSON string designating the type of a - credential as defined in [I-D.ietf-oauth-sd-jwt-vc], - Section 4.2.2.1. - - claims: OPTIONAL. A JSON object containing a list of name/ - value pairs, where each name identifies a claim offered in the - Credential. The value can be another such object (nested data - structures), or an array of such objects. To express the - specifics about the claim, the most deeply nested value MAY be - a JSON object that includes a following non-exhaustive list of - parameters defined by this specification: - o mandatory: OPTIONAL. Boolean which when set to true - indicates the claim MUST be present in the issued - Credential. If the mandatory property is omitted its - default should be assumed to be false. - o value_type: OPTIONAL. String value determining type of - value of the claim. A non-exhaustive list of valid values - defined by this specification are string, number, and image - media types such as image/jpeg as defined in IANA media type - registry for images (https://www.iana.org/assignments/media- - types/media-types.xhtml#image - (https://www.iana.org/assignments/media-types/media- - types.xhtml#image)). - o display: OPTIONAL. An array of objects, where each object - contains display properties of a certain claim in the - Credential for a certain language. Below is a non- - exhaustive list of valid parameters that MAY be included: - + name: OPTIONAL. String value of a display name for the - claim. - + locale: OPTIONAL. String value that identifies language - of this object represented as language tag values defined - in BCP47 [RFC5646]. There MUST be only one object for - each language identifier. - * order: OPTIONAL. An array of claims.display.name values that - lists them in the order they should be displayed by the Wallet. - - The following is a non-normative example of an object comprising - credentials_supported parameter of Credential format vc+sd-jwt. - - { - "format": "vc+sd-jwt", - "scope": "IdentityCredential_SD-JWT-VC", - "cryptographic_binding_methods_supported": [ - "did:example" - ], - "cryptographic_suites_supported": [ - "ES256K" - ], - "display": [ - { - "name": "IdentityCredential", - "locale": "en-US", - "background_color": "#12107c", - "text_color": "#FFFFFF" - } - ], - "credential_definition": { - "type": "IdentityCredential", - "claims": { - "given_name": { - "display": [ - { - "name": "Given Name", - "locale": "en-US" - }, - { - "name": "Vorname", - "locale": "de-DE" - } - ] - }, - "last_name": { - "display": [ - { - "name": "Surname", - "locale": "en-US" - }, - { - "name": "Nachname", - "locale": "de-DE" - } - ] - }, - "email": {}, - "phone_number": {}, - "address": { - "street_address": {}, - "locality": {}, - "region": {}, - "country": {} - }, - "birthdate": {}, - "is_over_18": {}, - "is_over_21": {}, - "is_over_65": {} - } - } - } - - - { - "type": "IdentityCredential", - "given_name": "John", - "family_name": "Doe", - } - -7.2.3. Credential Offer - - The following additional claims are defined for this Credential - format. - - * credential_definition: REQUIRED. JSON object containing the - detailed description of the credential type. It MUST contain at - least type property as defined in Section 7.2.2. - - The following is a non-normative example of an object comprising - credentials_supported parameter of Credential format vc+sd-jwt. - - { - "credential_issuer": "https://credential-issuer.example.com", - "credentials": [ - "IdentityCredential_SD-JWT-VC" - ], - "grants": { - "authorization_code": { - "issuer_state": "eyJhbGciOiJSU0Et...FYUaBy" - } - } - } - -7.2.4. Authorization Details - - The following additional claims are defined for authorization details - of type openid_credential and this Credential format. - - * credential_definition: REQUIRED. JSON object containing the - detailed description of the credential type. It MUST contain at - least type property as defined in Section 7.2.2. It MAY contain - claims property as defined in Section 7.2.2. - - The following is a non-normative example of an authorization details - object with Credential format vc+sd-jwt. - - [ - { - "type": "openid_credential", - "format": "vc+sd-jwt", - "credential_definition": { - "type": "IdentityCredential" - } - } - ] - -7.2.5. Credential Request - - The following additional parameters are defined for Credential - Requests and this Credential format. - - * credential_definition: REQUIRED. JSON object containing the - detailed description of the credential type. It MUST contain at - least vct property as defined in Section 7.2.2. It MAY contain - claims property as defined in Section 7.2.2. - - The following is a non-normative example of a Credential Request with - Credential format vc+sd-jwt. - - { - "format": "vc+sd-jwt", - "credential_definition": { - "type": "IdentityCredential" - }, - "proof": { - "proof_type": "jwt", - "jwt":"eyJraWQiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEva2V5cy8 - xIiwiYWxnIjoiRVMyNTYiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJzNkJoZFJrcXQzIiwiYXVkIjoiaHR - 0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJpYXQiOiIyMDE4LTA5LTE0VDIxOjE5OjEwWiIsIm5vbm - NlIjoidFppZ25zbkZicCJ9.ewdkIkPV50iOeBUqMXCC_aZKPxgihac0aW9EkL1nOzM" - } - } - -7.2.6. Credential Response - - The value of the credential claim in the Credential Response MUST be - a JSON string that is an SD-JWT VC. Credentials of this format are - already suitable for transfer and, therefore, they need not and MUST - NOT be re-encoded. - - The following is a non-normative example of a Credential Response - with Credential format vc+sd-jwt. - -7.2.7. Verifier Metadata - - The Verifier SHOULD add a vp_formats_supported element to its - metadata (e.g. in the client_metadata authorization request - parameter) to let the wallet know what protection algorithms it - supports in conjunction with SD-JWT VCs. The format element MUST - have the key vc+sd-jwt, the value is an object consisting of the - following elements: - - * sd-jwt_alg_values: OPTIONAL. A JSON array containing identifiers - of cryptographic algorithms the verifier supports for protection - of a SD-JWT. If present, the alg JOSE header (as defined in - [RFC7515]) of the presented SD-JWT MUST match one of the array - values. - * kb-jwt_alg_values: OPTIONAL. A JSON array containing identifiers - of cryptographic algorithms the verifier supports for protection - of a KB-JWT. If present, the alg JOSE header (as defined in - [RFC7515]) of the presented KB-JWT MUST match one of the array - values. - - The following is a non-normative example of client_metadata request - parameter value in a request to present a SD-JWT VC. - - { - "vp_formats": { - "vc+sd-jwt": { - "sd-jwt_alg_values": [ - "ES256", - "ES384" - ], - "kb-jwt_alg_values": [ - "ES256", - "ES384" - ] - } - } - } - -7.2.8. Presentation Definition - - The presentation of a SD-JWT VC is requested by adding an object - named vc+sd-jwt to the format object of an input_descriptor. The - object is empty. - - The following is a non-normative example of a presentation definition - for a SD-JWT VC. - - { - "id": "d76c51b7-ea90-49bb-8368-6b3d194fc131", - "input_descriptors": [ - { - "id": "IdentityCredential", - "format": { - "vc+sd-jwt": {} - }, - "constraints": { - "limit_disclosure": "required", - "fields": [ - { - "path": [ - "$.type" - ], - "filter": { - "type": "string", - "const": "IdentityCredential" - } - }, - { - "path": [ - "$.family_name" - ] - }, - { - "path": [ - "$.given_name" - ] - } - ] - } - } - ] - } - -8. 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 - * Wallet Instance Attestation - * DPoP - * HB 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. - - Note: When using this profile with other cryptosuites, it is - recommended to be explicit about which entity is required to support - which curve for signing and/or signature validation - -9. Implementations Considerations - -9.1. Validity Period of the Signature and the Claim Values - - iat and exp JWT claims express both the validity period of both the - signature and the claims about the subject, unless there is a - separate claim used to express the validity of the claims. - -10. References - -10.1. Normative References - - [I-D.ietf-oauth-attestation-based-client-auth] - Looker, T. and P. Bastian, "OAuth 2.0 Attestation-Based - Client Authentication", Work in Progress, Internet-Draft, - draft-ietf-oauth-attestation-based-client-auth-01, 23 - October 2023, . - - [I-D.ietf-oauth-dpop] - Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., - Jones, M. B., and D. Waite, "OAuth 2.0 Demonstrating - Proof-of-Possession at the Application Layer (DPoP)", Work - in Progress, Internet-Draft, draft-ietf-oauth-dpop-16, 13 - April 2023, . - - [I-D.ietf-oauth-sd-jwt-vc] - Terbu, O. and D. Fett, "SD-JWT-based Verifiable - Credentials (SD-JWT VC)", Work in Progress, Internet- - Draft, draft-ietf-oauth-sd-jwt-vc-01, 23 October 2023, - . - - [I-D.ietf-oauth-selective-disclosure-jwt] - Fett, D., Yasuda, K., and B. Campbell, "Selective - Disclosure for JWTs (SD-JWT)", Work in Progress, Internet- - Draft, draft-ietf-oauth-selective-disclosure-jwt-06, 23 - October 2023, . - - [I-D.looker-oauth-jwt-cwt-status-list] - Looker, T. and P. Bastian, "JWT and CWT Status List", Work - in Progress, Internet-Draft, draft-looker-oauth-jwt-cwt- - status-list-01, 10 July 2023, - . - - [I-D.terbu-sd-jwt-vc] - Terbu, O. and D. Fett, "SD-JWT-based Verifiable - Credentials with JSON payloads (SD-JWT VC)", Work in - Progress, Internet-Draft, draft-terbu-sd-jwt-vc-02, 26 May - 2023, . - - [OIDF.OID4VCI] - Lodderstedt, T., Yasuda, K., and T. Looker, "OpenID for - Verifiable Credential Issuance", 20 June 2022, - . - - [OIDF.OID4VP] - Terbu, O., Lodderstedt, T., Yasuda, K., Lemmon, A., and T. - Looker, "OpenID for Verifiable Presentations", 20 June - 2022, . - - [OIDF.SIOPv2] - Microsoft, Jones, M. B., and T. Lodderstedt, "Self-Issued - OpenID Provider V2", 18 December 2021, - . - - [OIDF.ekyc-ida] - yes, Fett, D., Haine, M., Pulido, A., Lehmann, K., and K. - Koiwai, "OpenID Connect for Identity Assurance 1.0", 19 - August 2022, . - - [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., - Housley, R., and W. Polk, "Internet X.509 Public Key - Infrastructure Certificate and Certificate Revocation List - (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, - . - - [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying - Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, - September 2009, . - - [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web - Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May - 2015, . - - [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, - DOI 10.17487/RFC7517, May 2015, - . - - [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token - (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, - . - - [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key - for Code Exchange by OAuth Public Clients", RFC 7636, - DOI 10.17487/RFC7636, September 2015, - . - - [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- - Possession Key Semantics for JSON Web Tokens (JWTs)", - RFC 7800, DOI 10.17487/RFC7800, April 2016, - . - - [RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 - Authorization Framework: JWT-Secured Authorization Request - (JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021, - . - - [RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., - and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", - RFC 9126, DOI 10.17487/RFC9126, September 2021, - . - -10.2. Informative References - - [ISO.18013-5] - ISO/IEC JTC 1/SC 17 Cards and security devices for - personal identification, "ISO/IEC 18013-5:2021 Personal - identification — ISO-compliant driving license — Part 5: - Mobile driving license (mDL) application", 2021, - . - -Appendix A. Combined Issuance of SD-JWT VC and mdocs - - * If combined issuance is required, the Batch Credential Endpoint - MUST be supported. - -Appendix B. JSON Schema for the supported Presentation Definition - properties - - { - "$schema": "http://json-schema.org/draft-07/schema#", - "title": "Presentation Definition for a High Assurance Profile", - "type": "object", - "properties": { - "presentation_definition": { - "$ref": "#/definitions/presentation_definition" - } - }, - "definitions": { - "presentation_definition": { - "type": "object", - "properties": { - "id": { - "type": "string" - }, - "input_descriptors": { - "type": "array", - "items": { - "$ref": "#/definitions/input_descriptor" - } - }, - "submission_requirements": { - "type": "array", - "items": { - "$ref": "#/definitions/submission_requirement" - } - } - }, - "required": [ - "id", - "input_descriptors" - ], - "additionalProperties": false - }, - "input_descriptor": { - "type": "object", - "additionalProperties": false, - "properties": { - "id": { - "type": "string" - }, - "name": { - "type": "string" - }, - "purpose": { - "type": "string" - }, - "format": { - "$ref": "http://identity.foundation/claim-format-registry/schemas/presentation-definition-claim-format-designations.json" - }, - "group": { - "type": "array", - "items": { - "type": "string" - } - }, - "constraints": { - "type": "object", - "additionalProperties": false, - "properties": { - "limit_disclosure": { - "type": "string", - "enum": [ - "required", - "preferred" - ] - }, - "fields": { - "type": "array", - "items": { - "path": { - "type": "array", - "items": { - "type": "string" - } - }, - "filter": { - "$ref": "http://json-schema.org/draft-07/schema#" - } - } - } - } - } - }, - "required": [ - "id", - "constraints" - ] - }, - "submission_requirement": { - "type": "object", - "oneOf": [ - { - "properties": { - "name": { - "type": "string" - }, - "rule": { - "type": "string", - "enum": [ - "pick" - ] - }, - "count": { - "type": "integer", - "minimum": 1 - }, - "from": { - "type": "string" - } - }, - "required": [ - "rule", - "from" - ], - "additionalProperties": false - } - ] - } - } - } - -Authors' Addresses - - Kristina Yasuda - Microsoft - Email: kristina.yasuda@microsoft.com - - - Torsten Lodderstedt - sprind.org - Email: torsten@lodderstedt.net diff --git a/tl/change_affiliation/index.html b/tl/change_affiliation/index.html deleted file mode 100644 index 4794df7..0000000 --- a/tl/change_affiliation/index.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - vcstuff/oid4vc-haip-sd-jwt-vc tl/change_affiliation preview - - - - -

Editor's drafts for tl/change_affiliation branch of vcstuff/oid4vc-haip-sd-jwt-vc

- - - - - - -
oid4vc-haip-sd-jwt-vcplain textsame as main
- - -