jiebi/CodeConvo huggingface dataset:
Code change:
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.

Related discussion:
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).
Code change:
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.

Related discussion:
text: parameters with the response: The parameters are included in the content of the HTTP response using <del> the "application/json" media type as defined by [RFC7159].  The </del> <ins> the "application/json" media type as defined by RFC7159.  The </ins> parameters are serialized into a JSON structure by adding each parameter at the highest structure level.  Parameter names and string values are included as JSON strings.  Numerical values are included
Code change:
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.

Related discussion:
text: 8. <del> 8.1. </del> <ins> The following authorization server metadata parameters RFC8414 are introduced to signal the server's capability and policy with respect to 1st Party Native Applications. 9. 9.1. </ins> Because this specification enables a client application to interact directly with the end user, and the application handles sending any
Code change:
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.

Related discussion:
text: belonging to the same brand as the authorization server.  For example, a bank publishing their own mobile application. <del> 8.2. </del> <ins> 9.2. </ins> There are two ways using this specification increases the risk of phishing.
Code change:
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.

Related discussion:
text: require that the user go through a redirect-based flow at any stage of the process based on its own risk assessment. <del> 8.3. </del> <ins> 9.3. </ins> Typically, mobile and desktop applications are considered "public clients" in OAuth, since they cannot be shipped with a statically
Code change:
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.

Related discussion:
text: client impersonation, such as using attestation APIs available from the operating system. <del> 8.4. </del> <ins> 9.4. </ins> TODO: Describe how to add proof of possession into the various parts of this flow.  Describe why, because things like device session could
Code change:
Included use cases for OTP, e-mail, SMS confirmation, step-up authentication and registration. Also see and

Related discussion:
text: The error may contain additional information to guide the Client on what information to collect next.  This pattern of collecting information, submitting it to the Authorization Challenge Endpoint <del> and then receing an error or authroization code may repeat several </del> <ins> and then receing an error or authorization code may repeat several </ins> times. (D) The client gathers additional information (e.g. passkey, or
Code change:
Included use cases for OTP, e-mail, SMS confirmation, step-up authentication and registration. Also see and

Related discussion:
text: DPoP is an application-level mechanism for sender-constraining OAuth RFC6749 access and refresh tokens I-D.ietf-oauth-dpop.  If DPoP is used to sender constrain tokens, the native client SHOULD use DPoP <del> for every token request to the Authroization Server and interaction </del> <ins> for every token request to the authorization Server and interaction </ins> with the Resource Server. DPoP includes an optional capability to bind the authorization code
Code change:
I added three sections I feel are important: ) Credential Stuffing/Abuse callout in security considerations. Browser-based front ends have lots of security checks inherently built in to an IdP's flow. If we move the authNZ to be backend API based then it's important to call out to implementors that they should treat that API with the same security concerns as whatever API recieves request when a login form is submitted. ) New Grant Type needed. ) DCR Registration consideration and 4.) corrected minor typo Happy to discuss. I have other updates I'll add and submit PRs/issues for later.

Related discussion:
text: 9.3. <ins> The authorization challenge endpoint is capable of directly receiving user credentials and returning authorization codes.  This exposes a new vector to perform credential stuffing attacks, if additional measures are not taken to ensure the authenticity of the application. An authorization server may already have a combination of built-in or 3rd party security tools in place to monitor and reduce this risk in browser-based authentication flows.  Implementors SHOULD consider similar security measures to reduce this risk in the authorization challenge endpoint.  Additionally, the attestation APIs SHOULD be used when possible to assert a level of confidence to the authorization server that the request is originating from an application owned by the same party. 9.4. </ins> Typically, mobile and desktop applications are considered "public clients" in OAuth, since they cannot be shipped with a statically configured set of client credentials RFC8252.  Because of this,
Code change:
I added three sections I feel are important: ) Credential Stuffing/Abuse callout in security considerations. Browser-based front ends have lots of security checks inherently built in to an IdP's flow. If we move the authNZ to be backend API based then it's important to call out to implementors that they should treat that API with the same security concerns as whatever API recieves request when a login form is submitted. ) New Grant Type needed. ) DCR Registration consideration and 4.) corrected minor typo Happy to discuss. I have other updates I'll add and submit PRs/issues for later.

