Merge pull request #199 from oauth-wg/PieterKas-patch-82

Clarify limits of authenticate-then-initiate mitigations

Author: PieterKas

draft-ietf-oauth-cross-device-security.md

@@ -983,7 +983,7 @@ The user experience MAY include information to further educate the user on cross
 ### Authenticate-then-Initiate
 By requiring a user to authenticate on the Consumption Device with a phishing resistant authentication method before initiating a cross-device flow, the server can prevent an attacker from initiating a cross-device flow and obtaining QR codes or user codes. This prevents the attacker from obtaining a QR code or user code that they can use to mislead an unsuspecting user. This requires that the Consumption Device has sufficient input capabilities to support a phishing resistant authentication mechanism, which may in itself negate the need for a cross-device flow.
 
-**Limitations:** Authenticating on the Consumption Device before starting a cross-device flow does not prevent the attacks described in {{example-b5}} and {{Example-B7}} and it is RECOMMENDED that additional mitigations described in this document is used if the cross-device flows are used in scenarios such as {{example-a5}} and {{example-a7}}.
+**Limitations:** This mitigation is limited to Consumption Devices capable of supporting phishing resistant authentication mechanisms. Authenticating on the Consumption Device before starting a cross-device flow does not prevent the attacks described in {{example-b5}} and {{Example-B7}} and it is RECOMMENDED that additional mitigations described in this document is used if the cross-device flows are used in scenarios such as {{example-a5}} and {{example-a7}}.
 
 ### Request Initiation Verification {#request-verification}
 The user MAY be asked to confirm if they initiated an authentication or authorization request by sending a one-time password (OTP) or PIN to the user's Authorization Device and asking them to enter it on the Consumption Device to confirm the request. If the request was initiated without the users' consent, they would receive an OTP or PIN out of context which may raise suspicion for the user. In addition, they would not have information on where to enter the OTP or PIN. The user experience on the Authorization Device MAY reinforce the risk of receiving an out-of-context OTP or PIN and provide information to the user on how to report an unauthorized authentication or authorization request.