Original text:
this specification which the native application uses to obtain an authorization code.  The client initiates the authorization flow with or without information collected from the user (e.g. a password or MFA code).

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:
this specification which the native application uses to obtain an authorization code. <ins> Authorization servers supporting this specification SHOULD include the URL of their authorization challenge endpoint in their authorization server metadata document RFC8414 using the "authorization_challenge_request_endpoint" parameter as defined in authorization-server-metadata. The endpoint accepts the authorization request parameters defined in RFC6749 for the authorization endpoint as well as all applicable extensions defined for the authorization endpoint.  Some examples of such extensions include Proof Key for Code Exchange (PKCE) RFC7636, Resource Indicators RFC8707, and OpenID Connect (OIDC) [OIDC].  It is important to note that some extension 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 has no meaning in this use case. </ins> The client initiates the authorization flow with or without information collected from the user (e.g. a password or MFA code).