jiebi/CodeConvo huggingface dataset:
Code change:
Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types

Related discussion:
text: whether that is to do an MFA flow, or perform an OAuth redirect-based flow. <ins> In order to preserve the security of this specification, the Authorization Server MUST verify the "first-partyness" of the client before continuing with the authentication flow.  Please see first- party-applications for additional considerations. </ins> 5.1. The client makes a request to the authorization challenge endpoint by
Code change:
Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types

Related discussion:
text: 5.2. The authorization server determines whether the information provided <del> up to this point is sufficient to issue an authorization code, and responds with an authorization code or an error message. </del> <ins> up to this point is sufficient to issue an authorization code, and if so responds with an authorization code.  If the information is not sufficient for issuing an authorization code, then the authorization server MUST respond with an error response. </ins> 5.2.1.
Code change:
Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types

Related discussion:
text: code (unless specified otherwise) and includes the following parameters with the response: <ins> This specification requires the authorization server to define new error codes that relate to the actions the client must take in order to properly authenticate the user.  These new error codes are specific to the authorization server's implementation of this specification and are intentionally left out of scope. </ins> The parameters are included in the content of the HTTP response using the "application/json" media type as defined by RFC7159.  The parameters are serialized into a JSON structure by adding each
Code change:
Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types

Related discussion:
text: vary. The authorization server MAY define additional parameters in the <del> response depending on the implmentation. </del> <ins> response depending on the implmentation.  The authorization server MAY also define more specific content types for the error responses as long as the response is JSON and conforms to "application/<as- defined>+json". </ins> 5.3.
Code change:
Added text to address assigned issues: URL URL URL
tbd: "Due to the inability to securely attest to the first-partyness of a browser based application, it is NOT RECOMMENDED to use this application in a browser-based application."
Thinking out loud, would the hypothetic "SPA attestation" be possible in principle / make sense at all?
Yes, Chrome has a proposal for the "Web Integrity API", but it has received a lot of pushback: URL Safari already shipped Private Access Tokens which are similar: URL
There was some discussion at OSW about enforcing client auth first, before invoking the native flow to further build trust. It may be a good idea to add additional information, perhaps in the security considerations, about ways in which the server can have confidence that the first party app is a "real" first party app.
Yes, I agree. There are couple of ways the server can determine trust in the mobile app. We shouldn't be prescriptive but maybe putting some options in the security considerations would help make it more clear how to do this. Maybe there is best practice guidance that could be put in a doc like for single-page-apps.
NAME to update First-Party Applications section
in Section 9.1 URL
Add new normative requirement for authorization server to verify that the application is a first party application.
One of the participants in the OSW workshop suggested adding a content type parameter to allow them to specify for example a JSON structure or some other data format to control the native app experience. We have been deliberately avoiding defining a new language or re-inventing HTML, but allowing implementors to return complex content types of their own definition may be worth considering if this is a common enough use case.
Make it more clear in 5.2 that this spec expects the response to always be either the authorization code or an error URL Section 5.2.2 needs to make it clear that the authorization server has to define its own error codes URL Section 5.2.2 should explicitly allow more specific JSON content types

Related discussion:
text: applications and to ensure the user experience is identical for all first-party apps. <ins> 9.7. Single Page Applications (SPA) run inside the context of a browser instance.  Due to the inability to securely attest to the first- partyness of a browser based application, it is NOT RECOMMENDED to use this specification in a browser-based application. </ins> 10. IANA has (TBD) registered the following values in the IANA "OAuth
Code change:
Issue Add normative requirement for device binding of auth session and require the authorization server to enforce it.
Should we prohibit the auth_session from moving off-device to avoid resumption of the session on another device (avoid risks of session theft or session take-over).
auth_session is expected to be device bound
Discussion Add statement that authorization sessions are device bounds. Make it Normative in spec.
Resolved in

