```suggestion * Verifiers and Wallets MUST support the "same-device" flow. Verifiers are RECOMMENDED to use only the "same-device" flow unless the Verifier does not rely on session binding for phishing resistance, e.g. in a proximity scenario. If "same-device" flow is used, then: ```

```suggestion Alternatively, ecosystems MAY choose to rely on other key attestation formats, meaning they would need to use a proof type other than `attestation`, define a new proof type, or expand the `jwt` proof type to support other key attestation formats. ```

```suggestion * mandate support for same device flow for redirect-based OpenID4VP ```

```suggestion * Implementation considerations can be found in Section 13.3 of [@!OIDF.OID4VP] and security considerations in Section 14.2 of [@!OIDF.OID4VP]. ```

```suggestion * Verifiers and Wallets MUST support the "same-device" flow. Verifiers are RECOMMENDED to use only the "same-device" flow and not the "cross-device" flow unless the Verifier does not need to rely on session binding for phishing resistance, e.g. in a proximity scenario. If "same-device" flow is used, then: ```

```suggestion ```

```suggestion * Verifiers and Wallets MUST support the "same-device" flow. Verifiers are RECOMMENDED to use only the "same-device" flow and not the "cross-device" flow unless the Verifier does not need to rely on session binding for phishing resistance, e.g. in a proximity scenario. If "same-device" flow is used, then: * 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]. ```

```suggestion * 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]. ```

```suggestion Note: This means cross-device flows using redirect based [@!OIDF.OID4VP] are not permitted in this profile. Where available, it is recommended to use (#oid4vp-dc-api) which allows secure cross device flows. Where the Digital Credentials API (or a platform equivalent) is not available, Verifiers can achieve a cross-device flow by securely transferring the user session to the other device before initiating the OpenID4VP flow. In this case, Verifiers MUST establish that the same user is interacting with both devices, for example by requiring the user to perform authentication on both devices and verifying the same account is used in both sessions. ```

I think you can read this as "when doing a same device flow, the Verifier MUST <...>" which I don't think was the intention. This might be clearer: ```suggestion * 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 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 web session to the one the request was initiated in. Implementation considerations in Section 13.3 and security considerations in Section 14.2 of [@!OIDF.OID4VP] MUST be applied. ``` (not sure the wording I added around 'web session' is really correct.) > Implementation considerations in Section 13.3 and security considerations in Section 14.2 of [@!OIDF.OID4VP] MUST be applied. Section 13.3 (to quote it) "outlines a possible design". I don't think it should be references in a 'MUST'. Not sure implementation considerations can really be a 'MUST be applied' either. For the record I still disagree with the approach and think it would be "acceptable" to allow cross device if the verifier achieves some session binding itself, because it we don't there's a massive drop in usability- for example in addition to use the redirect_uri, strongly authenticating the user on both devices and verifying it's the same user. Even if we keep this text, and verifiers actually respect it, cross device flows are a necessary user experience and we'll just see the verifiers do a qr-code based transfer from desktop to mobile to then invoke a same-device oid4vp flow. Which has just moved the problem around and avoided providing any advice on doing that securely.

```suggestion * Same-device flows MUST be enforced by the Verifier 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 the redirect to `redirect_uri`. Verifiers MUST reject presentations if Wallets do not follow the redirect back. Implementation considerations in Section 13.3 and security considerations in Section 14.2 of [@!OIDF.OID4VP] MUST be applied. ``` just because it's cleaner to have one requirement per sentence.