[OAUTH-WG] Re: WG Last Call: draft-ietf-oauth-attestation-based-client-auth-11 (Ends 2026-09-22)

[Frederik Krogsdal Jacobsen <[e-mail]>]

I support publication of this document.
I have implemented the newest draft version (without the DPoP combined
mode) and have plans to use it in production deployments.

Some comments based on my implementation experience:
- As written, the spec does not normatively require replay protection for
PoPs to actually be implemented by the verifier. Is this intentional?
- Even though trust management is explicitly out of scope, I think there
should be a normative statement that an AS which trusts multiple attesters
must somehow scope the accepted client_ids to each attester to prevent
multiple attesters from asserting the same client_id.
- I think there might be a kind of mild "downgrade" attack allowing a mode
switch from "normal" to "combined" by removing the PoP header. The severity
of this is probably pretty limited, but it feels fragile to signal combined
mode only by the absence of the OAuth-Client-Attestation-PoP header.
- I think iat should be REQUIRED. Otherwise, the AS cannot actually
determine how fresh an attestation is, and has to exclusively rely on the
exp from the attester which the AS does not control.
- I didn't implement combined mode, but I think that there should be a line
explicitly saying that a server implementing combined mode SHOULD also
provide DPoP nonces (which are optional in RFC 9449).
- The text is not currently clear on the fact that a client instance needs
to remember which client instance key each instance-bound protocol artifact
(i.e. refresh tokens) is actually bound to. If it doesn't do this, changing
client instance keys will result in bad user experiences (potentially
unbounded retries). Usually the client instance key rotation is not the
choice of the client instance, but is something the platform does for your
e.g. when biometrics are reset/updated, so this is something that will
happen to most implementations. Guidance would be helpful.
- It would be helpful for interoperability to define the status codes that
should be used for use_fresh_attestation and invalid_client_attestation
errors.
- I disagree with Denis' comment #1 about revocation. A revocation status
check would allow the attester to learn which AS the client is talking to
which goes against the core design goal for the wallet use case. The
expiration is enough and aligned with how DPoP and private_key_jwt works.
- Regarding Denis' comment #2, I think the current text is clear enough and
that the proposed text introduces unnecessary redundancy.
- I disagree with Denis' comment #5 about sub correlation. The sub
generally identifies the client software (via client_id), not the instance.
It therefore does not let two servers determine that they saw the same
instance, only that they saw instances of the same software. The point
about revocation is also not correct, as the sub does not identify specific
instances.
- I agree in principle with Denis' comment #7 about trust in additionally
attested claims, though I think the framing about liability is
inappropriate in an IETF document.