Related discussion:
text: server. The "auth_session" value is completely opaque to the client, and as <del> such the AS MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the AS is not maintaining state on the backend. </del> <ins> such the authorization server MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the authorization server is not maintaining state on the backend. </ins> If the client has an "auth_session", the client MUST include it in future requests to the authorization challenge endpoint.  The client
Code change:
Issue Add normative requirement for device binding of auth session and require the authorization server to enforce it.
Should we prohibit the auth_session from moving off-device to avoid resumption of the session on another device (avoid risks of session theft or session take-over).
auth_session is expected to be device bound
Discussion Add statement that authorization sessions are device bounds. Make it Normative in spec.
Resolved in

Related discussion:
text: values are static, and MUST be prepared to update the stored "auth_session" value if one is received in a response. <ins> To mitigate the risk of session hijacking, the 'auth_session' MUST be bound to the device, and the authorization server MUST reject an 'auth_session' if it is presented from a different device than the one it was bound to. </ins> See auth-session-security for additional security considerations. 6.
Code change:
Removed the need for the new ash claim by inverting the way in which binding works by putting responsibility for maintaining the binding on the authorization server (see issue ).
I do love "ash" as a claim name but (as DPoP co-author and a DE on the JWT Claims registry) I'd strongly suggest that the binding be done the other way around. Basically just say that the AS binds the authsession value to the the public key from the DPoP proof and checks the binding whenever the client sends the authsession. Binding that way is simpler (from the spec perspective anyway) and provides more protections. It's also how most of the binding in DPoP works ("ath" is kind of an outlier and provides somewhat questionable value). URL URL
Suggestion: also require a unique DPoP key per session to avoid risks around session binding.
Completed in
Looks good

Related discussion:
text: 9.6.1. If the client and authorization server are using DPoP binding of <del> access tokens and/or authorization codes, then they SHOULD also require DPoP binding of the "auth_session" value as well. </del> <ins> access tokens and/or authorization codes, then the "auth_session" value SHOULD be protected by the DPoP binding as well.  The authorization server SHOULD bind the "auth_session" value to the DPoP public key.  If the authorization server is binding the "auth_session" value to the DPoP public key, it MUST check that the same DPoP public key is being used and MUST verify the DPoP proof to ensure the client controls the corresponding private key whenever the client includes the "auth_session" in an Authorization Challenge Request as described in challenge-request. </ins> DPoP binding of the "auth_session" value ensures that the context referenced by the "auth_session" cannot be stolen and reused by another device. <del> This specification defines an additional claim in the DPoP Proof JWT Syntax defined in Section 4.2 of RFC9449: </del> 9.6.2. This specification makes no requirements or assumptions on the
Code change:
Removed the need for the new ash claim by inverting the way in which binding works by putting responsibility for maintaining the binding on the authorization server (see issue ).
I do love "ash" as a claim name but (as DPoP co-author and a DE on the JWT Claims registry) I'd strongly suggest that the binding be done the other way around. Basically just say that the AS binds the authsession value to the the public key from the DPoP proof and checks the binding whenever the client sends the authsession. Binding that way is simpler (from the spec perspective anyway) and provides more protections. It's also how most of the binding in DPoP works ("ath" is kind of an outlier and provides somewhat questionable value). URL URL
Suggestion: also require a unique DPoP key per session to avoid risks around session binding.
Completed in
Looks good

