[siop] Definition of the same-device and cross-device flows
Issue #1448
resolved
There is a model that falls out of definitions of both same-device and cross-device flows in SIOP v2 specification. It’s when the flow starts and ends on one device, but the response_mode used is the same as if separate devices are involved. A table below might help:
| Request | Response | |
|---|---|---|
| original cross-device model | QR code | HTTP POST request |
| original same-device model | deep-link | redirect |
| <<How to call this?>> | deep-link | HTTP POST request |
Below is the current definition of the same-device and cross-device flows in SIOP v2 specification.
Same-Device Self-Issued OP model: Self-Issued OP is on the same device on which the End-User's user interactions are occurring. The RP might be a Web site on a different machine and still use the same-device Self-Issued OP protocol flow for authentication.
Cross-device Self-Issued OP model: Self-Issued OP is on a different device than the one on which the End-User's user interactions are occurring
We could modify the definition or we could add a note to accommodate a third model…
Comments (5)
-
Account Deactivated
-
reporter
Vittorio gave feedback on Jan-5th-2023 SIOP call that same-device and cross-device both should be first-class citizens in SIOPv2 and OID4VP.
-
reporter
I would have to think a little more, but my two cents right now would be to stop using the term same-device, cross-device altogether.
in OpenID4VP and SIOPv2, we can replace
cross-devicewith response_mode direct_post, and in VCI, just talk about how request can be QR code or a deeplink - as there is nodirect_postin VCI -
reporter
i really need to do a PR: https://bitbucket.org/openid/connect/pull-requests/404#comment-361285488
-
- changed status to resolved
Migrated to GitHub
- Log in to comment
It’s not practical or sometimes even possible for implementations to even detect when this third model is happening. The RP cannot know the OP is on the same device, and the OP upon getting a deep link may not be given permission to any referrer information by the platform as to the origin of the request.
It will result in a very poor user experience, where they will be left in the OP after the response and have to self navigate back to the RP app/page on the same device.
I still strongly believe the HTTP POST response should always have the ability to result in a redirect in same device AND cross device flows. This guarantees the RP some way of communicating with the user even if they just want to display a custom success page. This is especially important if something went wrong in the response, such as if potential fishing was detected by the RP and they need to communicate to the user.