Nits (line numbers in .txt version linked in Rifaat's message):
- Heading capitalization seems a bit random
- Inconsistent use of OAuth 2 and OAuth 2.0.
- Inconsistent use of "use case" and "use-case"
- The steps listed for validation in section 7.3 are not really written as
steps. The sentence should probably be rewritten to match the "conditions
and rules" framing in section 7.2.
- The "applications using this media type" field in the IANA registration
for oauth-client-attestation-pop+jwt looks wrong. I would expect it to say
something like "applications that use this spec to convey a client
attestation with PoP" but the text currently mentions token status
information.
- The document history for version 11 has a duplicate bullet about removing
the duplication challenge verification.
- Section 10.5 mentions size limits "as of 2024" which should probably be
updated to the current limits.
- The HTTP syntax uses token68 which I think is supposed to be deprecated
(see section 16.4.2 of RFC 9110). I'm also not sure it is compatible with
defining the HTTP field types as "Item".
- Line 753 says "an use_attestation_challenge" instead of "a
use_attestation_challenge"
- Line 830 says "a HTTP header-based" instead of "an HTTP header-based"
- Line 1444 says that cryptographic operations need to be constructed,
where I think you mean that they need to be performed
- Line 1522 says "and or" instead of "and/or"
- Line 1524: what is "the HTTP"? Just HTTP or is there a missing word here?
- Lines 1670 and 1692 say "Details how ... is given in ..." instead of
"Details how ... are given in ..."
- Line 2559 says "Verifivation" instead of "Verification"
- Line 2567 does not really make sense as a sentence
- Line 2664 says "it's own top" instead of "its own top"
- Line 2766 calls the header Oauth-Client-Attestation instead of
OAuth-Client-Attestation
- I think the document could generally benefit from a grammar pass.

Cheers,
Frederik


On Thu, 10 Sept 2026 at 08:22, Denis <denis.ietf=[e-mail]>
wrote:

> *Seven comments on draft-ietf-oauth-attestation-based-client-auth-11
>
> (1) General. The draft does not address in section 4 or elsewhere the suspension or the revocation
>     of a Client Attestation JWT.  This important consideration should be added into the draft.
> *
>
> *(2) Page 6. Section 1.1 (**Data Flow).*
>
> *Change: *
>
> *   *  optionally, properties of that key (e.g., that it was securely
>       generated or resides in hardware-backed storage) *
>
> *into: *
>
> *   *  optionally, characteristics of the Client Instance (e.g.,
>       the criteria against which the Client Instance has been assessed
>       and in particular the protection of keys managed by the Client
>       Instance, as well as the protection aimed at limiting the use
>       of these keys to that Client Instance) *
>
>
>
>
> *Rational: The field is renamed from "properties of that key" to
> "characteristics of the Client Instance" which is more general. The
> characteristics of the Client Instance may include additional features or
> properties that are unrelated to the protection or use of keys managed by
> the Client Instance. *
>
>
> * (3) Page 7. Section 3 (Terminology).  *
>
> *Change: *
>
> *   Client Attestation JWT:  A JSON Web Token (JWT) generated by the
>       Client Attester that attests to the authenticity of a Client
>       Instance and is cryptographically bound to a key managed by that
>       Client Instance.  A Client Attestation JWT may additionally convey
>       information about the integrity or state of the Client Instance. *
>
> *into: *
>
> *   Client Attestation JWT:  A JSON Web Token (JWT) generated by the
>       Client Attester that attests to the authenticity of a Client
>       Instance and is cryptographically bound to a key managed by that
>       Client Instance.  A Client Attestation JWT may additionally
>       convey information about the characteristics of the Client
>       Instance. *
>
> *Rational: The second sentence is changed to use the words "characteristics of the Client Instance". *
>
> *
> (4) Page 18. Section 7.1 (Client Attestation JWT)
>
> The first instance of a client_id appears in the item 7:
> *
>
> *   7.  If a client_id is provided in the request containing the Client**       Attestation, then this client_id matches the sub claim of the**       Client Attestation JWT, unless specified otherwise by a profile**       as described in Section 13.*
>
>
>
>
> *The use of this parameter is not sufficiently explained. An explanation
> is provided in section 7.5. A reference to section 7.5 should be added
> and/or some text of that section should be copied here. *
>
> *(5)** Page 30. Section 11.1 (Client Instance Tracking Across
> Authorization Servers or Resource Servers)*
>
> *In a Client Attestation JWT, the sub claim is defined as:
>
> *  sub: REQUIRED.  The sub (subject) claim MUST specify the client_id
>       value of the OAuth Client, unless specified otherwise by a profile
>       as described in Section 13.
>
> Since the sub claim is REQUIRED, using different Client Instance Keys will be insufficient
> to prevent tracking Across Authorization Servers or Resource Servers.
>
> Tracking can also be made using the exp (expiration time) claim and the iat (issued at) claim
> when they are defined with a fine level of granularity.
>
> Section 13 (mentioned in the above sentence) states:
>
>    A profile MAY deviate on the following points:
>
>    *  The subject of the Client Attestation JWT: a profile MAY redefine
>       the meaning of the sub claim (see Section 4) and how a client_id
>       maps to Client Instances.  Such a profile MUST define how the
>       checks that rely on sub matching the client_id are replaced, in
>       particular those in Section 7.1 and Section 7.5.
>
> This explanation is unclear.
>
> The 'sub' field can be useful to suspend or revoke a Client Attestation JWT.
> If the 'sub' field is made OPTIONAL, then tracking Client Instance JWTs across Authorization Servers
> or Resource Servers can be prevented, but suspension or revocation will no more be possible.
>
> One solution to consider will be to allow tracking Client Instance JWTs across Authorization Servers,
> but not across Resource Servers.
>
> In this way, Authorization Servers will be able to ask for the revocation of one or more Client Attestation JWTs
> by a Client Attester and to verify that a Client Attestation JWT has not be suspended or revoked **by the Client Attester.**
> In certain deployment scenarios, there will be a single Authorization Server and hence there will not be a tracking problem
> across Authorization Servers.
>
> Some text should be added to address this issue.
>
>
> (6) Page 30. Section 11.1 (Client Instance Tracking Across Authorization Servers or Resource Servers)
>
> Whatever solution will be described to address the previous issue, the following text addition is proposed:
>
>    In certain deployment scenarios, the number of Resource Servers
>    can be quite large compared to the number of Authorization Servers.
>    In such a case, instead of supporting this protocol between a
>    Client Instance and a Resource Server, an alternative approach
>    can be used that **allows to limit the number of Client Attestation
>    JWTs with different Client Instance Keys**. *
>
>
>
>
>
>
>
>
>
> *   At step (7), when the Client Instance accesses a protected resource,
>    it may present a security token either directly issued by an
> Authorization Server or derived by the Client Instance from data    issued
> by an Authorization Server.  The Authorization Server    can include into
> the issued data the characteristics of the Client    Instance.  In this
> way, since the Resource Server trusts the    Authorization Server, it can
> rely on the Client Instance    characteristics contained in the security
> token.  This is a    transitive trust relationship.*
>
> *Rational: This alternative approach allows the use of **Client
> Attestation *
> *JWTs exclusively with Authorization Servers.*
>
>
> * (7) Page 32. Add a new section under section 12 (Security
> Considerations) called:  *
>
> *12.3 Characteristics of the Client Instance *
>
> *   In a Client Attestation JWT, the characteristics of the Client
>    Instance are optional.  When they are included in it, before
>    accepting or validating these characteristics, the Authorization
>    Server (or the Resource Server) must verify that it can trust the
>    Client Attester to provide them.  Such verification may prove
>    easier when the criteria against which the Client Instance was
>    evaluated (e.g. a reference to a Protection Profile or to a
>    Policy Identifier) are disclosed among the characteristics of the
>    Client Instance.  In this way, the Client Attester can be held
>    liable if the declared characteristics do not comply with the
>    criteria. *
>
> *Rational: This text paves the way for defining (elsewhere) a structure for the characteristics of the client instance
> that allows the Client Attester to be held liable if the declared characteristics do not comply with the criteria.
>
> Denis*
>
>
> This message starts a WG Last Call for:
> draft-ietf-oauth-attestation-based-client-auth-11
>
> This Working Group Last Call ends on 2026-09-22
>
> Abstract:
>    This specification defines an extension to the OAuth 2.0 protocol
>    (RFC 6749) that enables a client instance to include a key-bound
>    attestation when interacting with an Authorization Server or Resource
>    Server.  This mechanism allows a client instance to prove its
>    authenticity verified by a client attester without revealing its
>    target audience to that attester.  It may also serve as a mechanism
>    for client authentication as per OAuth 2.0.
>
> File can be retrieved from:https://www.ietf.org/archive/id/draft-ietf-oauth-attestation-based-client-auth-11.txt
>
> Please review and indicate your support or objection to proceed with the
> publication of this document by replying to this email keeping [e-mail]
> in copy. Objections should be explained and suggestions to resolve them are
> highly appreciated.
>
> Authors, and WG participants in general, are reminded of the Intellectual
> Property Rights (IPR) disclosure obligations described in BCP 79 [1].
> Appropriate IPR disclosures required for full conformance with the provisions
> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> Sanctions available for application to violators of IETF IPR Policy can be
> found at [3].
>
> Thank you.
>
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/
>
> The IETF datatracker status page for this Internet-Draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/
>
> There is also an HTML version available at:https://www.ietf.org/archive/id/draft-ietf-oauth-attestation-based-client-auth-11.html
>
> A diff from the previous version is available at:https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-attestation-based-client-auth-11
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>