[Relying Party Solution] Clarification requests Presentation Submission

[Zicchio]

The latest specification slightly modify the shape of a vp token released from a Wallet Instance toward a Relying. For reference, I am talking about thiss block of specs.

eudi-wallet-it-docs/docs/en/remote-flow.rst

Lines 379 to 496 in e58ad09

	Authorization Response Details
	------------------------------
	After getting the User authorization and consent for the presentation of the Credentials, the Wallet Instance sends the Authorization Response to the Relying Party ``response_uri`` endpoint, the content SHOULD be encrypted according `OpenID4VP`_ Section 6.3, using the Relying Party public key.
	.. note::
	**Why the response is encrypted?**
	The response sent from the Wallet Instance to the Relying Party is encrypted to prevent a malicious agent from gaining access to the plaintext information transmitted within the Relying Party's network. This is only possible if the network environment of the Relying Party employs `TLS termination <https://www.f5.com/glossary/ssl-termination>`_. Such technique employs a termination proxy that acts as an intermediary between the client and the webserver and handles all TLS-related operations. In this manner, the proxy deciphers the transmission's content and either forwards it in plaintext or by negotiates an internal TLS session with the actual webserver's intended target. In the first scenario, any malicious actor within the network segment could intercept the transmitted data and obtain sensitive information, such as an unencrypted response, by sniffing the transmitted data.
	Below a non-normative example of the request:
	.. code-block:: http
	POST /response_uri HTTP/1.1
	HOST: relying-party.example.org
	Content-Type: application/x-www-form-urlencoded
	response=eyJhbGciOiJFUzI1NiIs...9t2LQ
	Below is a non-normative example of the decrypted payload of the JWT contained in the ``response``, before base64url encoding:
	.. code-block::
	{
	"state": "3be39b69-6ac1-41aa-921b-3e6c07ddcb03",
	"vp_token": [
	"eyJhbGciOiJFUzI1NiIs...PT0iXX0",
	$WalletAttestation-JWT
	],
	"presentation_submission": {
	"definition_id": "32f54163-7166-48f1-93d8-ff217bdb0653",
	"id": "04a98be3-7fb0-4cf5-af9a-31579c8b0e7d",
	"descriptor_map": [
	{
	"id": "PersonIdentificationData",
	"path": "$.vp_token[0].vp",
	"format": "vc+sd-jwt"
	},
	{
	"id": "WalletAttestation",
	"path": "$.vp_token[1].vp",
	"format": "jwt"
	}
	]
	}
	}
	Where the following parameters are used:
	.. list-table::
	:widths: 25 50
	:header-rows: 1
	* - **Name**
	- **Description**
	* - **vp_token**
	- JSON Array containing the Verifiable Presentation(s). There MUST be at least two signed presentations in this Array:
	- The requested Digital Credential (one or more, in format of SD-JWT VC or MDOC CBOR)
	- The Wallet Attestation
	* - **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 <https://identity.foundation/presentation-exchange/spec/v2.0.0/>`_.
	* - **state**
	- Unique identifier provided by the Relying Party within the Authorization Request.
	The items contained in the ``vp_token`` array are Verifiable Presentations of Credentials.
	Both SD-JWT and mdoc CBOR provide indications for the presentation, according to their specifications.
	SD-JWT Presentation
	-------------------
	SD-JWT defines how an Holder can present a Credential to a Verifier proving the legitimate possession
	of the Credential. For doing this the Holder MUST include the ``KB-JWT`` in the SD-JWT,
	by appending the ``KB-JWT`` at the end of the of the SD-JWT, as represented in the example below:
	.. code-block::
	<Issuer-Signed-JWT>~<Disclosure 1>~<Disclosure 2>~...~<Disclosure N>~<KB-JWT>
	To validate the signature on the Key Binding JWT, the Verifier MUST use the key material included in the Issuer-Signed-JWT.
	The Key Binding JWT MUST specify which key material the Verifier needs to use to validate the Key Binding JWT signature,
	using JOSE header parameter ``kid``.
	When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in the JWS header:
	.. list-table::
	:widths: 25 50
	:header-rows: 1
	* - **Claim**
	- **Description**
	* - **typ**
	- REQUIRED. MUST be ``kb+jwt``, which explicitly types the Key Binding JWT as recommended in Section 3.11 of [RFC8725].
	* - **alg**
	- REQUIRED. Signature Algorithm using one of the specified in the section Cryptographic Algorithms.
	* - **kid**
	- REQUIRED. Unique identifier of the public key to be used to verify the signature.
	When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in the JWS payload:
	.. list-table::
	:widths: 25 50
	:header-rows: 1
	* - **Claim**
	- **Description**
	* - **iat**
	- REQUIRED. The value of this claim MUST be the time at which the Key Binding JWT was issued, using the syntax defined in [RFC7519].
	* - **aud**
	- REQUIRED. The intended receiver of the Key Binding JWT. How the value is represented is up to the protocol used and out of scope of this specification.
	* - **nonce**
	- REQUIRED. Ensures the freshness of the signature. The value type of this claim MUST be a string. How this value is obtained is up to the protocol used and out of scope of this specification.
	* - **sd_hash**
	- REQUIRED. The base64url-encoded hash digest over the Issuer-signed JWT and the selected disclosures as defined below.

Upon initial inspection, there are two details that to me are unclear.

(1) In the key binding JWT used as a proof of possession of the cnf key, it is stated that

eudi-wallet-it-docs/docs/en/remote-flow.rst

Lines 493 to 494 in e58ad09

	* - **nonce**
	- REQUIRED. Ensures the freshness of the signature. The value type of this claim MUST be a string. How this value is obtained is up to the protocol used and out of scope of this specification.

Am I correct in assuming that this nonce is the same nonce presented in the Request Object defined here?

eudi-wallet-it-docs/docs/en/remote-flow.rst

Lines 304 to 305 in e58ad09

	* - **nonce**
	- Fresh cryptographically random number with sufficient entropy, which length MUST be at least 32 digits.

If so, why is it stated that "[...] How this value is obtained is up to the protocol used and out of scope of this specification."?

(2) The non normative example of the presentation submission contains paths

eudi-wallet-it-docs/docs/en/remote-flow.rst

Line 416 in e58ad09

"path": "$.vp_token[0].vp",

and

eudi-wallet-it-docs/docs/en/remote-flow.rst

Line 421 in e58ad09

"path": "$.vp_token[1].vp",

what is .vp in the path referencing here? Is it simply a placeholder?

[peppelinux]

according to #251

vp_tokens is an array which entry are not anymore vp jwt

@m-basili is going to align all the presentation definition examples contained in the specs in milestone 0.8.0

[peppelinux]

@Zicchio it seems that the isexample about prensetation_definition is fixed in v 0.8.0, see:

https://github.com/italia/eudi-wallet-it-docs/blob/versione-corrente/examples/presentation-definition.json

while the way the nonce is described is taken directly from the SD-JWT specs, here:

https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/