Unclear whether wallet should follow HTTP redirects

[mickrau]

Feedback from Interop. @jogu

There is uncertainty among developers as to whether wallets should follow HTTP redirects (301, 302, 307), and when yes in which cases.
Same for VCI.

Most HTTP clients follow redirects by default. Current OpenID Conformance Test does not follow redirects.

example
a verifier implementation redirects a call to the request-uri

HTTP GET https://verifier.example.com/request-uri?static
<- HTTP 307 Temporary Redirect https://verifier.example.com/request-uri?id=234234
HTTP GET https://verifier.example.com/request-uri?id=234234
<- HTTP 200 OK <Authorization Request>

Should this be allowed?

In my opinion HTTP redirects are a standard HTTP pattern that should be allowed by default and explicitly disallowed when necessary.

[jogu]

The conformance suite doesn't follow redirects for request Uris, or any other cases other than in the authorization endpoint.

[mickrau]

Okay, but on what basis did you make that decision?
I would like a statement in the OID4V* specs that makes this clear.

What is the reason for disallowing redirects? If there is a security risk, conformance test should clarify that a wallet does not follow redirects.

[c2bo]

In general there is the security risk with redirects of having redirect loops - clients should at least be able to detect and prevent such infinite redirect loops if redirects are followed. There is guidance on redirects in https://www.rfc-editor.org/rfc/rfc9110#name-redirection-3xx that we might want to point to in our security considerations.

Are there use-cases where people think they would benefit from redirects in other places than authorization endpoint?

[jogu]

Okay, but on what basis did you make that decision? I would like a statement in the OID4V* specs that makes this clear.

What is the reason for disallowing redirects? If there is a security risk, conformance test should clarify that a wallet does not follow redirects.

There is no normative text I'm aware of that requires redirects to be followed. Hence, we don't follow redirects. If we made the decision to follow redirects, we'd have to update the tests for the component on the other side to generate redirects in all the cases were they are permitted - i.e. for this case the VCI tests for wallets would have to generate redirects for the request_uri response to check that the wallet correctly handles redirects. We could only require that behaviour from wallets if it was clearly required by the spec.

[Sakurann]

looks like no clarification is needed? closing unless further questions arise in a week

[brentzundel]

Group determined that text clarification is needed to make explicit that redirects will not be followed.

[Sakurann]

wg discussion. suggestion is to add a text in the security considerations "when not explicitly defined, redirects are not allowed".

[kaizencode-art]

wg discussion. suggestion is to add a text in the security considerations "when not explicitly defined, redirects are not allowed".

I’d also suggest clarifying what “explicitly defined” refers to: the base specification, the protocol binding, or an applicable profile. Otherwise, implementations may interpret the redirect policy differently.