*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 [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]
To unsubscribe send an email [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
