Hi Paul, happy to read you largely agree on my points :)
Regarding the challenge I put down a proposal for how the authorization server could request "additional security signals" from the client. I believe there are other proposals that target the resource server, though I don't remember which. I'll can dig that up if you find that helpful. On Wed, May 20, 2026 at 9:36 AM Paul Bastian <[email protected]> wrote: > Hi Judith, > > thanks for your feedback! Further answers inline: > On 5/7/26 12:24, Judith Kahrer wrote: > > > > Hi Paul, > > I support the DPoP addition in the editor's draft. To be honest, I have > never been a big fan of the separate PoP-JWT but I have to admit that the > draft improved quite a lot since I looked at it the last time! > > Reading the draft again, it actually contains two mechanisms: > - On the one hand, it defines a new client authentication method for an > OAuth client (attest_jwt_client_auth) as indicated by the title. > - On the other hand, it describes a mechanism for "additional security > signals". > > Imo, the title of the document should reflect both - or you split them up > into two. > > Agreed. The question is if this is too late, because the existing name is > already heavily in use. A better name could be "Key-bound Client > Attestation" in my view. How do others in the working group feel about > renaming at that stage? > > > Is there a way for the resource server (or authorization server) to > challenge the client to provide additional security signals? I guess, they > could return an 'invalid_client_attestation' error, if the request was > missing an attestation. I think it would be good with more guidance on how > to inform the client to provide the attestation as additional security > signals if it is missing (in addition to e.g., the access token or client > credentials). The resource server could even publish its requirements in > its resource metadata document, e.g., with "client_attestation_required: > true". > > Agreed. We opened up > https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/195 > and will come up with a proposal. > > > I agree with the conversation in the minutes. Leave the details of the > attestation process out of scope. However, I suggest you list the > requirements as it currently is unclear what attestation means. What do you > expect an attester to validate at a bare minimum (i.e., client instance > controlling the key)? What makes the key-bound JWT a client attestation? > What information should/does the client attestation JWT convey? In section > 6.4 you mention: "[Sending additional security signals] may provide > additional assurance about the client's authenticity, integrity, state or > other information contained in the Client Attestation". Make it clear (as > part of the terminology?) that this is what you expect from an attester and > client attestation. Imo, the client's authenticity and integrity are key to > an attestation (without having to get into technical details...). > > Somewhat agreed. I think we don't want to say too much, as it's out of > scope, but we could add some more text in the direction you suggested. > > > +1 on the use case for platform-specific apps (so-called "native apps". I > prefer to avoid the term native to foster a more inclusive language). At > Curity we have implemented something very similar for our Hypermedia > Authentication API (HAAPI) quite some time ago to support mobile apps. I > can also picture a use-case where you use client attestation in DCR, for > example, to establish trust in the client (comparable to software > statement). > > Cheers, > Judith > > On Thu, May 7, 2026 at 12:11 AM Paul Bastian <[email protected]> > wrote: > >> Hi all, >> >> on Monday we had the OAuth Interims call dedicated to Attestation-Based >> Client Authentication, see the minutes for details: >> https://datatracker.ietf.org/doc/minutes-interim-2026-oauth-01-202605041700/ >> >> As a follow-up, we want to bring the following points also to the mailing >> list to reach out to people that did not participate on the Interims call: >> >> - we presented the integration of the combined DPoP mode into the >> editor's draft, allowing to use a single key for both DPoP and >> Attestation-Based Client Authentication and re-use the DPoP Proof Header as >> a proof of possession for the Client Attestation JWT. We are looking for >> feedback on the current draft before making a new release >> - we discussed which which OAuth artefacts should explicitly be bound to >> the client instance and the client instance key of the client attestation >> JWT. Currently we have language for the refresh token and there are two >> open Github issues >> https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/56 >> and >> https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/114 >> that discuss whether auth code or other artifacts shall be bound to the >> client instance. If you have opinions on this, please respond in either >> issue or respond to this mail >> - we discussed whether explicit relationship to DCR should be mentioned, >> see >> https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/61. >> The feeling in the Interims call was to not include specific language >> - we discussed whether we should be more descriptive about the mechanisms >> how the client instance authenticates towards the client attester, see >> https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/107 >> . These steps are currently out-of-scope and the feeling in the interims >> call was to not include specific technologies >> - we discussed the AS/Client metadata for supported algorithms, see >> https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/170 >> . The proposal is to remove >> client_attestation_signing_alg_values_supported and >> client_attestation_pop_signing_alg_values_supported and rather re-use >> the existing token_endpoint_auth_signing_alg_values_supported. There was >> discussion whether client metadata makes sense, feedback is welcome. >> >> If you want to provide feedback, respond to this mail or post in the >> relevant Github issues. >> >> Best regards, >> Paul >> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
