Original text:
In cross-device flows that follow the user-transferred authorization data pattern, the client on the Initiating Device initiates the authorization request, but the user still has to transfer the <del> authorization code to the Initiating Device.  The authorization request may happen as a result of user interaction with the Initiating Device, but may also be triggered without the user's direct interaction with the Initiating Device. </del>  Attackers exploit the user-transferred authorization data pattern by combining the social engineering techniques used to set context for <del> users and tricking users into providing them with access codes sent to their phones.  These attacks are very similar to phishing attacks, except that the attacker also has the ability to trigger the </del>  authorization request to be sent to the user directly by the Authorization Server. The unauthenticated channel may also be exploited in variations of <del> the above scenario where the user (as opposed tot he attacker) initiates the flow and is then tricked into sending the authorization data (e.g. access code) to the attacker.  In these flows, the user is already authenticated and they request authroization data to transfer </del>  a session or obtain some other privilege such as joining a device to <del> a network.  The authorization data may be represented as a QR code o text message.  The attacker then proceeds to exploit the </del>  unauthenticated channel by using social engineering techniques to <del> trick the user into initiating a flow and send the QR code or user code to the attacker, which the attacker use to obtain the privileges </del>  that would have been assigned to the user. 3.4.

Reviewer comments:
Editorial clarifications based on feedback from Aaron Parecki (see )
A couple of editorial suggestions, but otherwise this looks fine to me!

Revised text:
In cross-device flows that follow the user-transferred authorization data pattern, the client on the Initiating Device initiates the authorization request, but the user still has to transfer the  <ins> authorization data to the Initiating Device.  The authorization data may take different forms, including a numerical value such as a 6 digit authorization code.  The authorization request may happen as a result of user interaction with the Initiating Device, but may also be triggered without the user's direct interaction with the Initiating Device. </ins> Attackers exploit the user-transferred authorization data pattern by combining the social engineering techniques used to set context for  <ins> users and tricking users into providing them with authorization data sent to their phones.  These attacks are very similar to phishing attacks, except that the attacker also has the ability to trigger the </ins> authorization request to be sent to the user directly by the Authorization Server. The unauthenticated channel may also be exploited in variations of  <ins> the above scenario where the user (as opposed to the attacker) initiates the flow and is then convinced using social engineering techniques into sending the authorization data (e.g. a 6 digit authorization code) to the attacker.  In these flows, the user is already authenticated and they request authorization data to transfer </ins> a session or obtain some other privilege such as joining a device to  <ins> a network.  The authorization data may be represented as a QR code or authorization code.  The attacker then proceeds to exploit the </ins> unauthenticated channel by using social engineering techniques to  <ins> convince the user to send the QR code or user code to the attacker. The attacker then use the authroization data to obtain the privileges </ins> that would have been assigned to the user. 3.4.