Original text:
Authorization Code Grant as defined in RFC6749 are more appropriate. If a protocol supports both same-device and cross-device modes (e.g., OpenID.SIOPV2), the cross-device mode SHOULD not be used for same- <del> device scenarios.  If an implementor decides to use a cross-device protocol or a protocol with a cross-device mode in a same-device scenario, the mitigations recommended in this document SHOULD be implemented to reduce the risks that the unauthenticated channel is exploited. </del>  6.

Reviewer comments:
Clarify the authorization server's role in detecting if a cross-device protocol is being used in a same-device scenario. See issue NAME
Give guidance that enforcement of same device use of the protocol is something the authorization server should do, in addition to a design time constraint. From Roy Williams: 1) At the end of section (5) there is a paragraph that talks about limiting Cross-device protocols on the same device. It does not seem to be something that a client could\would know about when let’s say YouTube TV requests auth and it ends up on Authenticator on the same device. In theory this would then be the Authenticator Service’s Job to determine this situation and respond with a well known pattern to drive the client to engage in a local oath call directly to authenticator. Full feedback here: URL I had promised at the 119 meeting that I would review this document and give feedback. I have completed that document and other than two potential clarification points, I found it to be helpful. The following two areas could be slightly improved: At the end of section (5) there is a paragraph that talks about limiting Cross-device protocols on the same device. It does not seem to be something that a client could\would know about when let's say YouTube TV requests auth and it ends up on Authenticator on the same device. In theory this would then be the Authenticator Service's Job to determine this situation and respond with a well known pattern to drive the client to engage in a local oath call directly to authenticator. In the case of 6.1.1 establishing proximity, there is a boundary (pun not intended) case where a device will shift between two different cellular providers. The IETF's Drone effort were examining the same problem as the drone flies close to an international boundary and flips back and forth to roaming and not. How to deal with this case or whether it is dependable is a question. I know that Pieter is suggesting Fido2, but the way this section is written a Consumption device may be on a weak Wifi and the authentication device has shifted to Cellular. Roy.

Revised text:
Authorization Code Grant as defined in RFC6749 are more appropriate. If a protocol supports both same-device and cross-device modes (e.g., OpenID.SIOPV2), the cross-device mode SHOULD not be used for same-  <ins> device scenarios.  An authorization server MAY choose to block cross- device protocols used in same-device scenarios if it detects that the same device is used.  An authorization Server may use techniques such as device fingerprinting, network address or other techniques to detect if a cross-device protocol is being used on the same device. If an implementor decides to use a cross-device protocol or a protocol with a cross-device mode in a same-device scenario, the mitigations recommended in this document SHOULD be implemented to reduce the risks that the unauthenticated channel is exploited. </ins> 6.