openid
Unclear whether wallet should follow HTTP redirects
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.
The conformance suite doesn't follow redirects for request Uris, or any other cases other than in the authorization endpoint.
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.
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?
