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]
