Closed peppelinux closed 10 months ago
We already added all the information regarding the generation of the request_uri
value in Step 7 of the Issuance flow as the following:
Step 7 (PAR Response): The PID/(Q)EAA Provider MUST issue the request_uri one-time use and bind it to the client identifier (client_id) that is provided in the Request Object. Furthermore, the entropy of the request_uri MUST be sufficiently large. The adequate shortness of the validity and the entropy of the request_uri depends on the risk calculation based on the value of the resource being protected. The validity time SHOULD be less than a minute, and the request_uri MUST include a cryptographic random value of 128 bits or more (RFC 9101). The entire request_uri SHOULD NOT exceed 512 ASCII characters due to the following two main reasons (RFC 9101):
Many phones on the market still do not accept large payloads. The restriction is typically either 512 or 1024 ASCII characters.
On a slow connection such as a 2G mobile connection, a large URL would cause a slow response; therefore, the use of such is not advisable from the user-experience point of view.
Right, but I was referring to the Relying Party solution document. The description on how to create the request_uri should perhaps be placed in one central document and the referred to from documents where request_uri is used.
Right, but I was referring to the Relying Party solution document. The description on how to create the request_uri should perhaps be placed in one central document and the referred to from documents where request_uri is used.
Ah, my bad. We are going to integrate all the checks that need to be performed by the involved entities in the RP solution as well and probably for the ones, that are in common probably, we may have a central document for it as you suggested.
@rohe 's:
In https://github.com/italia/eudi-wallet-it-docs/blob/versione-corrente/docs/en/relying-party-solution.rst
It says about Authorization Request Details: "The value corresponding to the request_uri endpoint MUST be randomized, according to RFC 9101"
What 9101 says is: "the request_uri MUST have appropriate entropy for its lifetime so that the URI is not guessable if publicly retrievable".
in OIDC core a randomized fragment is used for this.