Thanks Paul. I saw in the minutes that there were some questions about non-wallet use cases, so I'd like to mention one. I'm currently implementing this draft to secure OpenID Connect for native apps. The main "novelty" compared to other use cases I've seen is binding additional signing and decryption keys into the attestation such that the native app can send signed requests and receive encrypted ID tokens. In this use case, the Client Attestation JWT + PoP JWT is used as client authentication and not as an "additional security signal". I have two motivations: 1) additional security and 2) compliance with certain national electronic identification scheme regulations.
Cheers, Frederik On Thu, 7 May 2026 at 00:10, 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]
