[OAUTH-WG] Re: Next steps for Attestation-Based Client Authentication

[Judith Kahrer <[e-mail]>]

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 <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>