"a new response mode `post` in accordance with [OIDM]"

[Kristina Yasuda]

In PR #33 on Cross-device SIOP, a new response mode `post` is proposed. During Connect call on Aug-23-2021, there has been security concerns raised that it reuses redirect_uri that is use-facing, instead of using a separate endpoint.

[Torsten Lodderstedt]

We considered to use a different parameter. However, this would require definition of a new response type! Using a new response mode seemed to be the more lightweight approch.

I would like to understand the security concerns. Are they documented somewhere?

Note: the RP can put any endpoint value in the redirect_uri parameter it wants. It does not need to use the user facing endpoint.

[Michael Jones]

I understand that we could do this. It’s not clear to me why we’d do this. This would require additions to the infrastructure of every system using it, which is a big deal.

[Kristina Yasuda]

If I understand correctly, below are concerns around new response_mode=post. Some are from DW’s comments to PR #33

• Asking existing OIDC RPs to add support for a new response_mode=post might increase a barrier to adopt SIOP
• Session phishing protection of OIDC is a little lost, since OIDC responses are delivered via the front-channel, so that credentials are bound to the appropriate user agent to make a session. so response_mode=post (aka backchannel) means there's no guarantee you success is going back to anything under user control, it may be a malicious party acting as an intermediary.
• redirect_uri being browser-facing, may have requirements on the response having a transactional cookie, as well as WAF-style protections.
• lack of CORS would limit interactions with a browser-based SIOP (but we could probably craft things so that the request sends w/o CORS; you just won’t see a response).

‌

[Torsten Lodderstedt]

This is a mixture of very different concerns:

re 1: what is the alternative? I mean this argument applies to every new response mode, response type and grant type.

re 2: this is well known and covered in Daniel‘s security analysis. It is a characteristics all OOB flows share, including CIBA, device flow. The only viable security measure is to inform the user about the context of the request (e,g, the domain of the redirect URI). If we assume that Cross Device is a must in scenarios involving a wallet on the user’s device, what is the alternative to the proposed flow?

re 3: the RP can use a different URI. That’s why resolvable client ids are useful in SIOP context. A RP can use two different URIs for on and cross device flows but receives the same sub value in case of PPIDs.

re 4: I don’t get the argument. If the SIOP is browser based, the redirect URI must support CORS. We can simply add this to the spec. As already stated, the cross device redirect URI can be different from the on device redirect URI. So if a RO wants to utilize different CORS policies - it can do so. If the SIOP is not browser based, CORS is not an issue at all.

[Kristina Yasuda]

I am ok closing this issue as I think we reached consensus during the SIOP calls that POST method is the way to go for cross-device SIOP