Original text:
3.1. A common action in cross-device flows is to present the user with a <del> QR code or a user code on the initiating device (e.g., Smart TV) which is then scanned or entered on the authorization device (the </del>  mobile phone).  When the user scans the code or copies the user code, they do so without any proof that the QR code or user code is being displayed in the place or context intended by the service provider. <del> It is up to the user's judgment to decide on whether they can trust the QR code or user code.  In effect the user is asked to compensate for the absence of an authenticated channel between the initiating device (smart TV) and the device on which the authentication/ authorization will take place (the mobile phone). </del>  Attackers exploit this absence of an authenticated channel between the two devices by obtaining QR codes or user codes (e.g., by initiating the authorization flows).  They then use social engineering techniques to change the context in which authorization is requested to trick end-users to scan the QR code or enter it on <del> their mobile devices.  Once the end-user performs the authorization on the mobile device, the attacker who initiated the authentication or authorization request obtains access to the users resources.  The figure below shows an example of such an attack. </del>  3.2. <del> In the client transferred pattern, the client instructs the authorization server to authenticate the user and obtain </del>  authorization for an action.  This may happen as a result of user <del> interaction with the initiating device, but may also be triggered without the users direct interaction with the initiating device, </del>  resulting in an authorization request presented to the user without context of why or who triggered the request.

Reviewer comments:
Changed name of "User transferred" attack to User Transferred Session Data Pattern - see Issue
Is this a duplicate with PR ?
Resolving issue
Resolving

Revised text:
3.1. A common action in cross-device flows is to present the user with a  <ins> QR code or a user code on the Initiating Device (e.g., Smart TV) which is then scanned or entered on the Authorization Device (the </ins> mobile phone).  When the user scans the code or copies the user code, they do so without any proof that the QR code or user code is being displayed in the place or context intended by the service provider.  <ins> It is up to the user to decide whether they should trust the QR code or user code.  In effect the user is asked to compensate for the absence of an authenticated channel between the Initiating Device (e.g., smart TV) and the Authorizing Device (e.g., the mobile phone). </ins> Attackers exploit this absence of an authenticated channel between the two devices by obtaining QR codes or user codes (e.g., by initiating the authorization flows).  They then use social engineering techniques to change the context in which authorization is requested to trick end-users to scan the QR code or enter it on  <ins> their Authorization Device (e.g., mobile phone).  Once the end-user performs the authorization on the mobile device, the attacker who initiated the authentication or authorization request obtains access to the users resources.  The figure below shows an example of such an attack. </ins> 3.2.  <ins> In the backchannel transferred session pattern, the client requests the authorization server to authenticate the user and obtain </ins> authorization for an action.  This may happen as a result of user  <ins> interaction with the Initiating Device, but may also be triggered without the users direct interaction with the Initiating Device, </ins> resulting in an authorization request presented to the user without context of why or who triggered the request.