diff --git a/examples/.DS_Store b/examples/.DS_Store deleted file mode 100644 index d55f44be..00000000 Binary files a/examples/.DS_Store and /dev/null differ diff --git a/examples/client_metadata/sd_jwt_vc_verifier_metadata.json b/examples/client_metadata/sd_jwt_vc_verifier_metadata.json new file mode 100644 index 00000000..b3bd6682 --- /dev/null +++ b/examples/client_metadata/sd_jwt_vc_verifier_metadata.json @@ -0,0 +1,8 @@ +{ + "vp_formats": { + "vc+sd-jwt": { + "sd-jwt_alg_values": ["ES256", "ES384"], + "kb-jwt_alg_values": ["ES256", "ES384"] + } + } +} \ No newline at end of file diff --git a/examples/credentials/sd_jwt_vc.json b/examples/credentials/sd_jwt_vc.json new file mode 100644 index 00000000..5a046de7 --- /dev/null +++ b/examples/credentials/sd_jwt_vc.json @@ -0,0 +1,25 @@ +{ + "_sd": [ + "3oUCnaKt7wqDKuyh-LgQozzfhgb8gO5Ni-RCWsWW2vA", + "8z8z9X9jUtb99gjejCwFAGz4aqlHf-sCqQ6eM_qmpUQ", + "Cxq4872UXXngGULT_kl8fdwVFkyK6AJfPZLy7L5_0kI", + "TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo", + "jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4", + "sFcViHN-JG3eTUyBmU4fkwusy5I1SLBhe1jNvKxP5xM", + "tiTngp9_jhC389UP8_k67MXqoSfiHq3iK6o9un4we_Y", + "xsKkGJXD1-e3I9zj0YyKNv-lU5YqhsEAF9NhOr8xga4" + ], + "iss": "https://example.com/issuer", + "iat": 1683000000, + "exp": 1883000000, + "vct": "https://credentials.example.com/identity_credential", + "_sd_alg": "sha-256", + "cnf": { + "jwk": { + "kty": "EC", + "crv": "P-256", + "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc", + "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ" + } + } +} \ No newline at end of file diff --git a/examples/credentials/sd_jwt_vc_unsecured.json b/examples/credentials/sd_jwt_vc_unsecured.json new file mode 100644 index 00000000..70f1e1d2 --- /dev/null +++ b/examples/credentials/sd_jwt_vc_unsecured.json @@ -0,0 +1,6 @@ +{ + "vct": "https://credentials.example.com/identity_credential", + "given_name": "John", + "family_name": "Doe", + "birthdate": "1940-01-01" +} \ No newline at end of file diff --git a/examples/request/pd_sd_jwt_vc.json b/examples/request/pd_sd_jwt_vc.json new file mode 100644 index 00000000..20419253 --- /dev/null +++ b/examples/request/pd_sd_jwt_vc.json @@ -0,0 +1,32 @@ +{ + "id": "example_sd_jwt_vc_request", + "input_descriptors": [ + { + "id": "identity_credential", + "format": { + "vc+sd-jwt": { + "sd-jwt_alg_values": ["ES256", "ES384"], + "kb-jwt_alg_values": ["ES256", "ES384"] + } + }, + "constraints": { + "limit_disclosure": "required", + "fields": [ + { + "path": ["$.vct"], + "filter": { + "type": "string", + "const": "https://credentials.example.com/identity_credential" + } + }, + { + "path": ["$.family_name"] + }, + { + "path": ["$.given_name"] + } + ] + } + } + ] +} diff --git a/examples/response/id_token_is_jwt_vp.json b/examples/response/id_token_is_jwt_vp.json index ab5ad38f..4ceadbc1 100644 --- a/examples/response/id_token_is_jwt_vp.json +++ b/examples/response/id_token_is_jwt_vp.json @@ -78,7 +78,7 @@ "presentation_submission": { "descriptor_map": [ { - "format": "jwt_vp", + "format": "jwt_vp_json", "id": "citizenship", "path": "$", "path_nested": { diff --git a/examples/response/id_token_ref_vp_token_multple_vps.json b/examples/response/id_token_ref_vp_token_multple_vps.json index 7983b93d..4ba00add 100644 --- a/examples/response/id_token_ref_vp_token_multple_vps.json +++ b/examples/response/id_token_ref_vp_token_multple_vps.json @@ -27,7 +27,7 @@ }, { "id": "Ontario Health Insurance Plan", - "format": "jwt_vp", + "format": "jwt_vp_json", "path": "$[1].presentation", "path_nested": { "format": "jwt_vc", diff --git a/examples/response/jarm_jwt_enc_only_vc_json_body.json b/examples/response/jarm_jwt_enc_only_vc_json_body.json index b03441e5..97c6da7a 100644 --- a/examples/response/jarm_jwt_enc_only_vc_json_body.json +++ b/examples/response/jarm_jwt_enc_only_vc_json_body.json @@ -7,7 +7,7 @@ { "id": "id_credential", "path": "$", - "format": "jwt_vp", + "format": "jwt_vp_json", "path_nested": { "path": "$.vp.verifiableCredential[0]", "format": "jwt_vc" diff --git a/examples/response/jarm_jwt_vc_json_body.json b/examples/response/jarm_jwt_vc_json_body.json index 09b24c8b..1cff5144 100644 --- a/examples/response/jarm_jwt_vc_json_body.json +++ b/examples/response/jarm_jwt_vc_json_body.json @@ -10,7 +10,7 @@ { "id": "id_credential", "path": "$", - "format": "jwt_vp", + "format": "jwt_vp_json", "path_nested": { "path": "$.vp.verifiableCredential[0]", "format": "jwt_vc" diff --git a/examples/response/kb_jwt_unsecured.json b/examples/response/kb_jwt_unsecured.json new file mode 100644 index 00000000..4ec99254 --- /dev/null +++ b/examples/response/kb_jwt_unsecured.json @@ -0,0 +1,6 @@ +{ + "nonce": "n-0S6_WzA2Mj", + "aud": "https://example.com/verifier", + "iat": 1709838604, + "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4" +} diff --git a/examples/response/ps_sd_jwt_vc.json b/examples/response/ps_sd_jwt_vc.json new file mode 100644 index 00000000..eae78b78 --- /dev/null +++ b/examples/response/ps_sd_jwt_vc.json @@ -0,0 +1,11 @@ +{ + "definition_id": "example_sd_jwt_vc_request", + "id": "example_sd_jwt_vc_presentation_submission", + "descriptor_map": [ + { + "id": "identity_credential", + "path": "$", + "format": "vc+sd-jwt" + } + ] +} \ No newline at end of file diff --git a/examples/response/token_response_vp_token_sd_jwt_vc.txt b/examples/response/token_response_vp_token_sd_jwt_vc.txt new file mode 100644 index 00000000..d99aca82 --- /dev/null +++ b/examples/response/token_response_vp_token_sd_jwt_vc.txt @@ -0,0 +1,23 @@ +eyJhbGciOiAiRVMyNTYiLCAidHlwIjogInZjK3NkLWp3dCIsICJraWQiOiAiZG9jLXNp +Z25lci0wNS0yNS0yMDIyIn0.eyJfc2QiOiBbIjNvVUNuYUt0N3dxREt1eWgtTGdRb3p6 +ZmhnYjhnTzVOaS1SQ1dzV1cydkEiLCAiOHo4ejlYOWpVdGI5OWdqZWpDd0ZBR3o0YXFs +SGYtc0NxUTZlTV9xbXBVUSIsICJDeHE0ODcyVVhYbmdHVUxUX2tsOGZkd1ZGa3lLNkFK +ZlBaTHk3TDVfMGtJIiwgIlRHZjRvTGJnd2Q1SlFhSHlLVlFaVTlVZEdFMHc1cnREc3Ja +emZVYW9tTG8iLCAianN1OXlWdWx3UVFsaEZsTV8zSmx6TWFTRnpnbGhRRzBEcGZheVF3 +TFVLNCIsICJzRmNWaUhOLUpHM2VUVXlCbVU0Zmt3dXN5NUkxU0xCaGUxak52S3hQNXhN +IiwgInRpVG5ncDlfamhDMzg5VVA4X2s2N01YcW9TZmlIcTNpSzZvOXVuNHdlX1kiLCAi +eHNLa0dKWEQxLWUzSTl6ajBZeUtOdi1sVTVZcWhzRUFGOU5oT3I4eGdhNCJdLCAiaXNz +IjogImh0dHBzOi8vZXhhbXBsZS5jb20vaXNzdWVyIiwgImlhdCI6IDE2ODMwMDAwMDAs +ICJleHAiOiAxODgzMDAwMDAwLCAidmN0IjogImh0dHBzOi8vY3JlZGVudGlhbHMuZXhh +bXBsZS5jb20vaWRlbnRpdHlfY3JlZGVudGlhbCIsICJfc2RfYWxnIjogInNoYS0yNTYi +LCAiY25mIjogeyJqd2siOiB7Imt0eSI6ICJFQyIsICJjcnYiOiAiUC0yNTYiLCAieCI6 +ICJUQ0FFUjE5WnZ1M09IRjRqNFc0dmZTVm9ISVAxSUxpbERsczd2Q2VHZW1jIiwgInki +OiAiWnhqaVdXYlpNUUdIVldLVlE0aGJTSWlyc1ZmdWVjQ0U2dDRqVDlGMkhaUSJ9fX0. +hBeB-fuMsIQ82QIE_674CSPIufs7w0D9CdfGdP_tGyBVp_vTSlbWb9MInFKSZ6Y3ie-r +0MMeSSEHyuUz9WNGSQ~WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uY +W1lIiwgIkRvZSJd~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUi +LCAiSm9obiJd~eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImtiK2p3dCJ9.eyJub25jZS +I6ICJuLTBTNl9XekEyTWoiLCAiYXVkIjogImh0dHBzOi8vZXhhbXBsZS5jb20vdmVyaW +ZpZXIiLCAiaWF0IjogMTcwOTgzODYwNCwgInNkX2hhc2giOiAiRHktUll3WmZhYW9DM2 +luSmJMc2xnUHZNcDA5YkgtY2xZUF8zcWJScXRXNCJ9.RmgIhqCHYWerxbDboMuB0lli6 +3HPJHI9Vl2ZNOGh20C7_6p7nf3Wkd2wkx5WlmwTwtHKc87MBY2nuRLoeduQMA \ No newline at end of file diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index c5039cbf..2b42f356 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -52,7 +52,7 @@ This specification defines a protocol for requesting and presenting Verifiable C # Introduction -This specification defines a mechanism on top of OAuth 2.0 [@!RFC6749] that enables presentation of Verifiable Credentials as Verifiable Presentations. Verifiable Credentials and Verifiable Presentations can be of any format, including, but not limited to W3C Verifiable Credentials Data Model [@VC_DATA], ISO mdoc [@ISO.18013-5], and AnonCreds [@Hyperledger.Indy]. +This specification defines a mechanism on top of OAuth 2.0 [@!RFC6749] that enables presentation of Verifiable Credentials as Verifiable Presentations. Verifiable Credentials and Verifiable Presentations can be of any format, including, but not limited to W3C Verifiable Credentials Data Model [@VC_DATA], ISO mdoc [@ISO.18013-5], IETF SD-JWT VC [@!I-D.ietf-oauth-sd-jwt-vc], and AnonCreds [@Hyperledger.Indy]. OAuth 2.0 [@!RFC6749] is used as a base protocol as it provides the required rails to build a simple, secure, and developer-friendly Credential presentation layer on top of it. Moreover, implementers can, in a single interface, support Credential presentation and the issuance of Access Tokens for access to APIs based on Verifiable Credentials in the Wallet. OpenID Connect [@!OpenID.Core] deployments can also extend their implementations using this specification with the ability to transport Verifiable Presentations. @@ -72,7 +72,7 @@ Credential: : A set of one or more claims about a subject made by a Credential Issuer. Note that the definition of the term "Credential" in this specification is different from that in [@!OpenID.Core]. Verifiable Credential (VC): -: An Issuer-signed Credential whose authenticity can be cryptographically verified. Can be of any format used in the Issuer-Holder-Verifier Model, including, but not limited to those defined in [@VC_DATA], [@ISO.18013-5] (mdoc) and [@Hyperledger.Indy] (AnonCreds). +: An Issuer-signed Credential whose authenticity can be cryptographically verified. Can be of any format used in the Issuer-Holder-Verifier Model, including, but not limited to those defined in [@VC_DATA] (VCDM), [@ISO.18013-5] (mdoc), [@!I-D.ietf-oauth-sd-jwt-vc] (SD-JWT VC), and [@Hyperledger.Indy] (AnonCreds). W3C Verifiable Credential: : A Verifiable Credential compliant to the [@VC_DATA] specification. @@ -81,7 +81,7 @@ Presentation: : Data that is presented to a specific Verifier, derived from one or more Verifiable Credentials that can be from the same or different Credential Issuers. Verifiable Presentation (VP): -: A Holder-signed Credential whose authenticity can be cryptographically verified to provide Cryptographic Holder Binding. Can be of any format used in the Issuer-Holder-Verifier Model, including, but not limited to those defined in [@VC_DATA], [@ISO.18013-5] (mdoc) and [@Hyperledger.Indy] (AnonCreds). +: A Holder-signed Credential whose authenticity can be cryptographically verified to provide Cryptographic Holder Binding. Can be of any format used in the Issuer-Holder-Verifier Model, including, but not limited to those defined in [@VC_DATA] (VCDM), [@ISO.18013-5] (mdoc), [@!I-D.ietf-oauth-sd-jwt-vc] (SD-JWT VC), and [@Hyperledger.Indy] (AnonCreds). W3C Verifiable Presentation: : A Verifiable Presentations compliant to the [@VC_DATA] specification. @@ -122,7 +122,7 @@ This specification defines a mechanism on top of OAuth 2.0 to request and presen As the primary extension, OpenID for Verifiable Presentations introduces the VP Token as a container to enable End-Users to present Verifiable Presentations to Verifiers using the Wallet. A VP Token contains one or more Verifiable Presentations in the same or different Credential formats. -This specification supports any Credential format used in the Issuer-Holder-Verifier Model, including, but not limited to those defined in [@VC_DATA], [@ISO.18013-5] (mdoc), and [@Hyperledger.Indy] (AnonCreds). Credentials of multiple formats can be presented in the same transaction. The examples given in the main part of this specification use W3C Verifiable Credentials, while examples in other Credential formats are given in (#alternative_credential_formats). +This specification supports any Credential format used in the Issuer-Holder-Verifier Model, including, but not limited to those defined in [@VC_DATA] (VCDM), [@ISO.18013-5] (mdoc), [@!I-D.ietf-oauth-sd-jwt-vc] (SD-JWT VC), and [@Hyperledger.Indy] (AnonCreds). Credentials of multiple formats can be presented in the same transaction. The examples given in the main part of this specification use W3C Verifiable Credentials, while examples in other Credential formats are given in (#alternative_credential_formats). Implementations can use any pre-existing OAuth 2.0 Grant Type and Response Type in conjunction with this specification to support different deployment architectures. @@ -223,7 +223,7 @@ OpenID for Verifiable Presentations extends existing OAuth 2.0 mechanisms as fol * A new `vp_token` response parameter is defined to return Verifiable Presentations to the Verifier in either Authorization or Token Response depending on the Response Type. See (#response) for more details. * New Response Types `vp_token` and `vp_token id_token` are defined to request Verifiable Credentials to be returned in the Authorization Response (standalone or along with a Self-Issued ID Token [@!SIOPv2]). See (#response) for more details. * A new OAuth 2.0 Response Mode `direct_post` is defined to support sending the response across devices, or when the size of the response exceeds the redirect URL character size limitation. See (#response_mode_post) for more details. -* The [@!DIF.PresentationExchange] `format` parameter is used throughout the protocol in order to enable customization according to the specific needs of a particular Credential format. Examples in (#alternative_credential_formats) are given for Credential formats as specified in [@VC_DATA], [@ISO.18013-5], and [@Hyperledger.Indy]. +* The [@!DIF.PresentationExchange] `format` parameter is used throughout the protocol in order to enable customization according to the specific needs of a particular Credential format. Examples in (#alternative_credential_formats) are given for Credential formats as specified in [@VC_DATA], [@ISO.18013-5], [@!I-D.ietf-oauth-sd-jwt-vc], and [@Hyperledger.Indy]. * A new `client_id_scheme` Authorization Request parameter is defined to enable deployments of this specification to use different mechanisms to obtain and validate metadata of the Verifier beyond the scope of [@!RFC6749]. Presentation of Verifiable Credentials using OpenID for Verifiable Presentations can be combined with the user authentication using [@SIOPv2], and the issuance of OAuth 2.0 Access Tokens. @@ -268,6 +268,8 @@ This specification defines the following new parameters: A public key to be used by the Wallet as an input to the key agreement to encrypt Authorization Response (see (#jarm)). It MAY be passed by the Verifier using the `jwks` or the `jwks_uri` claim within the `client_metadata` or `client_metadata_uri` request parameter. +`client-metadata` and `client_metadata_uri` parameters MUST NOT be used when the Wallet knows Client Identifier and corresponding Client metadata prior to the transaction (i.e., Client Identifier scheme is absent or has value `pre-registered`). + `request_uri_method`: : OPTIONAL. A string determining the HTTP method to be used when the `request_uri` parameter is included in the same request. Two case-sensitive valid values are defined in this specification: `get` and `post`. If `request_uri_method` value is `get`, the Wallet MUST send the request to retrieve the Request Object using the HTTP GET method, i.e., as defined in [@RFC9101]. If `request_uri_method` value is `post`, a supporting Wallet MUST send the request using the HTTP POST method as detailed in (#request_uri_method_post). If the `request_uri_method` parameter is not present, the Wallet MUST process the `request_uri` parameter as defined in [@RFC9101]. Wallets not supporting the `post` method will send a GET request to the request URI (default behavior as defined in [@RFC9101]). `request_uri_method` parameter MUST NOT be present if a `request_uri` parameter is not present. @@ -454,7 +456,7 @@ The following is a non-normative example of a request when `client_id` equals `r &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &presentation_definition=... &nonce=n-0S6_WzA2Mj - &client_metadata=%7B%22vp_formats%22:%7B%22jwt_vp%22:% + &client_metadata=%7B%22vp_formats%22:%7B%22jwt_vp_json%22:% 7B%22alg%22:%5B%22EdDSA%22,%22ES256K%22%5D%7D,%22ldp _vp%22:%7B%22proof_type%22:%5B%22Ed25519Signature201 8%22%5D%7D%7D%7D @@ -767,8 +769,6 @@ The error response follows the rules as defined in [@!RFC6749], with the followi - `client_metadata` or `client_metadata_uri` parameter defined in (#vp_token_request) is present, but the Wallet recognizes Client Identifier and knows metadata associated with it. - Verifier's pre-registered metadata has been found based on the Client Identifier, but `client_metadata` parameter is also present. -Usage of `client_metadata` or `client_metadata_uri` parameters with `client_id` that the Wallet might be seeing for the first time is mutually exclusive with the registration mechanism where Self-Issued OP assigns `client_id` to the Verifier after receiving Verifier metadata. - `access_denied`: - The Wallet did not have the requested Credentials to satisfy the Authorization Request. @@ -1234,7 +1234,7 @@ Requests from the Wallet to the Verifier SHOULD be sent with the minimal amount - + Self-Issued OpenID Provider V2 @@ -1673,6 +1673,100 @@ The VP Token contains the base64url encoded `DeviceResponse` CBOR structure as d See ISO/IEC TS 18013-7 Annex B [@ISO.18013-7] and ISO/IEC 23220-4 Annex C [@ISO.23220-4] for the latest examples on how to use the `presentation_submission` parameter and how to generate the Authorizaton Response for presenting Credentials in the mdoc format. +## IETF SD-JWT VC + +This section defines how Credentials complying with [@!I-D.ietf-oauth-sd-jwt-vc] can be presented to the Verifier using this specification. + +### Format Identifier + +The Credential format identifier is `vc+sd-jwt`. + +#### Example Credential + +The following is a non-normative example of the unsecured payload of an IETF SD-JWT VC that will be used throughout this section: + +<{{examples/credentials/sd_jwt_vc_unsecured.json}} + +The following is a non-normative example of an IETF SD-JWT VC using the unsecured payload above, containing claims that are selectively disclosable. + +<{{examples/credentials/sd_jwt_vc.json}} + +The following are disclosures belonging to the claims from the example above. + +__Claim `given_name`__: + + * SHA-256 Hash: `jsu9yVulwQQlhFlM_3JlzMaSFzglhQG0DpfayQwLUK4` + * Disclosure:\ +`WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImdpdmVuX25hbWUiLCAiSm9o`\ +`biJd` + * Contents: +`["2GLC42sKQveCfGfryNRN9w", "given_name", "John"]` + + +__Claim `family_name`__: + + * SHA-256 Hash: `TGf4oLbgwd5JQaHyKVQZU9UdGE0w5rtDsrZzfUaomLo` + * Disclosure:\ +`WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImZhbWlseV9uYW1lIiwgIkRv`\ +`ZSJd` + * Contents: +`["eluV5Og3gSNII8EYnsxA_A", "family_name", "Doe"]` + + +__Claim `birthdate`__: + + * SHA-256 Hash: `tiTngp9_jhC389UP8_k67MXqoSfiHq3iK6o9un4we_Y` + * Disclosure:\ +`WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImJpcnRoZGF0ZSIsICIxOTQw`\ +`LTAxLTAxIl0` + * Contents: +`["6Ij7tM-a5iVPGboS5tmvVA", "birthdate", "1940-01-01"]` + +### Verifier Metadata + +The `format` value in the `vp_formats` parameter of the Verifier metadata MUST have the key `vc+sd-jwt`, and the value is an object consisting of the following name/value pairs: + +* `sd-jwt_alg_values`: OPTIONAL. A JSON array containing identifiers of cryptographic algorithms the Verifier supports for signing of an Issuer-signed JWT of an SD-JWT. If present, the `alg` JOSE header (as defined in [@!RFC7515]) of the Issuer-signed JWT 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 signing of a Key Binding JWT (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 an IETF SD-JWT VC. + +<{{examples/client_metadata/sd_jwt_vc_verifier_metadata.json}} + +### Presentation Request + +The following is a non-normative example of an Authorization Request: + +<{{examples/request/request.txt}} + +The following is a non-normative example of the contents of a `presentation_definition` parameter that contains the requirements regarding the Credential to be presented: + +<{{examples/request/pd_sd_jwt_vc.json}} + +The presentation of an IETF SD-JWT VC is requested by adding an object named `vc+sd-jwt` to the `format` object of an `input_descriptor`. The `input_descriptor` value is applied to the unsecured payload of the IETF SD-JWT VC which correspond to the disclosures of the presented SD-JWT VC. + +Setting `limit_disclosure` property defined in [@!DIF.PresentationExchange] to `required` enables selective release by instructing the Wallet to submit only the disclosures for the matching claims specified in the fields array. The unsecured payload of an IETF SD-JWT VC is used to perform the matching. + +### Presentation Response + +A non-normative example of the Authorization Response would look the same as in the examples of other Credential formats in this Annex. + +The following is a non-normative example of the content of the `presentation_submission` parameter: + +<{{examples/response/ps_sd_jwt_vc.json}} + +The following is a non-normative example of the `vp_token` parameter provided in the same response and referred to by the `presentation_submission` above: + +<{{examples/response/token_response_vp_token_sd_jwt_vc.txt}} + +In this example the `vp_token` contains only the disclosures for the claims specified in the `presentation_submission`, along with a Key Binding JWT. + +The following is a non-normative example of the unsecured payload of the Key Binding JWT. + +<{{examples/response/kb_jwt_unsecured.json}} + +Note: The Key Binding JWT `nonce` claim contains the value of the `nonce` from the authorization request, and the `aud` claim contains the Client Identifier of the Verifier. + ## Combining this specification with SIOPv2 This section shows how SIOP and OpenID for Verifiable Presentations can be combined to present Verifiable Credentials and pseudonymously authenticate an end-user using subject controlled key material. @@ -1804,6 +1898,7 @@ The technology described in this specification was made available from contribut * added references to ISO/IEC 23220 and 18013 documents * added `post` request method for Request URI + * Added IETF SD-JWT VC profile -20