Hi Paul, Frederik and everyone, Sorry for the long silence since the IIW last fall.
I am also working on a native app implementation using this draft. I would like to follow up on the "Integration with iOS App Attest" that I mentioned back then to see if there are any updates or if there is change of interest in the group regarding the use of the non-standard signing algorithm. Best regards, Kosuke Koiwai 2026年5月7日(木) 16:37 Frederik Krogsdal Jacobsen <[email protected]>: > > 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] _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
