request_uri, state, request_uri_method and client_id_scheme;
If the client_id_scheme is provided and set with the value entity_id, the Wallet Instance MUST collect and validate the OpenID Federation Trust Chain related to the Relying Party. If the client_id_scheme is either not provided or is assigned a value different from entity_id, the Wallet Instance MUST establish the trust by utilizing the client_id or an alternative client_id_scheme value. This alternative value MUST enable the Wallet Instance to establish trust with the Relying Party, ensuring compliance with the assurance levels mandated by the trust framework;
If request_uri_method is provided and set with the value post, the Wallet Instance SHOULD transmit its metadata to the Relying Party's request_uri endpoint using the HTTP POST method and obtain the signed Request Object. If request_uri_method is set with the value get or not present, the Wallet Instance MUST fetch the signed Request Object using an HTTP request with method GET to the endpoint provided in the request_uri parameter;
the Wallet Instance verifies the signature of the signed Request Object, using the public key obtained with the trust chain, and that its issuer matches the client_id obtained at the step number 2;
the Wallet Instance verifies the signature of the signed Request Object, using the public key identifier within the Request Object JWT header parameter to select the correct public key obtained within Trust Chain related to the RP;
the Wallet Instance verifies that the client_id contained in the Request Object issuer (RP) matches with the one obtained at the step number 2 and with the sub parameter contained in the RP's Entity Configuration within the Trust Chain;
the Wallet Instance evaluates the requested Digital Credentials and checks the elegibility of the Relying Party in asking these by applying the policies related to that specific Relying Party, obtained with the trust chain;
the Wallet Instance asks User disclosure and consent;
the Wallet Instance presents the requested information to the Relying Party along with the Wallet Attestation. The Relying Party validates the presented Credentials checking the trust with their Issuers, and validates the Wallet Attestation by also checking that the Wallet Provider is trusted;
Remote Flow
-
+
Fig. 5 Remote Protocol Flow¶
@@ -225,7 +226,7 @@ Remote Flow14
The Wallet Instance obtains the signed Request Object.
The RP issues the Request Object signin it using one of its cryptographic private keys, where their public parts have been published within its Entity Configuration (metadata.wallet_relying_party.jwks). The Wallet Instance obtains the signed Request Object.
15, 16, 17
The Request Object JWS is verified by the Wallet Instance. The Wallet Instance processes the Relying Party metadata and applies the policies related to the Relying Party, attesting whose Digital Credentials and User data the Relying Party is granted to request.
Remote Flow21, 22, 23, 24, 25
The Relying Party verifies the Authorization Response, extracts the Wallet Attestation to establish the trust with the Wallet Solution. The Relying Party extracts the Digital Credentials and attests the trust to the Credentials Issuer and the proof of possession of the Wallet Instance about the presented Digital Credentials. Finally, the Relying Party verifies the revocation status of the presented Digital Credentials.
26
26 (Same Device Flow only)
The Relying Party provides to the Wallet Instance a redirect URI with a response code to be used by the Wallet Instance to finalize the authentication.
27, 28 and 29
Request Object Details
Request URI Response¶
-The Relying Party issues the signed Request Object, where a non-normative example in the form of decoded header and payload is shown below:
+The Relying Party issues the signed Request Object using the content type set to application/oauth-authz-req+jwt,
+where a non-normative example in the form of decoded header and payload is shown below:
{
"alg": "ES256",
"typ": "JWT",
@@ -642,8 +644,7 @@ Request URI Response
presentation_definition: JSON object according to Presentation Exchange. This parameter MUST not be present when presentation_definition_uri or scope are present.
presentation_definition_uri: Not supported. String containing an HTTPS URL pointing to a resource where a Presentation Definition JSON object can be retrieved. This parameter MUST be present when presentation_definition parameter or a scope value representing a Presentation Definition is not present.
client_metadata: A JSON object containing the Relying Party metadata values. The client_metadata parameter MUST NOT be present when client_id_scheme is entity_id. Since the client_metadata is taken from trust_chain, this parameter is intended to not be used.
client_metadata_uri: string containing an HTTPS URL pointing to a resource where a JSON object with the Relying Party metadata can be retrieved. The client_metadata_uri parameter MUST NOT be present when client_id_scheme is entity_id. Since the client_metadata is taken from trust_chain, this parameter is intended to not be used.
client_metadata: A JSON object containing the Relying Party metadata values. If the client_metadata parameter is present when client_id_scheme is entity_id, the Wallet Instance MUST consider the client metadata obtained through the OpenID Federation Trust Chain.
@@ -717,7 +718,7 @@ Authorization Response Detailspresentation_submission
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange.
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange. This is expressed via elements in the descriptor_map array (Input Descriptor Mapping Objects) that contain a field called path, which MUST have the value $ (top level root path) when only one Verifiable Presentation is contained in the VP Token, and MUST have the value $[n] (indexed path from root) when there are multiple Verifiable Presentations, where n is the index to select. The Relying Party receiving the presentation_submission descriptor therefore is able to use the correct method to decode each credential data format provided within the vp_token.
state
Unique identifier provided by the Relying Party within the Authorization Request.
Remote Flowclient_id, request_uri, state, request_uri_method and client_id_scheme;
If the client_id_scheme is provided and set with the value entity_id, the Wallet Instance MUST collect and validate the OpenID Federation Trust Chain related to the Relying Party. If the client_id_scheme is either not provided or is assigned a value different from entity_id, the Wallet Instance MUST establish the trust by utilizing the client_id or an alternative client_id_scheme value. This alternative value MUST enable the Wallet Instance to establish trust with the Relying Party, ensuring compliance with the assurance levels mandated by the trust framework;
If request_uri_method is provided and set with the value post, the Wallet Instance SHOULD transmit its metadata to the Relying Party's request_uri endpoint using the HTTP POST method and obtain the signed Request Object. If request_uri_method is set with the value get or not present, the Wallet Instance MUST fetch the signed Request Object using an HTTP request with method GET to the endpoint provided in the request_uri parameter;
the Wallet Instance verifies the signature of the signed Request Object, using the public key obtained with the trust chain, and that its issuer matches the client_id obtained at the step number 2;
the Wallet Instance verifies the signature of the signed Request Object, using the public key identifier within the Request Object JWT header parameter to select the correct public key obtained within Trust Chain related to the RP;
the Wallet Instance verifies that the client_id contained in the Request Object issuer (RP) matches with the one obtained at the step number 2 and with the sub parameter contained in the RP's Entity Configuration within the Trust Chain;
the Wallet Instance evaluates the requested Digital Credentials and checks the elegibility of the Relying Party in asking these by applying the policies related to that specific Relying Party, obtained with the trust chain;
the Wallet Instance asks User disclosure and consent;
the Wallet Instance presents the requested information to the Relying Party along with the Wallet Attestation. The Relying Party validates the presented Credentials checking the trust with their Issuers, and validates the Wallet Attestation by also checking that the Wallet Provider is trusted;
Remote Flow
-
+
Remote Protocol Flow¶
@@ -215,7 +216,7 @@ Remote Flow14
The Wallet Instance obtains the signed Request Object.
The RP issues the Request Object signin it using one of its cryptographic private keys, where their public parts have been published within its Entity Configuration (metadata.wallet_relying_party.jwks). The Wallet Instance obtains the signed Request Object.
15, 16, 17
The Request Object JWS is verified by the Wallet Instance. The Wallet Instance processes the Relying Party metadata and applies the policies related to the Relying Party, attesting whose Digital Credentials and User data the Relying Party is granted to request.
Remote Flow21, 22, 23, 24, 25
The Relying Party verifies the Authorization Response, extracts the Wallet Attestation to establish the trust with the Wallet Solution. The Relying Party extracts the Digital Credentials and attests the trust to the Credentials Issuer and the proof of possession of the Wallet Instance about the presented Digital Credentials. Finally, the Relying Party verifies the revocation status of the presented Digital Credentials.
26
26 (Same Device Flow only)
The Relying Party provides to the Wallet Instance a redirect URI with a response code to be used by the Wallet Instance to finalize the authentication.
27, 28 and 29
Request Object Details
Request URI Response¶
-The Relying Party issues the signed Request Object, where a non-normative example in the form of decoded header and payload is shown below:
+The Relying Party issues the signed Request Object using the content type set to application/oauth-authz-req+jwt,
+where a non-normative example in the form of decoded header and payload is shown below:
{
"alg": "ES256",
"typ": "JWT",
@@ -632,8 +634,7 @@ Request URI Response
presentation_definition: JSON object according to Presentation Exchange. This parameter MUST not be present when presentation_definition_uri or scope are present.
presentation_definition_uri: Not supported. String containing an HTTPS URL pointing to a resource where a Presentation Definition JSON object can be retrieved. This parameter MUST be present when presentation_definition parameter or a scope value representing a Presentation Definition is not present.
client_metadata: A JSON object containing the Relying Party metadata values. The client_metadata parameter MUST NOT be present when client_id_scheme is entity_id. Since the client_metadata is taken from trust_chain, this parameter is intended to not be used.
client_metadata_uri: string containing an HTTPS URL pointing to a resource where a JSON object with the Relying Party metadata can be retrieved. The client_metadata_uri parameter MUST NOT be present when client_id_scheme is entity_id. Since the client_metadata is taken from trust_chain, this parameter is intended to not be used.
client_metadata: A JSON object containing the Relying Party metadata values. If the client_metadata parameter is present when client_id_scheme is entity_id, the Wallet Instance MUST consider the client metadata obtained through the OpenID Federation Trust Chain.
@@ -707,7 +708,7 @@ Authorization Response Detailspresentation_submission
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange.
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange. This is expressed via elements in the descriptor_map array (Input Descriptor Mapping Objects) that contain a field called path, which MUST have the value $ (top level root path) when only one Verifiable Presentation is contained in the VP Token, and MUST have the value $[n] (indexed path from root) when there are multiple Verifiable Presentations, where n is the index to select. The Relying Party receiving the presentation_submission descriptor therefore is able to use the correct method to decode each credential data format provided within the vp_token.
state
Unique identifier provided by the Relying Party within the Authorization Request.
Fig. 5 Remote Protocol Flow¶
14
The Wallet Instance obtains the signed Request Object.
The RP issues the Request Object signin it using one of its cryptographic private keys, where their public parts have been published within its Entity Configuration (metadata.wallet_relying_party.jwks). The Wallet Instance obtains the signed Request Object.
15, 16, 17
The Request Object JWS is verified by the Wallet Instance. The Wallet Instance processes the Relying Party metadata and applies the policies related to the Relying Party, attesting whose Digital Credentials and User data the Relying Party is granted to request.
Remote Flow21, 22, 23, 24, 25
The Relying Party verifies the Authorization Response, extracts the Wallet Attestation to establish the trust with the Wallet Solution. The Relying Party extracts the Digital Credentials and attests the trust to the Credentials Issuer and the proof of possession of the Wallet Instance about the presented Digital Credentials. Finally, the Relying Party verifies the revocation status of the presented Digital Credentials.
21, 22, 23, 24, 25
The Relying Party verifies the Authorization Response, extracts the Wallet Attestation to establish the trust with the Wallet Solution. The Relying Party extracts the Digital Credentials and attests the trust to the Credentials Issuer and the proof of possession of the Wallet Instance about the presented Digital Credentials. Finally, the Relying Party verifies the revocation status of the presented Digital Credentials.
26
26 (Same Device Flow only)
The Relying Party provides to the Wallet Instance a redirect URI with a response code to be used by the Wallet Instance to finalize the authentication.
27, 28 and 29
Request Object Details
Request URI Response¶
-The Relying Party issues the signed Request Object, where a non-normative example in the form of decoded header and payload is shown below:
+The Relying Party issues the signed Request Object using the content type set to application/oauth-authz-req+jwt,
+where a non-normative example in the form of decoded header and payload is shown below:
{
"alg": "ES256",
"typ": "JWT",
@@ -642,8 +644,7 @@ Request URI Response
presentation_definition: JSON object according to Presentation Exchange. This parameter MUST not be present when presentation_definition_uri or scope are present.
presentation_definition_uri: Not supported. String containing an HTTPS URL pointing to a resource where a Presentation Definition JSON object can be retrieved. This parameter MUST be present when presentation_definition parameter or a scope value representing a Presentation Definition is not present.
client_metadata: A JSON object containing the Relying Party metadata values. The client_metadata parameter MUST NOT be present when client_id_scheme is entity_id. Since the client_metadata is taken from trust_chain, this parameter is intended to not be used.
client_metadata_uri: string containing an HTTPS URL pointing to a resource where a JSON object with the Relying Party metadata can be retrieved. The client_metadata_uri parameter MUST NOT be present when client_id_scheme is entity_id. Since the client_metadata is taken from trust_chain, this parameter is intended to not be used.
client_metadata: A JSON object containing the Relying Party metadata values. If the client_metadata parameter is present when client_id_scheme is entity_id, the Wallet Instance MUST consider the client metadata obtained through the OpenID Federation Trust Chain.
@@ -717,7 +718,7 @@ Authorization Response Detailspresentation_submission
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange.
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange. This is expressed via elements in the descriptor_map array (Input Descriptor Mapping Objects) that contain a field called path, which MUST have the value $ (top level root path) when only one Verifiable Presentation is contained in the VP Token, and MUST have the value $[n] (indexed path from root) when there are multiple Verifiable Presentations, where n is the index to select. The Relying Party receiving the presentation_submission descriptor therefore is able to use the correct method to decode each credential data format provided within the vp_token.
Request URI Response¶
-The Relying Party issues the signed Request Object, where a non-normative example in the form of decoded header and payload is shown below:
+The Relying Party issues the signed Request Object using the content type set to application/oauth-authz-req+jwt,
+where a non-normative example in the form of decoded header and payload is shown below:
{
"alg": "ES256",
"typ": "JWT",
@@ -642,8 +644,7 @@ Request URI Response
presentation_definition: JSON object according to Presentation Exchange. This parameter MUST not be present when presentation_definition_uri or scope are present.
presentation_definition_uri: Not supported. String containing an HTTPS URL pointing to a resource where a Presentation Definition JSON object can be retrieved. This parameter MUST be present when presentation_definition parameter or a scope value representing a Presentation Definition is not present.
client_metadata: A JSON object containing the Relying Party metadata values. The client_metadata parameter MUST NOT be present when client_id_scheme is entity_id. Since the client_metadata is taken from trust_chain, this parameter is intended to not be used.
client_metadata_uri: string containing an HTTPS URL pointing to a resource where a JSON object with the Relying Party metadata can be retrieved. The client_metadata_uri parameter MUST NOT be present when client_id_scheme is entity_id. Since the client_metadata is taken from trust_chain, this parameter is intended to not be used.
client_metadata: A JSON object containing the Relying Party metadata values. If the client_metadata parameter is present when client_id_scheme is entity_id, the Wallet Instance MUST consider the client metadata obtained through the OpenID Federation Trust Chain.
Authorization Response Detailspresentation_submission
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange.
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange. This is expressed via elements in the descriptor_map array (Input Descriptor Mapping Objects) that contain a field called path, which MUST have the value $ (top level root path) when only one Verifiable Presentation is contained in the VP Token, and MUST have the value $[n] (indexed path from root) when there are multiple Verifiable Presentations, where n is the index to select. The Relying Party receiving the presentation_submission descriptor therefore is able to use the correct method to decode each credential data format provided within the vp_token.
presentation_submission
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange.
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange. This is expressed via elements in the descriptor_map array (Input Descriptor Mapping Objects) that contain a field called path, which MUST have the value $ (top level root path) when only one Verifiable Presentation is contained in the VP Token, and MUST have the value $[n] (indexed path from root) when there are multiple Verifiable Presentations, where n is the index to select. The Relying Party receiving the presentation_submission descriptor therefore is able to use the correct method to decode each credential data format provided within the vp_token.
state
Unique identifier provided by the Relying Party within the Authorization Request.
Remote Flowclient_id, request_uri, state, request_uri_method and client_id_scheme;
If the client_id_scheme is provided and set with the value entity_id, the Wallet Instance MUST collect and validate the OpenID Federation Trust Chain related to the Relying Party. If the client_id_scheme is either not provided or is assigned a value different from entity_id, the Wallet Instance MUST establish the trust by utilizing the client_id or an alternative client_id_scheme value. This alternative value MUST enable the Wallet Instance to establish trust with the Relying Party, ensuring compliance with the assurance levels mandated by the trust framework;
If request_uri_method is provided and set with the value post, the Wallet Instance SHOULD transmit its metadata to the Relying Party's request_uri endpoint using the HTTP POST method and obtain the signed Request Object. If request_uri_method is set with the value get or not present, the Wallet Instance MUST fetch the signed Request Object using an HTTP request with method GET to the endpoint provided in the request_uri parameter;
the Wallet Instance verifies the signature of the signed Request Object, using the public key obtained with the trust chain, and that its issuer matches the client_id obtained at the step number 2;
the Wallet Instance verifies the signature of the signed Request Object, using the public key identifier within the Request Object JWT header parameter to select the correct public key obtained within Trust Chain related to the RP;
the Wallet Instance verifies that the client_id contained in the Request Object issuer (RP) matches with the one obtained at the step number 2 and with the sub parameter contained in the RP's Entity Configuration within the Trust Chain;
the Wallet Instance evaluates the requested Digital Credentials and checks the elegibility of the Relying Party in asking these by applying the policies related to that specific Relying Party, obtained with the trust chain;
the Wallet Instance asks User disclosure and consent;
the Wallet Instance presents the requested information to the Relying Party along with the Wallet Attestation. The Relying Party validates the presented Credentials checking the trust with their Issuers, and validates the Wallet Attestation by also checking that the Wallet Provider is trusted;
Remote Flow
-
+
Remote Protocol Flow¶
@@ -215,7 +216,7 @@ Remote Flow14
The Wallet Instance obtains the signed Request Object.
The RP issues the Request Object signin it using one of its cryptographic private keys, where their public parts have been published within its Entity Configuration (metadata.wallet_relying_party.jwks). The Wallet Instance obtains the signed Request Object.
If the client_id_scheme is provided and set with the value entity_id, the Wallet Instance MUST collect and validate the OpenID Federation Trust Chain related to the Relying Party. If the client_id_scheme is either not provided or is assigned a value different from entity_id, the Wallet Instance MUST establish the trust by utilizing the client_id or an alternative client_id_scheme value. This alternative value MUST enable the Wallet Instance to establish trust with the Relying Party, ensuring compliance with the assurance levels mandated by the trust framework;
If request_uri_method is provided and set with the value post, the Wallet Instance SHOULD transmit its metadata to the Relying Party's request_uri endpoint using the HTTP POST method and obtain the signed Request Object. If request_uri_method is set with the value get or not present, the Wallet Instance MUST fetch the signed Request Object using an HTTP request with method GET to the endpoint provided in the request_uri parameter;
the Wallet Instance verifies the signature of the signed Request Object, using the public key obtained with the trust chain, and that its issuer matches the client_id obtained at the step number 2;
the Wallet Instance verifies the signature of the signed Request Object, using the public key identifier within the Request Object JWT header parameter to select the correct public key obtained within Trust Chain related to the RP;
the Wallet Instance verifies that the client_id contained in the Request Object issuer (RP) matches with the one obtained at the step number 2 and with the sub parameter contained in the RP's Entity Configuration within the Trust Chain;
the Wallet Instance evaluates the requested Digital Credentials and checks the elegibility of the Relying Party in asking these by applying the policies related to that specific Relying Party, obtained with the trust chain;
the Wallet Instance asks User disclosure and consent;
the Wallet Instance presents the requested information to the Relying Party along with the Wallet Attestation. The Relying Party validates the presented Credentials checking the trust with their Issuers, and validates the Wallet Attestation by also checking that the Wallet Provider is trusted;
+
Remote Protocol Flow¶
Remote Flow14
The Wallet Instance obtains the signed Request Object.
The RP issues the Request Object signin it using one of its cryptographic private keys, where their public parts have been published within its Entity Configuration (metadata.wallet_relying_party.jwks). The Wallet Instance obtains the signed Request Object.
14
The Wallet Instance obtains the signed Request Object.
The RP issues the Request Object signin it using one of its cryptographic private keys, where their public parts have been published within its Entity Configuration (metadata.wallet_relying_party.jwks). The Wallet Instance obtains the signed Request Object.
15, 16, 17
The Request Object JWS is verified by the Wallet Instance. The Wallet Instance processes the Relying Party metadata and applies the policies related to the Relying Party, attesting whose Digital Credentials and User data the Relying Party is granted to request.
Remote Flow21, 22, 23, 24, 25
The Relying Party verifies the Authorization Response, extracts the Wallet Attestation to establish the trust with the Wallet Solution. The Relying Party extracts the Digital Credentials and attests the trust to the Credentials Issuer and the proof of possession of the Wallet Instance about the presented Digital Credentials. Finally, the Relying Party verifies the revocation status of the presented Digital Credentials.
21, 22, 23, 24, 25
The Relying Party verifies the Authorization Response, extracts the Wallet Attestation to establish the trust with the Wallet Solution. The Relying Party extracts the Digital Credentials and attests the trust to the Credentials Issuer and the proof of possession of the Wallet Instance about the presented Digital Credentials. Finally, the Relying Party verifies the revocation status of the presented Digital Credentials.
26
26 (Same Device Flow only)
The Relying Party provides to the Wallet Instance a redirect URI with a response code to be used by the Wallet Instance to finalize the authentication.
27, 28 and 29
Request Object Details
Request URI Response¶
-The Relying Party issues the signed Request Object, where a non-normative example in the form of decoded header and payload is shown below:
+The Relying Party issues the signed Request Object using the content type set to application/oauth-authz-req+jwt,
+where a non-normative example in the form of decoded header and payload is shown below:
{
"alg": "ES256",
"typ": "JWT",
@@ -632,8 +634,7 @@ Request URI Response
presentation_definition: JSON object according to Presentation Exchange. This parameter MUST not be present when presentation_definition_uri or scope are present.
presentation_definition_uri: Not supported. String containing an HTTPS URL pointing to a resource where a Presentation Definition JSON object can be retrieved. This parameter MUST be present when presentation_definition parameter or a scope value representing a Presentation Definition is not present.
client_metadata: A JSON object containing the Relying Party metadata values. The client_metadata parameter MUST NOT be present when client_id_scheme is entity_id. Since the client_metadata is taken from trust_chain, this parameter is intended to not be used.
client_metadata_uri: string containing an HTTPS URL pointing to a resource where a JSON object with the Relying Party metadata can be retrieved. The client_metadata_uri parameter MUST NOT be present when client_id_scheme is entity_id. Since the client_metadata is taken from trust_chain, this parameter is intended to not be used.
client_metadata: A JSON object containing the Relying Party metadata values. If the client_metadata parameter is present when client_id_scheme is entity_id, the Wallet Instance MUST consider the client metadata obtained through the OpenID Federation Trust Chain.
@@ -707,7 +708,7 @@ Authorization Response Detailspresentation_submission
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange.
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange. This is expressed via elements in the descriptor_map array (Input Descriptor Mapping Objects) that contain a field called path, which MUST have the value $ (top level root path) when only one Verifiable Presentation is contained in the VP Token, and MUST have the value $[n] (indexed path from root) when there are multiple Verifiable Presentations, where n is the index to select. The Relying Party receiving the presentation_submission descriptor therefore is able to use the correct method to decode each credential data format provided within the vp_token.
Request URI Response¶
-The Relying Party issues the signed Request Object, where a non-normative example in the form of decoded header and payload is shown below:
+The Relying Party issues the signed Request Object using the content type set to application/oauth-authz-req+jwt,
+where a non-normative example in the form of decoded header and payload is shown below:
{
"alg": "ES256",
"typ": "JWT",
@@ -632,8 +634,7 @@ Request URI Response
presentation_definition: JSON object according to Presentation Exchange. This parameter MUST not be present when presentation_definition_uri or scope are present.
presentation_definition_uri: Not supported. String containing an HTTPS URL pointing to a resource where a Presentation Definition JSON object can be retrieved. This parameter MUST be present when presentation_definition parameter or a scope value representing a Presentation Definition is not present.
client_metadata: A JSON object containing the Relying Party metadata values. The client_metadata parameter MUST NOT be present when client_id_scheme is entity_id. Since the client_metadata is taken from trust_chain, this parameter is intended to not be used.
client_metadata_uri: string containing an HTTPS URL pointing to a resource where a JSON object with the Relying Party metadata can be retrieved. The client_metadata_uri parameter MUST NOT be present when client_id_scheme is entity_id. Since the client_metadata is taken from trust_chain, this parameter is intended to not be used.
client_metadata: A JSON object containing the Relying Party metadata values. If the client_metadata parameter is present when client_id_scheme is entity_id, the Wallet Instance MUST consider the client metadata obtained through the OpenID Federation Trust Chain.
Authorization Response Detailspresentation_submission
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange.
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange. This is expressed via elements in the descriptor_map array (Input Descriptor Mapping Objects) that contain a field called path, which MUST have the value $ (top level root path) when only one Verifiable Presentation is contained in the VP Token, and MUST have the value $[n] (indexed path from root) when there are multiple Verifiable Presentations, where n is the index to select. The Relying Party receiving the presentation_submission descriptor therefore is able to use the correct method to decode each credential data format provided within the vp_token.
presentation_submission
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange.
JSON Object containing the mappings between the requested Verifiable Credentials and where to find them within the returned Verifiable Presentation Token, according to the Presentation Exchange. This is expressed via elements in the descriptor_map array (Input Descriptor Mapping Objects) that contain a field called path, which MUST have the value $ (top level root path) when only one Verifiable Presentation is contained in the VP Token, and MUST have the value $[n] (indexed path from root) when there are multiple Verifiable Presentations, where n is the index to select. The Relying Party receiving the presentation_submission descriptor therefore is able to use the correct method to decode each credential data format provided within the vp_token.
state
Unique identifier provided by the Relying Party within the Authorization Request.