OpenID4VC High Assurance Interoperability Profile with SD-JWT VC - draft 00

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).¶

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¶

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.¶

{
  "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",
  }
}

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)¶

• 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, 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.¶

{
    "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",
}

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

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

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

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
    "format": "vc+sd-jwt",
    "credential": "eyJhbGciOiAiRVMyNTYifQ.eyJfc2QiOiBbIjA5dktySk1PbHlUV00wc2pwdV9wZE9CV
kJRMk0xeTNLaHBINTE1blhrcFkiLCAiMnJzakdiYUMwa3k4bVQwcEpyUGlvV1RxMF9kY
Xcxc1g3NnBvVWxnQ3diSSIsICJFa084ZGhXMGRIRUpidlVIbEVfVkNldUM5dVJFTE9pZ
UxaaGg3WGJVVHRBIiwgIklsRHpJS2VpWmREd3BxcEs2WmZieXBoRnZ6NUZnbldhLXNON
ndxUVhDaXciLCAiSnpZakg0c3ZsaUgwUjNQeUVNZmVadTZKdDY5dTVxZWhabzdGN0VQW
WxTRSIsICJQb3JGYnBLdVZ1Nnh5bUphZ3ZrRnNGWEFiUm9jMkpHbEFVQTJCQTRvN2NJI
iwgIlRHZjRvTGJnd2Q1SlFhSHlLVlFaVTlVZEdFMHc1cnREc3JaemZVYW9tTG8iLCAia
mRyVEU4WWNiWTRFaWZ1Z2loaUFlX0JQZWt4SlFaSUNlaVVRd1k5UXF4SSIsICJqc3U5e
VZ1bHdRUWxoRmxNXzNKbHpNYVNGemdsaFFHMERwZmF5UXdMVUs0Il0sICJpc3MiOiAia
HR0cHM6Ly9leGFtcGxlLmNvbS9pc3N1ZXIiLCAiaWF0IjogMTY4MzAwMDAwMCwgImV4c
CI6IDE4ODMwMDAwMDAsICJ0eXBlIjogIklkZW50aXR5Q3JlZGVudGlhbCIsICJfc2RfY
WxnIjogInNoYS0yNTYiLCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiO
iAiUC0yNTYiLCAieCI6ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsc
zd2Q2VHZW1jIiwgInkiOiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2d
DRqVDlGMkhaUSJ9fX0.mEkoDmCa5YFFl5DV111elGsZAhsOdtnPTEUClR1rix57k6A-_
ovF5BufP8yCAlTzM4hypYNyb3i2xGUPb7EpHQ~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STj
l3IiwgImdpdmVuX25hbWUiLCAiSm9obiJd~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BI
iwgImZhbWlseV9uYW1lIiwgIkRvZSJd~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwg
ImVtYWlsIiwgImpvaG5kb2VAZXhhbXBsZS5jb20iXQ~WyJlSThaV205UW5LUHBOUGVOZ
W5IZGhRIiwgInBob25lX251bWJlciIsICIrMS0yMDItNTU1LTAxMDEiXQ~WyJRZ19PNj
R6cUF4ZTQxMmExMDhpcm9BIiwgImFkZHJlc3MiLCB7InN0cmVldF9hZGRyZXNzIjogIj
EyMyBNYWluIFN0IiwgImxvY2FsaXR5IjogIkFueXRvd24iLCAicmVnaW9uIjogIkFueX
N0YXRlIiwgImNvdW50cnkiOiAiVVMifV0~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIi
wgImJpcnRoZGF0ZSIsICIxOTQwLTAxLTAxIl0~WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdW
ZRIiwgImlzX292ZXJfMTgiLCB0cnVlXQ~WyJHMDJOU3JRZmpGWFE3SW8wOXN5YWpBIiw
gImlzX292ZXJfMjEiLCB0cnVlXQ~WyJsa2x4RjVqTVlsR1RQVW92TU5JdkNBIiwgImlz
X292ZXJfNjUiLCB0cnVlXQ~",
    "c_nonce": "fGFF7UkhLa",
    "c_nonce_expires_in": 86400
}

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

{
    "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

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

Appendix C. Acknowledgements

We would like to thank Paul Bastian, Christian Bormann, Mike Jones, Oliver Terbu, Daniel Fett, and Giuseppe De Marco for their valuable feedback and contributions to this specification.¶

Appendix D. Notices

Copyright (c) 2023 The OpenID Foundation.¶

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.¶

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that MAY cover technology that MAY be required to practice this specification.¶

Authors' Addresses