require support for same device flow for redirect-based OpenID4VP

[paulbastian]

Closes #98

[charsleysa]

I still think there needs to be consideration for in-person cross device flows, e.g. age assurance at a retail store. Being unable to use digital IDs in the real world or having poor user experience will be a hindrance to adoption of digital IDs, especially in jurisdictions where showing the digital ID on your device is forbidden to be accepted by the retail staff under trust framework rules.

[paulbastian]

lgtm now

[Sakurann]

suggestion projecting inner @tlodderstedt :

• without broad implementation experience, it's way too limiting to prohibit this right now.
• there might be use cases where cross device using vanilla openid4vp is acceptable, like in-person wallet-to-wallet
• move this to implementation considerations and say that this is conditional to risk analysis of

[jogu]

Discussed on today's WG call, consensus that:

There are some scenarios where cross-device flows have other mechanisms in place that mean phishing resistance is not required (e.g. in-person).

Add a "MUST support Same-Device".

"unless the Verifier does not require phishing resistance," should be reframed as "for scenarios where phishing resistance can be achieved in alternative ways".

Paul to update the PR and we'll hopefully merge on Thursday's WG call before starting public review.

[Sakurann]

Suggested change

	* The Verifier MUST reject flows that are non "Same-Device". It MUST do this by including `redirect_uri` in the HTTP response to the Wallet's HTTP POST to the `response_uri`, as defined in Section 8.2 of [@!OIDF.OID4VP]. Wallets MUST follow the redirect to `redirect_uri`. Verifiers MUST reject presentations if Wallets do not follow the redirect back or the redirect back arrives in a different user session to the one the request was initiated in. Implementation considerations can be found in Section 13.3 of [@!OIDF.OID4VP] and security considerations in Section 14.2 of [@!OIDF.OID4VP].
	* The Wallet and the Verifier MUST support "Same-Device" flow:
	* Verifiers MUST include `redirect_uri` in the HTTP response to the Wallet's HTTP POST to the `response_uri`, as defined in Section 8.2 of [@!OIDF.OID4VP].
	* Wallets MUST follow the redirect to `redirect_uri`.
	* Verifiers MUST reject presentations if Wallets do not follow the redirect back or the redirect back arrives in a different user session to the one the request was initiated in.
	* Implementation considerations can be found in Section 13.3 of [@!OIDF.OID4VP] and security considerations in Section 14.2 of [@!OIDF.OID4VP].
	* Non "Same-Device" flows can be acceptable in the scenarios where phishing resistance can be achieved in alternative ways. e.g. it is an in-person presentation using OpenID4VP via redirects. When doing so, ecosystems and implementations are advised to make this decision based on a risk analysis.