Hi Denis, Thanks for the Feedback, we’ve gone through your comments and will be creating a small PR to address some of the concerns.
Comments for each Feedback: > (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. The draft keeps the payload / data of the client attestation rather generic - that is by choice. Other documents Should profile this specification and add additional claims depending on their specific use-cases and requirements. Revocation is such a case, where we have different mechanisms to deal with that in OAuth land, but it heavily depends on the deployment and context (and freshness requirements), so adding generic text doesn’t seem like a good idea. Instead other work that depends on this specification should tailor those things as they need - as is already happening for example in the context of digital wallets. Also check section 10.2 and exp for the short-lived option and exp is a required parameter. We can add a clarifying Sentence that status management is outside of scope of this document, but I’d not want to change scope. > (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) The client assessment part is already part of the statements above the quoted one: the authenticity and integrity of the Client Instance (this might encompass statements about its software and hardware environment) We believe that list of points can be improved - we’ll propose a small fix in a PR. > (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". Happy to add characteristics to the list, but we would like to keep the other attributes, especially integrity. Will propose a merged wording in a follow-up PR. > (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. client_id is well established in OAuth and we thought it requires no further explanation, but we can add it to Terminology if that helps. We can add the reference to section 7.5 for the check to avoid confusion. > (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. client_id is the client software, not a client instance in OAuth (see previous discussions at IETF & interim meetings - that means it is identical for all client instances). The “default” way client_id and in this case sub works would create identical entries and would not create likability for instances -> for the management of a specific client instance, something additional needs to be defined (especially if used across different AS). This also seems to go back to the general question about revocation which was already discussed in point 1. For the privacy part: Our proposal would be to add temporal claims (iat, exp) to privacy considerations as correlation factors to consider. > (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. > What you are describing is an Access Token and the core mechanism of OAuth? Cient attestations usage at RS does not replace access tokens, is optional and can be used as an additional security signal (with sufficient freshness) to guarantee the state of the client instance at the time of the request. > (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. Liability is outside of the scope of this document. We already say that profiles may define the type and additional claims. Additional claims in a Client Attestation JWT are assertions of the Client Attester and can be added as such. Servers should rely on them only to the extent the Attester is trusted for such statements (see 7.1, rule 4 - “known and trusted Client Attesters”). We’ve opened an issue reflecting the comments and will create a PR with the aforementioned fixes. Best Regards, Christian > On 10. Sep 2026, at 08:21, Denis <[email protected]> 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 >> [email protected] <mailto:[email protected]> >> 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 -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > > _______________________________________________ > 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]