Related discussion:
text: client impersonation, such as using attestation APIs available from the operating system. <del> 9.4. </del> <ins> 9.5. </ins> Tokens issued to native apps SHOULD be sender constrained to mitigate the risk of token theft and replay.
Code change:
I added three sections I feel are important: ) Credential Stuffing/Abuse callout in security considerations. Browser-based front ends have lots of security checks inherently built in to an IdP's flow. If we move the authNZ to be backend API based then it's important to call out to implementors that they should treat that API with the same security concerns as whatever API recieves request when a login form is submitted. ) New Grant Type needed. ) DCR Registration consideration and 4.) corrected minor typo Happy to discuss. I have other updates I'll add and submit PRs/issues for later.

Related discussion:
text: possession sender constrained token is presented without valid proof of possession of the cryptographic key, it MUST be rejected. <del> 9.4.1. </del> <ins> 9.5.1. </ins> DPoP is an application-level mechanism for sender-constraining OAuth RFC6749 access and refresh tokens I-D.ietf-oauth-dpop.  If DPoP is
Code change:
I added three sections I feel are important: ) Credential Stuffing/Abuse callout in security considerations. Browser-based front ends have lots of security checks inherently built in to an IdP's flow. If we move the authNZ to be backend API based then it's important to call out to implementors that they should treat that API with the same security concerns as whatever API recieves request when a login form is submitted. ) New Grant Type needed. ) DCR Registration consideration and 4.) corrected minor typo Happy to discuss. I have other updates I'll add and submit PRs/issues for later.

Related discussion:
text: Server MUST reject the request (do we need to define a specific error code for that?). <del> 9.4.2. </del> <ins> 9.5.2. </ins> It may be possible to use other proof of possession mechanisms to sender constrain access and refresh tokens.  Defining these mechanisms are out of scope for this specification. <del> 9.4.3. </del> <ins> 9.5.3. </ins> PoP binding of device session parameter <del> 9.5. </del> <ins> 9.6. </ins> When 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. <del> 9.5.1. </del> <ins> 9.6.1. </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 <del> experiences.  When multiple native applications are support, the </del> <ins> experiences.  When multiple native applications are supported, the </ins> implementation MUST ensure the native experience is identical across all the 1st party native applications.
Code change:
I added three sections I feel are important: ) Credential Stuffing/Abuse callout in security considerations. Browser-based front ends have lots of security checks inherently built in to an IdP's flow. If we move the authNZ to be backend API based then it's important to call out to implementors that they should treat that API with the same security concerns as whatever API recieves request when a login form is submitted. ) New Grant Type needed. ) DCR Registration consideration and 4.) corrected minor typo Happy to discuss. I have other updates I'll add and submit PRs/issues for later.

Related discussion:
text: will not complete the authentication experience for the 1st party native application. <del> 9.5.2. </del> <ins> 9.6.2. </ins> 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. <del> 9.5.3. </del> <ins> 9.6.3. </ins> To address these risk, when multiple 1st party native applications must be supported, and other methods such as OpenID.Native-SSO are
Code change:
Added option for redirecting to the web. Notes: Re-using the PAR response - feels strange to have the "request_uri" parameter as the redirect URI - is that OK? Added and example of redirecting to the web. Not entirely sure how control gets passed back to the "native" app/client or how much detail we should provide.
I see the problem with the current text. In PAR, the response is a which represents the PAR request itself: The client is expected to then start an authorization request and put the value in the query string parameter: So the text in this section should instead be:

Related discussion:
text: 5.2.2. <ins> In the case where the authorization server wishes to interact with the user directly, it can return the "redirect" response.  The authorization server may choose to interact directly with the user based on a risk assesment, the introduction of a new authentication method not supported in the application, or to handle an exception flow like account recovery.  In this case the client is expected to initiate a traditional OAuth Authorization Code flow with PKCE according to RFC6749 and RFC7636. 5.2.3. </ins> If the request contains invalid parameters or incorrect data, the authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following