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 <[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]
