Original text:
PoP binding of device session parameter <del> 8.4.1. </del>  The client SHOULD use DPoP for every request, the AS SHOULD bind any artifacts returned to the DPoP key <del> 8.4.2. </del>  Possible, but of scope of this document. <del> 8.5. </del>  <del> Increased phishing risk </del>  <del> User confusion </del>  <del> Increased attack surface </del>  <del> Higher chance of incorrect implementations </del>  <del> 9. </del>  This document has no IANA actions.

Reviewer comments:
I'd like to discuss why we don't want to recommend supporting the spec for multiple first party apps? My thinking has been the protocol (whether in or out of scope) allows for a challenge/response method that the AS can control allowing it to support multiple apps at the same time. On the App side, this can be managed via an SDK that is used by all the first party apps. The AS needs to track which app versions have which capabilities to ensure the correct native experience is supported and if it's not possible to support the native experience then the AS asks the client to fall back to the web redirect experience.
Key point is that we don't want different user experiences implemented by the different apps. Add this topic in the Security Considerations section.
Also, if there are multiple 1st apps, can use OIDF Native SSO for Mobile Apps to create a better experience for the user
already stubbed some out in the draft, needs more expansion
Would we need a second profile to use this with OpenID Connect? How do we expect an AS that supports both OAuth and OIDC to implement this endpoint. Aaron - make sure this is possible without breaking anything. George - provide some guidance on what behaviour we want. Get AS behaviour consistent to simplify native implementations (no AS specific code needed). One idea - use examples from OIDC in a non-normative way. OmniAuth - maintains a list of providers their library supports. Aaron- 2 classes of implementors. (1) proprietary (2) those using OIDC
Copy language from PAR:
What profiling would we need to make to ensure that the new endpoint accepts any parameter the authorization end-point. The goal is to allow layering and use of other OAuth capabilities. Do we borrow from PAR?
Language from PAR: George: Some parameters have meaning in a web context but don't have meaning in a native mechanism (e.g. response_mode=query). It is out of scope as to what the AS does in the case that an extension defines a parameter that is invalid in this use case.

Revised text:
PoP binding of device session parameter  <ins> 9.4.1. </ins> The client SHOULD use DPoP for every request, the AS SHOULD bind any artifacts returned to the DPoP key  <ins> 9.4.2. </ins> Possible, but of scope of this document.  <ins> 9.5. </ins>  <ins> When there there is more than one 1st-party native applications supported by the AS, then it is important to consider a number of additional risks.  These risks fall into two main categories: Experience Risk and Technical Risk which are described below. </ins>  <ins> 9.5.1. </ins>  <ins> Any time a user is asked to provide the authentication credentials in user experiences that differ, it has the effect of increasing the likelihood that the user will fall prey to a phishing attack because they are used to entering credentials in different looking experiences.  When multiple native applications are support, the implementation MUST ensure the native experience is identical across all the 1st party native applications. </ins>  <ins> Another experience risk is user confusion caused by different looking experiences and behaviors.  This can increase the likelihood the user will not complete the authentication experience for the 1st party native application. </ins>  <ins> 9.5.2. In addition to the experience risks, multiple implementations in 1st party native applications increases the risk of an incorrect implementation as well as increasing the attack surface as each implementation may expose it's own weaknesses. 9.5.3. To address these risk, when multiple 1st party native applications must be supported, and other methods such as [Native SSO] are not applicable, it is RECOMMENDED that a client-side SDK be used to ensure the implementation is consistent across the different native apps and to ensure the user experience is identical for all 1st party apps. 10. </ins> This document has no IANA actions.