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. 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". 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...). +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]