Related discussion:
text: IANA has (TBD) registered the following Claims in the "JSON Web Token Claims" registry IANA.JWT established by RFC7519. <del> : "ash" : The base64url-encoded SHA-256 hash of the ASCII encoding of the "auth_session" value : IETF : Section 9.6.1 of this specification </del>
Code change:
Proposed update based on feedback in issue Open question for reviewers (and NAME whether we should allow both or only a single method, and if a single methods should we opt for the least common denominator (dpopjkt) or an authorization challenge endpoint specific one?
Commented over in URL that I think the single method of the DPoP proof header is sufficient and preferred.
I would tend to agree that we should stick with only the header option for DPoP.
I'm good with that. Will create a PR to reflect this.
NAME and NAME I made the changes. please review and feel free to merge if ready.
Because the client interacts directly with the Authorization Challenge Endpoint the authorization code binding can and probably should be done via the DPoP proof rather than the dpop_jkt parameter. This is similar to what but here you could probably get away with just using the DPoP proof.
That makes sense, we should do it the same way that's recommended for PAR.
NAME I was reading the rationale for requiring both the dpopjkt parameter and adding the DPoP header to the PAR request: URL It looks like the goal was to keep client libraries simple so that they don't need to distinguish between PAR or front channel flows. If we remove dpopjkt, do we make it harder for implementors of client libraries? Given that this is a new end-point (Authorization Challenge Endpoint) and a native client, we may not need to keep support for both and we can be more prescriptive, but I wonder if we might cause confusion for implementors as we have established dpopjkt as the least common denominator (the reason for allowing it to be used with PAR end points). Perhaps we should have similar guidance to DPoP on supporting both dpopjkt and allowing the DPoP Header to be added to the Authorization Challenge Response? I guess the question is really if we settle dpop_jkt as a the least common denominator in all DPoP impementations?
I think the in PAR was more about keeping the commonalty of authz request parameters and their treatment on both sides. Not so much about being a least common denominator. I think this Authorization Challenge Endpoint is different enough that just using the DPoP proof is the way to go. Also, doing DPoP key binding of the needs the DPoP proof - so a client doing DPoP in this context really just should be sending the DPoP proof header.
Closing this as it was resolved in
looks okay to me (pending conflicts that need to be resolved)

Related discussion:
text: server. The "auth_session" value is completely opaque to the client, and as <del> such the AS MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the AS is not maintaining state on the backend. </del> <ins> such the authorization server MUST adequately protect the value from inspection by the client, for example by using a random string or using a JWE if the authorization server is not maintaining state on the backend. </ins> If the client has an "auth_session", the client MUST include it in future requests to the authorization challenge endpoint.  The client
Code change:
Proposed update based on feedback in issue Open question for reviewers (and NAME whether we should allow both or only a single method, and if a single methods should we opt for the least common denominator (dpopjkt) or an authorization challenge endpoint specific one?
Commented over in URL that I think the single method of the DPoP proof header is sufficient and preferred.
I would tend to agree that we should stick with only the header option for DPoP.
I'm good with that. Will create a PR to reflect this.
NAME and NAME I made the changes. please review and feel free to merge if ready.
Because the client interacts directly with the Authorization Challenge Endpoint the authorization code binding can and probably should be done via the DPoP proof rather than the dpop_jkt parameter. This is similar to what but here you could probably get away with just using the DPoP proof.
That makes sense, we should do it the same way that's recommended for PAR.
NAME I was reading the rationale for requiring both the dpopjkt parameter and adding the DPoP header to the PAR request: URL It looks like the goal was to keep client libraries simple so that they don't need to distinguish between PAR or front channel flows. If we remove dpopjkt, do we make it harder for implementors of client libraries? Given that this is a new end-point (Authorization Challenge Endpoint) and a native client, we may not need to keep support for both and we can be more prescriptive, but I wonder if we might cause confusion for implementors as we have established dpopjkt as the least common denominator (the reason for allowing it to be used with PAR end points). Perhaps we should have similar guidance to DPoP on supporting both dpopjkt and allowing the DPoP Header to be added to the Authorization Challenge Response? I guess the question is really if we settle dpop_jkt as a the least common denominator in all DPoP impementations?
I think the in PAR was more about keeping the commonalty of authz request parameters and their treatment on both sides. Not so much about being a least common denominator. I think this Authorization Challenge Endpoint is different enough that just using the DPoP proof is the way to go. Also, doing DPoP key binding of the needs the DPoP proof - so a client doing DPoP in this context really just should be sending the DPoP proof header.
Closing this as it was resolved in
looks okay to me (pending conflicts that need to be resolved)

Related discussion:
text: values are static, and MUST be prepared to update the stored "auth_session" value if one is received in a response. <ins> To mitigate the risk of session hijacking, the 'auth_session' MUST be bound to the device, and the authorization server MUST reject an 'auth_session' if it is presented from a different device than the one it was bound to. </ins> See auth-session-security for additional security considerations. 6.