Attestable and randomized redirect_uri and response_uri

[peppelinux]

For increasing the security of the implementations, it is recommended that the RPs randomize their endpoints.

This can be achieved appending random paths, as for example: https:/rp.example.org/request-uri/that-random-things

however, there are cases where the RP endpoints are attested by a trusted third party, like a National Accreditation Body, who certifies the RP's metadata and provide these:

• by publishing them in a public and verifiable registry
• providing to the RP a verifiable attestation
• using metadata and the metadata_policy language defined in OpenID Federation

In the cases above, the RP cannot changes its URIs unless it does use the fragments, according to OIDC Core 1.0 specs.

Do we agree that we should mention the recommendation of randomizing those URIs in the definition of the params or in the security considerations?

[peppelinux]

I would add a sentence like this, for all the RP's endpoints (request, redirect, response)

It is RECOMMENDED that the HTTPS URL, where the Relying Party provides the endpoints, includes a random URI fragment value. For instance: https://relying-party.example.org/request_uri#that-random-fragment-we-mentioned. The random fragment value should ideally exceed 12 characters in length.

Randomizing URIs with fragments can provide several benefits:

1. Security: By adding a random fragment to the URI, potential security risks can be prevented. See RFC

2. Cache Busting: Web servers and browsers often cache resources like files or pages to improve performance. However, if a resource changes on the server, the client might still load the outdated resource from the cache. By adding a unique, random fragment to each URI, you ensure that each request is unique and not loaded from the cache.

3. Tracking and Analytics: Random fragments can also be useful for tracking individual requests or user sessions in analytics. By analyzing the unique fragments, you can gain insights into user behavior or performance issues.

[jogu]

As per https://www.rfc-editor.org/rfc/rfc6749#section-3.1.2 :

The [redirection] endpoint URI MUST NOT include a fragment component.

I don't think we should recommend people violate RFC6749, so we should not say this for the redirect url.

The RP request & response endpoints not called via a redirect but via a HTTP, so I don't see how a fragment will help as it will not be passed to the server?

[peppelinux]

ok to not violate anyelse RFC!

the goal is to protect the RP's endpoints with a random and unpredictable value and at the same time have it (withour fragment) in its metadata.

I didn't get this

I don't see how a fragment will help as it will not be passed to the server?

The RP is a server with its public endpoints, in the flow where the wallet interacts with the RP

[jogu]

The RP is a server with its public endpoints, in the flow where the wallet interacts with the RP

The wallet will make this http call to the verifier/RP:

GET /something HTTP/1.1

The http spec explicitly defines the /something to only be the path and the query. (Or put another way, the only time the RP can access the fragment is when it's received in a redirect, as per response_mode=fragment, where JS in the frontend is needed which extracts the fragment from document.location and sends it to the backend.)

[peppelinux]

Ok, just to put a stone on this.

How we can achieve the feature to have uri in RP's metadata and randomization in the http requests? Since we cannot use fragments, may we use urlparams?

[jogu]

I can't really see how you'd do it for redirect uri, for security reasons an exact match is required and there have been all sorts of attacks against servers that implement partial matching (there was a presentation at OSW this year).

[danielfett]

Yes, partial matching is dangerous. A precise matching should be applied.

Besides this, what exactly are the attacks randomization protects against?

[peppelinux]

@danielfett in tha italian profile we was inspired by this https://datatracker.ietf.org/doc/html/rfc9101.html#section-10.2

[peppelinux]

@jogu

Even if not supported by Oauth 2.0 specification, OIDC Core 1.0 defines the use of fragments in the redirect_uri endpoint https://openid.net/specs/openid-connect-core-1_0.html#ImplicitCallback

this is an open point just for the redirect_uri, while request_uri and response_uri are something different where we can use the fragments for randomizing the endpoints wihtout preventing their registration in the RP metadata

[danielfett]

@peppelinux But that's talking about Request URIs, not Redirect URIs. That's not what I would consider an RP endpoint.

[peppelinux]

Ok, let's keep out redirect_uri and continue working on request_uri and response_uri with fragments

[danielfett]

Even if not supported by Oauth 2.0 specification, OIDC Core 1.0 defines the use of fragments in the redirect_uri endpoint https://openid.net/specs/openid-connect-core-1_0.html#ImplicitCallback

The server attaches a fragment to transfer the data to an application running in the browser. But the registered redirect URI (or the one in the redirect_uri parameter) cannot have a fragment.

this is an open point just for the redirect_uri, while request_uri and response_uri are something different where we can use the fragments for randomizing the endpoints wihtout preventing their registration in the RP metadata

Who would check the randomization? And are request_uris really registered in your case? They should be random anyway (without a fragment).

[peppelinux]

Ok, then we're saying that should not register request-uri and response-uri in RP metadata because they must be random and without fragment

while in this issue I was suggesting to allow the registrations of request-uri and response-uri in RP metadata and using fragments for randomizing them

the benefit is that the wallet solution always relies on the endpoints defined/attested in the RP's metadata using the fragment as well since the fragment doesn't introduce any change on the baseurl used

[jogu]

Ok, then we're saying that should not register request-uri and response-uri in RP metadata because they must be random and without fragment

I think at this stage we're probably saying:

1. There's no easy way to do this, and
2. It's not clear there's a good security reason to do this

We should probably focus on answering '2' before talking about possible ways forward.

[peppelinux]

2. It's not clear there's a good security reason to do this

protection of the endpoint through randomization of the urls

[jogu]

Protecting the endpoint against what?

[peppelinux]

thousands of presentations with thousands of vp in the vp_token array, where the nonce is included in each of vp jws and the RP have to decode each of them (in sequence or in parallel) before deciding what to do or,

differently,

a vulnerability that affects an encryption library that could be easily exploited at the response-uri endpoint, using a well-crafted presentation

with a random uri would be difficult to have a successful exploitation, or better, neither a try.

[jogu]

I think you could achieve roughly the same outcomes by using state? i.e. pass a random state value in the original request, and at the response_uri check the incoming state value as pretty much the first step.

[peppelinux]

I can buy it, thanks.

If there are no further comments I assume we can close the matter in the next week.

[peppelinux]

@jogu even if the state doesn't help for randomizing the request-uri endpoint, do you have any hint/consideration to share about this?

[jogu]

I'm not sure what to do about request uri.

I think it breaks down into two cases:

1. The request_uri body contents is stable and is the same for all requests => no need to add any random element
2. The request_uri body contents changes each time => it must surely already have something unique in the path/query

[peppelinux]

Regarding the request_uri endpoint I was wondering that an RP may issue signed artifacts and a DDOS on it would produce resource exhauntion

while if the url is randomized the attack would be eluded. The request-uri endpoint would be attested by a TTP in a signed metadata or trust chain, the fragment/urlparam/anything-else, would be created by RP to randomize the resource

[peppelinux]

This issue was created with the assumption to have redirect_uris and response_uris in a metadata attested by a trusted third party, such the one represented by a trust anchor in a trust chain or by a central metadata registry or metadata resolution endpoint

the problem it aims to resolve is the prevention of hijack using a secure metadata distribution according to a trust framework

this expected feature seems to be out of scope for openid4vp that only aims to define the client metadata expected in the request parameter and nothing else