Section 3.6 (the section about an attacker emulating an enterprise application) is the canonical example of an illicit consent grant attack leveraging the device authorization grant. One of the key things that makes this attack particularly scary is the fact that everything the targeted user sees (outside of perhaps the non-ordinary flow involving user_code entry) indicates to them that they're signing into a trusted enterprise application, since you can use a trusted app's client ID when initiating the flow. In reality, however, they're just completing the second leg of a flow initiated by some attacker's script.
While you mention "emulating an enterprise application", I don't think that provides the clearest example of why this is particularly scary. I think you could go a bit further and emphasize that everything the user sees in this sort of attack is: a) trusted UX and b) indicates that they're signing into a trusted application.
Section 3.6 (the section about an attacker emulating an enterprise application) is the canonical example of an illicit consent grant attack leveraging the device authorization grant. One of the key things that makes this attack particularly scary is the fact that everything the targeted user sees (outside of perhaps the non-ordinary flow involving user_code entry) indicates to them that they're signing into a trusted enterprise application, since you can use a trusted app's client ID when initiating the flow. In reality, however, they're just completing the second leg of a flow initiated by some attacker's script.
While you mention "emulating an enterprise application", I don't think that provides the clearest example of why this is particularly scary. I think you could go a bit further and emphasize that everything the user sees in this sort of attack is: a) trusted UX and b) indicates that they're signing into a trusted application.