Denis,
Thanks for the careful read of draft-yossif-psea-01 — I'll address only your
point 18 here, as the rest concerns a separate draft.
Agreed on the value of a non-normative example for TEE-backed digital
credential wallets. The intent of the SHOULD on hardware-backed key storage was
exactly the wallet deployment model — Secure Enclave / StrongBox holding the
signing key, with the per-action PSEA evidence produced inside the trust anchor
and the surrounding application unable to forge it.
I'll add a concrete example along these lines to the Security Considerations
section in -02, covering both the iOS (Secure Enclave + App Attest) and Android
(StrongBox + Key Attestation) cases, and noting how this composes with platform
attestation to give the Relying Party a chain from device trust to per-action
authority.
If you have a preferred framing for the wallet example — particularly with
respect to EUDI / SD-JWT VC deployment contexts — happy to incorporate it.
Best,
[Mohamad Khalil Yossif, Founder & CEO of Yuthent]
Mohamad Khalil Yossif
Founder & CEO · Yuthent
PSEA Spec Author · IETF draft-yossif-psea
[Yuthent — Execution Authority Infrastructure]
T: +972 50-931-1103 [tel:+972509311103]
E: [email protected] [mailto:[email protected]]
W: yuthent.com [https://yuthent.com] [LinkedIn]
[https://www.linkedin.com/in/mohamadkhalilyossif]
[Yuthent — Cryptographic proof of human authorization at execution time]
[https://yuthent.com]
This email may contain confidential or sensitive information. If you are not
the intended recipient, any review, use, disclosure, distribution, or copying
is prohibited. If you received this message in error, please delete it
immediately.
On 11/05/2026 10:27:37, Denis <[email protected]> wrote:
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
[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 that set 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 Client Data 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]
[mailto:[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/
[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
[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
[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
[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
[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
[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] [mailto:[email protected]]
To unsubscribe send an email to [email protected]
[mailto:[email protected]]
_______________________________________________ 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]
