Hi Paul,
These comments on draft-ietf-oauth-attestation-based-client-auth-08
detail my observations and comments
made during the virtual interim meeting held last Monday on 2026-05-04
from 17:00 to 18:00 UTC.
Since my comments 3 and 12 contain the acronym CBOR, I copy the Spice
mailing list
while this document does not contain any occurrence of that acronym.
*1.**The vocabulary used in this draft is still confusing*
*Introduction*
*Traditional OAuth security concepts perform client authentication
through a backend channel.*
The wording "backend channel" is not explained.
The term "backend" is confusing as the Figure indicates:
*+--------------------+ || |Client Attester | |(backend)| ||
+--------------------+***
In the ISO OBP, the single definition for the term "attester" is as follows:
attester : actor (person) who certifies and records legal responsibility
for a particular unit of information ISO 13606-1:2019, 3.1.1.
An Attester is someone who affirms or vouches for the correctness or
truth or genuineness of something.
Such a role is endorsed by a TTP (Trusted Third Party). However, the
acronym TPP does not appear anywhere in this draft.
The text continues with:
*This specification establishes a mechanism for a backend-attested client
authentication through a frontend channel to address these issues.*
The wording "frontend channel" is not explained and the word "frontend"
is used nowhere else in the draft.
However, using the terms "frontend" and "backend" makes sense for a
Client, but these terms would need to be defined
in section 3 (Terminology).
*
*
*2.**The draft should support "data origin authentication" instead of
"entity authentication"*
**In the Introduction, the step (6) is described as follows:
*(6) The Client Instance sends both the Client Attestation JWT and
the Client Attestation PoP JWT to the authorization server,
e.g. within a token request.
*This is insecure as :
* the token request is left unprotected,
* the Client Attestation JWT is left unprotected since it is not
signed by the Client Instance Key.
In order to allow an AS to verify the origin of a request rather than
only authenticating a client, the draft should support a "data origin
authentication service" instead of an "authentication service". See also
the following issue:
https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/159
that has been raised more than six months ago on Oct 16, 2025.
*3.**Terminology used in Section 3: Client Attestation JWT *
*Client Attestation JWT:A JSON Web Token (JWT) generated by the Client
Attester which is bound to a key managed by a Client Instance which can
then be used by the instance for client authentication. *The draft should first define a Client Attestation. A client attestation
can be encoded either using JSON or CBOR. At the conceptual level, the
encoding of a Client Attestation is irrelevant. In Token Status List
(TSLs), TSLs can be encoded using either JSON or CBOR. Why not do the
same in this document?
*4.**Model overview*
The terminology I propose is based on the following model:
***+--------------+ |Client| |Backend| |Attester| +--------------+ || ||
+--------------+ |Client| |Backend| +--------------+ || ||
+--------------++--------------+ |Client||| |Frontend|----------|AS|
|||| +--------------++--------------+ FIGURE 1: Model overview*
A Client Backend Attester delivers Client Backend Attestations to Client
Backends.
A Client Backend stores, protects and manages critical cryptographic key
materials. It communicates with a Client Frontend and possibly with a
Client Backend Attester.
A Client Frontend communicates with a Client Backend and with an AS, as
well as with other entities.
The following definition is proposed:
*Client Backend Attestation*: data generated by a Client Backend Attester
that describes some of
the characteristics of the Client Backend application,
including those of the OS/hardware supporting it, that contains a
public key which is associated with a private key stored and
protected within the Client Backend.
A Client Backend Attester is a TTP that certifies and bears
responsibility for the delivery of these attestations after the
examination of the characteristics of a Client Backend and how it is
managed.
Characteristics supported by a Client Backend are described using a
sequence of OIDs that can be defined under different name spaces.
*5.Terminology used in Section 3: Client Attestation Proof of Possession
(PoP) JWT
*
The next definition is:
*Client Attestation Proof of Possession (PoP) JWT:A Proof of
Possession generated by the Client Instance *
*using the key that the Client **Attestation JWT is bound to.*
The goal is NOT to authenticate the Client Backend but to know that some
data originates from a Client Backend.
When a client application is interacting with an AS, there are two goals:
(1) a first goal is to demonstrate to the AS that a request sent by
the Client Fronted to an AS is integrity protected using a private
key managed by the Client Backend.
(2) a second goal is to demonstrate to the AS that some key material
has be generated by a Client Backend (i.e., not by the Client
Frontend) that supports a set of characteristics that are attested
by a Client Backend Attester. Such characteristics are intended to
guaranty that the keys are correctly generated, kept in a secure
place and are only usable by a set of reliable applications. If the
Issuer trusts that Client Backend Attester, then it can be confident
that this set of characteristics is supported by that Client Backend.
The definition of a "*Client Attestation Proof of Possession
(PoP)"JWT*should be removed.
*6.Terminology used in Section 3: Client Instance
*
The next definition is:
*Client Instance:A deployed instance of a piece of client software.
*
This definition should be reconsidered as it does not explain its
relationship with the internal structure of the client.
It should be replaced by two definitions: Client Backend and Client
Frontend.
*Client Backend*: a part of a Client application that stores,
protects and manages critical cryptographic key materials.
It communicates with a Client Frontend and possibly with a Client
Backend Attester.
When a TEE (Trusted Execution Environment) is supported, a Client
Backend corresponds to a TA (Trusted Application) running in the TEE.
*Client Frontend*: a part of a Client application that communicates
with a Client Backend and with an AS, as well as with other entities.
When a TEE is supported, a Client Frontend corresponds to a UA
(Untrusted Application) running in the REE (Rich Execution Environment).
*7.Terminology used in Section 3: Client Instance Key
*
The next definition is:
*Client Instance Key:A cryptographic asymmetric key pair that is
generated by the Client Instance where the public key of the key
pair is provided to the Client Attester.This public key is then
encapsulated within the Client Attestation JWT and is utilized to
sign the Client Attestation Proof of Possession.
*
This definition is not appropriate as there are different ways to
install or generate such key pair.
For example, using an on-the-air (OTA) update of a smartphone, it is
possible to download into the mobile device such a key together with its
attestation.
This definition should be reconsidered.
*8.Terminology used in Section 3: Client Attester
*
The next definition is:
*Client Attester:An entity that authenticates a Client Instance and
attests it by issuing a Client Attestation JWT.
*
A Client Attester does not simply "authenticate" a Client Instance. It
attests some of its characteristics and makes sure
that a public key that is inserted into the client attestation
corresponds to a private key that is present in a protected part
of that client i.e, the Client Backend.
The following definition is proposed as a replacement:
*Client Backend Attester*:Trusted Third Party (TTP) that delivers
Client Backend Attestations to Client Backends after examination
of the characteristics and of the environment where a type of Client
Backend will be deployed. This TTP bears responsibility
when delivering Client Backend Attestations.
*9.Terminology used in Section 3: Challenge
*
The next definition is:
*Challenge:A String that is the input to a cryptographic challenge-
response pattern.This is traditionally called a nonce within OAuth.
*
This definition is technically correct but can be improved as it does
not state for what purpose the String will be used.
*Challenge:A String that is the input to a cryptographic challenge-
response pattern in order to be able to detect replay attacks.
Within OAuth, this is traditionally called a nonce.
*
IMPORTANT: The use of a challenge should be mandatory.
*10.About section 5: Relation to RATS
**
*RATS (RFC 9334) does not contain any definition for the term
"Attester". However, it contains the following sentence:
*In Remote ATtestation procedureS (RATS), one peer (the "Attester")
produces believable information about itself ("Evidence")
to enable a remote peer (the "Relying Party") to decide whether or
not to consider that Attester a trustworthy peer.*
RATS (RFC 9334) does not contain any definition for the term
"Attestation" either. The text is only using the wording "Attestation
Results".
The current draft states:
*The Remote Attestation Procedures (RATS) architecture defined by
[RFC9334] has some commonalities to this document.The flow
specified in this specification relates to the "Passport Model" in
RATS.
*In RATS, the Passport Model is described in section 5.1:
*The citizen retains control of the resulting passport document and
presents it to other entities *
*when it needs to assert a citizenship**or identity Claim, such as
at an airport immigration desk.*
**It is questionable whether this model applies, as the second paragraph
from section 5.1 states:
*Thus, in this immigration desk analogy, the citizen is the
Attester, (...)*
Can a citizen really be an Attester ? What about the Client ?
Section 4 (i.e., Relation to RATS) should be removed.
*11.About section 5: Client Attestation Format
*
The next section is : 5.Client Attestation Format
Before diving into the encoding, it would be useful to indicate the goal
of the Client Attestation and its relationship with a Client Attestation
Result.
Before that section, a new section should be added with a title like :
"*Goals and Architecture*".
Figure 2 (below) which is different from the Figure currently present on
page 4 should be used.
When making a request to the AS, two cases can be considered:
(a) the Client Frontend wishes to send a request to the AS and to
integrity protect it using a key stored and protected within the
Client Backend.
(b) the Client Frontend wishes to send a request to the AS that
contains, in addition, a set of cryptographic data (e.g., a set of
public keys)
and wishes to demonstrate that this set of keys has been
generated by the Client Backend.
A typical example is the request of a batch of digital credentials where
each issued digital credential contains one of these public keys.
When the AS receives these public keys, it can know the characteristics
supported by the Client Backend and then can decide whether
they match with one of its issuing digital credential policies.
How can this be modelled ?
The Client Frontend instructs its Client Backend what to do. This will
be done by locally communicating:
- a command to the Client Backend and
- a set of parameters appropriate for that command.
This is usually done using an API.
Commands sent to the Client Backend will have the following structure;
- a command XYZ sent to the Client Backend,
- a challenge that has been previously requested to the AS by
the Client Frontend and
- a hash value of the request that the Client Frontend wishes
to send to the AS.
An example of such a command XYZ sent to an AS can be:
" generate a batch of four public keys according to the algorithm Y
using the set of parameters Z and return these public keys (as
authenticated data)
within the Attestation Result and an index for each of them in
the response to the command ".
It is now possible to take a look at Figure 2 below:
*
+--------------+
|Client|
|Backend|
|Attester|
+--------------+
|Out of|
|scope|
+--------------+
|Client|
|backend|
+--------------+
/ \|
(4)||(5)
command||response to the command
+||+ Attestation Result =
challenge||all signed under a Client Backend private key:
+||(challenge + hash value of the request
hash value||+ Client Backend Attestation
of a request ||+ authenticated data (optional))
|\ /
+---------------++---------------+
||challenge request (1)||
||------------------------>||
||challenge(2)||
|Client|<------------------------| Authorization |
|frontend|request|Server|
|(3)|+||
||Attestation Result||
||------------------------>||
+---------------+(6)+---------------+
FIGURE 2: Architecture and data flows overview
*Out of the scope of this document:How the Client Backend got or
generated a private key and obtained,
from a Client Backend Attester, a Client Backend Attestation for the
corresponding public key
where that attestation includes a set of characteristics supported by
the Client Backend.
(1) The Client Frontend requests a challenge to the AS
(2) The AS sends back a challenge to the Client frontend
(3) The Client Frontend locally constructs a request that will be
sent later on to the AS and computes a hash of this request
(4) The Client Frontend communicates to the Client Backend and
constructs a message composed of a command, the challenge and the
hash of the request.
(5) the Client Backend returns to the Client Frontend a response to
the command intended to be processed by the Client Frontend and an
Attestation Result
that contains up to four data elements, all signed under a
private key of the Client Backend:
(a) the challenge,
(b) the hash value of the request,
(c) a client backend Attestation and
(d) optionally, authenticated data generated by the Client
Backend intended to be processed by the AS.
An example of "authenticated data generated by the Client Backend"
is a set of public keys where each public key is intended to be
included into soon-to-be-issued digital credentials.
(6) the Client Frontend sends to the AS both a request (e.g. a token
request) and the Attestation Result.
*12.About section 5 (Client Attestation Format) *The text states:*The Client Attestation MUST be encoded as a "JSON Web
Token (JWT)" according to [RFC7519]. *This is debatable. If used in a CBOR context, why should client backend
attestations be only JSON encoded ?*13. About the field "sub" and the
unlinkability property between RSs ***sub: REQUIRED.The sub (subject)
claim MUST specify client_id value of the OAuth Client. *Since the header of the JWT shall include a "sub (subject) claim that
MUST specify client_id value of the OAuth Client", if this protocol is
used towards a RS, the unlinkability property between RSs cannot be
supported.. If this protocol is maintained with a RS, it should be
clearly advertised that the unlinkability property between RSs cannot be
supported. In that case, a "Privacy Considerations" section should be
added to warn implementers. Using a transitive trust model, it is
possible to communicate to a RS a set of characteristics supported by
the Client Backend
while supporting the unlinkability property between RSs in the following way:
At the time a token request is received by an AS, the AS can know a
set of characteristics supported by the Client Backend.
If that set of characteristics is adequate according to the issuance
policy of a given type of token, then the AS can include a subset of
thatset of characteristics into the issued token (e.g., into a
digital credential) but SHALL NOT include the "sub" field that is
present in the Client Backend Attestation, as it would allow to
identify a particular Client Backend.
In this way, the unlinkability property between RSs can be supported and
a protocol between the AS and the RS can be avoided.
*14.About the field "exp"
**
*exp: REQUIRED.The exp (expiration time) claim MUST specify the
time at which the Client Attestation is considered expired by its issuer.*
Since a Client Backend Attestation shall include an expiration time
field, the document should include a section to deal with
the suspension and the revocation of Client Backend Attestations.
It should be noticed that, in the proposal, the digital signature made
using a private key of the Client Backend also protects the Client
Backend Attestation.
This is necessary because the Client Backend Attestation needs to know
which one has been used. Suspension or revocation apply to a Client
Backend Attestation
and not to the public key it contains.
After the end of a suspension, it is not necessary to change the key
pair.After a revocation, depending about the revocation reason, it
may not be necessary to change the key pair.
*15.About the most important missing field and "other claims"
* The text mentions:
*The following additional rules apply:
1.The JWT MAY contain other claims.*
A field that enumerates a set of characteristics supported by the Client
Backend is missing. Such field should contain a set of OIDs.
Saying "*The JWT MAY contain other claims*" is insufficient, as it would
not permit any kind of interoperability and would miss one major goal of
this document.
*16.About the title
*
The title of this draft is:*OAuth 2.0 Attestation-Based Client
Authentication*
******
Given the previous comments, it would be more appropriate to rename it:*
*
***OAuth 2.0 Attestation-Based ClientData Origin Authentication*
*17. About the abstract
*
The wording "or Resource Server" should be removed from the abstract.
Taking into account the previous comment, the following abstract is
proposed:
This specification defines an extension to the OAuth 2.0 protocol
[RFC6749] that enables a client instance to send to an Authorization
Server
messages integrity-protected using an attestation bound to a Client
Backend.
*18. Considering the following individual draft issued on May 5, 2026
and recently advertised on the saag mailing list
*
*Post-Session Execution Assurance (PSEA): A Security Model for Verifying
Authority at the Moment of Action (draft-yossif-psea-01)
**
*I noticed the following statement in the Security considerations section:
*Implementations SHOULD use platform-attested hardware-backed key
storage (such as Trusted Execution Environments) to bound this risk.
*
This observation is appropriate. A non-normative example about digital
credential wallets supported by a TEE would be great.
END OF COMMENTS
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.
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".
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...).
+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 [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
