Received: from mail-ua2-x0f.google.com (mail-ua2-x0f.google.com [IPv6:2a00:1450:4864:39::f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id E882B30 for ; Fri, 18 Sep 2026 12:18:12 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=idura.eu header.s=google header.b=OUXKHq2m; arc=pass ("google.com:s=arc-20260327:i=1"); dmarc=pass (policy=reject) header.from=idura.eu; spf=pass (mx.ietf.org: domain of frederik.krogsdal@idura.eu designates 2a00:1450:4864:39::f as permitted sender) smtp.mailfrom=frederik.krogsdal@idura.eu Received: by mail-ua2-x0f.google.com with SMTP id a1e0cc1a2514c-98296941f99so272148241.3 for ; Fri, 18 Sep 2026 05:18:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1789733886; cv=none; d=google.com; s=arc-20260327; b=NGo6tBTSIY0RJO1pSPqYgN1tt1SZH6Eh2scW8FMGkM9SlF/R/ULnngjCzuAw0aAGMi LZ9Ni1jrO/igjq8UHs+x+tlPvjLbMpT/XL5meZuMX8SJ5kDcVa76gipLxjGedkCnarcQ /Zh+nMzRpEJ1oo7fY3/YmCwVe1IvL4yWLnSt39PcKgeuybsd9SCDRTusDDgspXW3T1xn MjhVIUxBR2Yzq/6P/J171gyjD1TZ7eppeE5DLgDjKSour7wNmXoFi4+FEnNainafpXY1 Rc9n4sIOsydcj5XhEundfgi66/A691fe4hIVwg5RP2l91eciuJghA6mYxGsV74PvrqFg KuUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=gzfa5eVYT0hu0c74Ubw1XAMlEiwwi2uK5tzwPs8V5cg=; fh=PQ5JoHWam/40y9QgVlZ1vuJGGmeKJgTFZqGLZHJ3XHw=; b=bbSHWzIY7E807GrmNdBh7LIkmY2/bsCodOGYrNFxO06uxLsQIvwDqsfc+KiZFOe1sW hKIBPKgpTW7WY40vqS97KGzxOffrP4m9rITtbk0Cj8eY9Uj52uElmaK9sNpkPRujYxFe dtYlvmG+m932OUsC9mZRZUxHC9UUNNFuDU8aNoIOThrWUFpuit+Dd2boM89kmrAQLPVy 5r6fiDOQOEA5pRfuxC0fRUXffZA0SjLfZfr/izzkQU5ATdv2cVROlIdoliGD2VPIDFLm /uPnawuStvB4Cg5j3dK6+NvwLVQydgCxfVZFqPT0h1zIE9oyd9xzX944DpSjviaxCvfN X4qA==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=idura.eu; s=google; t=1789733886; x=1790338686; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=gzfa5eVYT0hu0c74Ubw1XAMlEiwwi2uK5tzwPs8V5cg=; b=OUXKHq2mE7UDR42BQVa7YgllFpsR7k4vEPxOeHfBt/y8v6ARng6pHLEQ/b0bzR9S46 5sTWO4vTdFz6ARPFXdo2gyW46aU7UXgD4OOxq9O0fLTb7I7d5I85m+/DWlEijt5JDOH8 lubIE4SorKHYSJrPjrL790N+mYr+kZI1v8myFxPfRMDoo9EbG/DD8bOpV/c1DPMf4otP klq1HoOiynu0OnMu2Jgub92087cpd5TblvcYT7QHBY6nQbOrFy9gKovoJfy+NTknf3OQ HCIkDVkbutQs8ZnzmgUvPUa4/H09sLmYIKeV5e1ZBqprZrL2GoKdxqbEe4fls9PVoFOS /tgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789733886; x=1790338686; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=gzfa5eVYT0hu0c74Ubw1XAMlEiwwi2uK5tzwPs8V5cg=; b=PFUzl4m80LPVQKKbRzCv9NspFvKpbnmcNNTEzfpnfj87qk3aLpH+Mj7MNxJlfsjrZr r5rkm0/5x/snc5bXiUzzT9vw+6vCxvpDWDv2fhSzu0os1Q0rpg3ZFVGX/IhYga/PxT/b gF7n6L9Ol8eHgWf196FO/AMVkq7Z+Q2kH+KJJcvO2U5Nmskt7bJAxgqxkmcKO+nYw7kt ChdHhPPdzBhQIzNOglXT+/Et1SgSL3iwy21F8Fxa54dID4GiSLGIM/NbrCPXyAzo/HvA F/PUbW5ExKKvGAN1q0LUpLikWS5Idal+l0COj8bjhIq5EsGuj922dkgNGexs/2C9ttUR TNtQ== X-Forwarded-Encrypted: i=1; AKwUvBz4nErslFEBMBTFszO6UkLvyIoaPeE9BjH4g/d92eAuPteaNZQpyA7TUqQwgs8Lh4NujW+MiA==@ietf.org X-Gm-Message-State: AFuF++nwUICokusHmeiCOGjiEe1OlduGOj8Lfdfcy/sDHDocR3yF34qp VR/13Zqd+kN+O9FobV81HMSmA9EjlAXpnEF2ZZmoUAe6g0wKE7d2KOrAMBDYlfa9xbKt2pmbwdU V6xXpeX8eJnoJfwVkjWddgZf5MoJq4vw3DLbTA+9H4g== X-Gm-Gg: AYBFou0Iy4VAAJn8OrVi7tWAVpNAVRc3/hXZhCThXdOT9l6hfD9TPsrPrKtEKr+0OnH lAqgwvCNR0oOZ+PA/5OoXukZF61Nboy34SYLjvNH00DC2EcSvv9kJtxPkAWKgxvu0kVHZD+8fcj ZwOguSYx8Z3slhJxivQIj64JLawaeYXTAx/GieCwNOTKTvsRYKXDbVheLJWDKOPREcKsaY+vOhT iRZMxlMlGOlrasEcrJ1+1+03wq9JJU00BK/STAl0B3Wr9tOzglhP2/AbA6YkmhSSx1FaSuGq2Uh mEZZfoVrjWFXTwxO13oTUdqI5DaULBLpewHfB5BALX0NTUA2rtz+sta19A== X-Received: by 2002:a05:6102:cd1:b0:79b:b6c5:71b6 with SMTP id ada2fe7eead31-7a55a72b59fmr987912137.3.1789733886152; Fri, 18 Sep 2026 05:18:06 -0700 (PDT) MIME-Version: 1.0 References: <178886938188.868253.13306592686277230637@dt-datatracker-9769b79f-xztnc> <067b9a5e-0eb8-43d4-99ee-e216d40ab13f@free.fr> In-Reply-To: <067b9a5e-0eb8-43d4-99ee-e216d40ab13f@free.fr> From: Frederik Krogsdal Jacobsen Date: Fri, 18 Sep 2026 14:17:55 +0200 X-Gm-Features: AcwNN1XQE0g-3YIPDrvtPTNbP_VEQhaxChtsTDIcjydQ1de8vmPWeul_g65Z2EU Message-ID: To: Denis Content-Type: multipart/alternative; boundary="00000000000086e2e4065bc0e40e" X-Spamd-Bar: -- Message-ID-Hash: XRTKQGU23ZCIFDWI55UC4XKUSSL4ZWPY X-Message-ID-Hash: XRTKQGU23ZCIFDWI55UC4XKUSSL4ZWPY X-MailFrom: frederik.krogsdal@idura.eu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-oauth.ietf.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: draft-ietf-oauth-attestation-based-client-auth@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org X-Mailman-Version: 3.3.10 Precedence: list Subject: [OAUTH-WG] Re: WG Last Call: draft-ietf-oauth-attestation-based-client-auth-11 (Ends 2026-09-22) List-Id: OAUTH WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000086e2e4065bc0e40e Content-Type: text/plain; charset="UTF-8" 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 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 oauth@ietf.org > 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 -- oauth@ietf.org > To unsubscribe send an email to oauth-leave@ietf.org > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-leave@ietf.org > --00000000000086e2e4065bc0e40e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support publication of this document.
I have impleme= nted the newest draft version (without the DPoP combined mode) and have pla= ns to use it in production deployments.

Some comme= nts based on my implementation experience:
- As written, the spec= does not normatively require replay protection for PoPs to actually be imp= lemented by the verifier. Is this intentional?
- Even though trus= t management is explicitly out of scope, I think there should be a normativ= e statement that an AS which trusts multiple attesters must somehow scope t= he 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&= quot; to "combined" by removing the PoP header. The severity of t= his is probably pretty limited, but it feels fragile to signal combined mod= e only by the absence of the OAuth-Client-Attestation-PoP header.
- I think iat should be REQUIRED. Otherwise, the AS cannot actually determ= ine how fresh an attestation is, and has to exclusively rely on the exp fro= m the attester which the AS does not control.
- I didn't impl= ement combined mode, but I think that there should be a line explicitly say= ing that a server implementing combined mode SHOULD also provide DPoP nonce= s (which are optional in RFC 9449).
- The text is not currently c= lear on the fact that a client instance needs to remember which client inst= ance key each instance-bound protocol artifact (i.e. refresh tokens)=C2=A0i= s actually bound to. If it doesn't do this, changing client instance ke= ys will result in bad user experiences (potentially unbounded retries). Usu= ally the client instance key rotation is not the choice of the client insta= nce, but is something the platform does for your e.g. when biometrics are r= eset/updated, so this is something that will happen to most implementations= . Guidance would be helpful.
- It would be helpful for interopera= bility to define the status codes that should be used for use_fresh_attesta= tion and invalid_client_attestation errors.
- I disagree with Den= is' 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 Deni= s' comment #2, I think the current text is clear enough and that the pr= oposed text introduces unnecessary redundancy.
- I disagree with = Denis' comment #5 about sub correlation. The sub generally identifies t= he 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 agr= ee in principle with Denis' comment #7 about trust in additionally atte= sted claims, though I think the framing about liability is inappropriate in= an IETF document.

Nits (line numbers in .txt vers= ion linked in Rifaat's message):
- Heading capitalization see= ms 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 wr= itten as steps. The sentence should probably be rewritten to match the &quo= t;conditions and rules" framing in section 7.2.
- The &= quot;applications using this media type" field in the IANA registratio= n for=C2=A0oauth-client-attestation-pop+jwt looks wrong. I would ex= pect it to say something like "applications that use this spec to conv= ey a client attestation with PoP" but the text currently mentions toke= n status information.
- The document history for v= ersion 11 has a duplicate bullet about removing the duplication challenge v= erification.
- Section 10.5 mentions size limits &= quot;as of 2024" which should probably be updated to the current limit= s.
- The HTTP syntax uses token68 which I think is= supposed to be deprecated (see section 16.4.2 of RFC 9110). I'm also n= ot sure it is compatible with defining the HTTP field types as "Item&q= uot;.
- Line 753 says "an use_attestation_chall= enge" instead of "a use_attestation_challenge"
- L= ine 830 says "a HTTP header-based" instead of "an HTTP heade= r-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"<= /div>
- 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
- Lin= e 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, Den= is <denis.ietf=3D40free.fr@d= marc.ietf.org> wrote:
=20 =20 =20 
Seven comments on draft-ietf-oauth-attestation-based-c=
lient-auth-11=20

(1) General. The draft does not address in section 4 or elsewhere the suspe=
nsion or the revocation=20
    of a Client Attestation JWT.  This important consideration should be ad=
ded into the draft.=20

(2) Page 6. Section 1.1 (Data Flow).

Change: 

=C2=A0=C2=A0 *=C2=A0 optiona=
lly, properties of that key (e.g., that it was securely
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generated or resides in hardwar=
e-backed storage) 
into: 
=C2=A0=C2=A0=C2=A0*=C2=A0 op=
tionally, characteristics of the Client Instance (e.g.,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the criteria against which=
 the Client Instance has been assessed=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0and in particular the prot=
ection of keys managed by the Client=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Instance, as well as the p=
rotection aimed at limiting the use=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0of these keys to that Clie=
nt Instance)

Rational: The field is renamed from "properties of that key" to "cha= racteristics 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). =C2=A0

Change: 

=C2=A0=C2=A0 Client Attestation JWT:=C2=A0 A JSON Web Token (JWT) generated by the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Client Attester that attests to=
 the authenticity of a Client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Instance and is cryptographical=
ly bound to a key managed by that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Client Instance.=C2=A0 A Client Attestation JWT may additionally convey
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 information about the integrity=
 or state of the Client Instance. 
into: 
=C2=A0=C2=A0=C2=A0Client Attestation JWT:=
=C2=A0 A JSON Web Token (JWT) generated by the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Client Attester that attests to=
 the authenticity of a Client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Instance and is cryptographical=
ly bound to a key managed by that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Client Instance.=C2=A0 A Client Attestation JWT may additionally=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0convey information about t=
he characteristics of the Client=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Instance. 
Rational: The second sentence is changed to use the wo=
rds "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:=20

   7.  If a client_id is provided in the request con=
taining the Client
       Attestation, then this client_id matches the sub claim of=
 the
       Client Attestation JWT, unless specified otherwise by a p=
rofile
       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=20
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=20
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 Attesta=
tion JWT.=20
If the 'sub' field is made OPTIONAL, then tracking Client Instance =
JWTs across Authorization Servers=20
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 acr=
oss Authorization Servers,=20
but not across Resource Servers.

In this way, Authorization Servers will be able to ask for the revocation o=
f one or more Client Attestation JWTs=20
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 Serve=
r and hence there will not be a tracking problem=20
across Authorization Servers.

Some text should be added to address this issue.


(6) Page 30. Section 11.1 (Client Instance Tracking Across Authorization Se=
rvers or Resource Servers)

Whatever solution will be described to address the previous issue, the foll=
owing text addition is proposed:

=C2=A0=C2=A0=C2=A0In certain deployment scenarios, the number =
of Resource Servers
=C2=A0=C2=A0=C2=A0can be quite large compared to the number of=
 Authorization Servers.
=C2=A0=C2=A0=C2=A0In such a case, instead of supporting this p=
rotocol between a=20
=C2=A0=C2=A0=C2=A0Client Instance and a Resource Server, an al=
ternative approach=20
=C2=A0=C2=A0=C2=A0can be used that allo=
ws to limit the number of Client Attestation=20
   JWTs with different Client Instance Keys.

=C2=A0=C2=A0 At step (7), when the Client Instance accesses a protected resource,
=C2=A0=C2=A0 it may present a security token either directly issued by an
=C2=A0=C2=A0 Authorization Server or derived by the Client Instance from data
=C2=A0=C2=A0 issued by an Authorization Server.=C2=A0 The Authorization Server
=C2=A0=C2=A0 can include into the issued data the characteristics of the Client
=C2=A0=C2=A0 Instance.=C2=A0 In this way, since the Resource Server trusts the
=C2=A0=C2=A0 Authorization Server, it can rely on the Client Instance
=C2=A0=C2=A0 characteristics contained in the security token.=C2=A0 This is a =C2=A0=C2=A0 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: =C2=A0

12.3 Characteristics of the Client Instance 
=C2=A0=C2=A0=C2=A0In a Client Attestation=
 JWT, the characteristics of the Client=20
=C2=A0=C2=A0=C2=A0Instance are optional.=C2=A0 Wh=
en they are included in it, before=20
=C2=A0=C2=A0=C2=A0accepting or validating these characteristic=
s, the Authorization
=C2=A0=C2=A0=C2=A0Server (or the Resource Server) must verify =
that it can trust the
=C2=A0=C2=A0 Client Attester to provide them.=C2=A0 Such verification may prove
=C2=A0=C2=A0=C2=A0easier when the criteria against which the C=
lient Instance was
=C2=A0=C2=A0=C2=A0evaluated (e.g. a reference to a Protection =
Profile or to a=20
=C2=A0=C2=A0=C2=A0Policy Identifier) are disclosed among the c=
haracteristics of the=20
=C2=A0=C2=A0=C2=A0Client Instance.=C2=A0 In this =
way, the Client Attester can be held=20
=C2=A0=C2=A0=C2=A0liable if the declared characteristics do no=
t comply with the=20
=C2=A0=C2=A0=C2=A0criteria. 
Rational: This text paves the way for defining (elsewh=
ere) a structure for the characteristics of the client instance=20
that allows the Client Attester to be held liable if the declared character=
istics 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/dr=
aft-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 oauth@ietf.org
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 provisio=
ns
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] h=
ttps://datatracker.ietf.org/doc/bcp78/
[2] h=
ttps://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/d=
raft-ietf-oauth-attestation-based-client-auth-11.html

A diff from the previous version is available at:
https://author-tools.ietf.=
org/iddiff?url2=3Ddraft-ietf-oauth-attestation-based-client-auth-11

_______________________________________________
OAuth mailing list -- o=
auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org


_______________________________________________
OAuth mailing list -- o= auth@ietf.org
To unsubscribe send an email to oauth-leave@ietf.org
--00000000000086e2e4065bc0e40e--