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

[Judith Kahrer <[e-mail]>]

Hi Paul,

happy to read you largely agree on my points :)

Regarding the challenge I put down a proposal for how the authorization
server could request "additional security signals" from the client. I
believe there are other proposals that target the resource server, though I
don't remember which. I'll can dig that up if you find that helpful.

On Wed, May 20, 2026 at 9:36 AM Paul Bastian <[e-mail]> wrote:

> Hi Judith,
>
> thanks for your feedback! Further answers inline:
> On 5/7/26 12:24, Judith Kahrer wrote:
>
>
>
> 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.
>
> Agreed. The question is if this is too late, because the existing name is
> already heavily in use. A better name could be "Key-bound Client
> Attestation" in my view. How do others in the working group feel about
> renaming at that stage?
>
>
> 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".
>
> Agreed. We opened up
> https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/195
> and will come up with a proposal.
>
>
> 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...).
>
> Somewhat agreed. I think we don't want to say too much, as it's out of
> scope, but we could add some more text in the direction you suggested.
>
>
> +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]
>>
>