JWTs issued for one individual must not be usable by another individual with a complicity between these individuals

[Denisthemalice]

The title of this document is JSON Web Token Best Current Practices. Its goal is "to provide actionable guidance leading to secure implementation and deployment of JWTs" and "to facilitate secure implementation and deployment of JWTs" (Introduction).

Section 2 (Threats and Vulnerabilities) lists some known and possible problems with JWT implementations and deployments.

Section 2.7 (Substitution Attacks) states:

There are attacks in which one recipient will be given a JWT that was intended for it and will attempt to use it at a different recipient for which that JWT was not intended.

This relates to the audience of the JWT.

Section 2.8 (Cross-JWT Confusion) states:

As JWTs are being used by more different protocols in diverse application areas, it becomes increasingly important to prevent cases of JWT tokens that have been issued for one purpose being subverted and used for another.

The concept of "purpose" is inexistent in JWT-SD and would need to be clarified.

This draft is concentrating on the structure of JWTs, but is ignoring the context in which JWTs are requested, obtained and then used.

SD-JWTs defined SD-JWTs formats for two flows:

 a) when an issuer issues a SD-JWT including all Disclosures,
 b) when a verifier presents SD-JWT or SD-JWT+KB including selected Disclosures.

However, SD-JWT does not define which protocols can be used to carry these data formats.

Hence, threats and vulnerabilities that can arise in these protocols are not considered, nor addressed.
This means that the current content of this draft while explicit targeted to "Developers of specifications that rely on JWTs,
both inside and outside the IETF" is incomplete.

Two important "specifications that rely on JWTs outside the IETF" are:

"OID4VCI": OpenID for Verifiable Credential Issuance - draft 16
https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html

"OID4VP": "OpenID for Verifiable Presentations 1.0" which defines a protocol for requesting and presenting Credentials (published on 9 July 2025). It defines a mechanism on top of OAuth 2.0 to allow presentation of claims in the form of Verifiable Credentials as part of the protocol flow. https://openid.net/specs/openid-4-verifiable-presentations-1_0.html

These two OpenID specifications contain many optional features. This makes difficult for implementers to select a right combination that allows to develop a secure implementation.

When using selective disclosure of claims, it is important to prevent cases where JWTs issued for one individual would be usable by another individual with a complicity between these individuals. In some cases, this issue is identified as a "relay attack".

This issue has not been identified in the documents produced by the OAuth WG (nor the SPICE WG), nor in OID4VP.

OID4VP defines protocols for requesting and presenting Credentials. It is not explicitly said that these protocols must be supported by a single application and that the end-user using the device supporting that application SHALL NOT be able to modify it or to use its "key store" by downloading a rogue application and then using these keys with it.

Once this issue is identified, it needs to be addressed in a section called "implementation considerations" which, unfortunately, is inexistent in the proposed draft.

This topic is highly dependent upon the type of the device, however, general considerations apply.

[dickhardt]

@Denisthemalice

However, SD-JWT does not define which protocols can be used to carry these data formats.

Hence, threats and vulnerabilities that can arise in these protocols are not considered, nor addressed.
This means that the current content of this draft while explicit targeted to "Developers of specifications that rely on JWTs,
both inside and outside the IETF" is incomplete.

What specifically are you suggesting should be added to the JWT BCP? I participated in SD-JWT and provided guidance on JWT best practices to be included in SD-JWT. What did we miss?

These two OpenID specifications contain many optional features. This makes difficult for implementers to select a right combination that allows to develop a secure implementation.

Are you suggested we provide advice no not including optional features? While I agree there may be challenges in "many optional features", that is decision that looks out of scope as a best practice as it is dependent on the use cases a specification is trying to solve and "many optional features" may be the right choice. Do you have suggested text to make the discussion more concrete?

[dickhardt]

@Denisthemalice checking in you saw this -- we will close if we don't receive additional context

[Denisthemalice]

The key point is making sure that the private keys that are generated by the Holder application are used "appropriately" by a "trusted " Holder application. These private keys are used by two different protocols:

a) by an Holder - Issuer protocol before the user requests a SD-JWT to an Issuer and
b) by an Holder - Issuer protocol when the user presents some claims contained in a SD-JWT to a Verifier.

The same Holder application shall be used for implementing these two protocols.

The security characteristics of the "trusted" application should be known : (a) by the Issuer but also (b) by the Verifier.
The EUDIW is using the concept of a "wallet attestation".

Wallet attestations can be verified using a set of trust anchors and a set of PKCs.

The owner of the device that supports the Holder application should not be able to modify that trusted application or to replace it by another application. In practice, this means that the device should not be rooted or jailed-broken, or if it has been rooted or jailed broken, the trusted Holder application should immediately cease to operate.

This the top of the iceberg for implementations considerations.

When the Holder application presents a public key that will later be included into a SD-JWT, that Holder application should present to the Issuer an "Holder application attestation" that allows the Issuer to know the characteristics of the Holder application. The Holder application should also demonstrate the knowledge of the private key corresponding to the public key included into the Holder application attestation.

Some protocols make that this feature optional. When it is optional, no guarantee can be obtained about the characteristics of the Holder application.

For the protocol b) that is used in the context of the Holder - Issuer protocol, two options are possible:

1. take advantage of the fact that the Issuer can know the characteristics of the Holder application and once it has verified them, they can be included into a claim within the SD-JWT. Unfortunately at this moment, no claim has yet been requested to IANA to include them. A best practice should be to include them into a SD-JWT. This approach supports the concept of a transitive trust: If the Issuer can be trusted by the Verifier to verify the characteristics of the Holder application, then the Verifier can use this claim when it is present.

2. implement an additional protocol between the Holder application and the Verifier that allows the Verifier to know the characteristics of the Holder application. However, privacy considerations should be considered to prevent Verifiers to link Holder applications using Holder application attestations. This would be far more complicated than the first option. While the second option should be mentioned, it should be deprecated.

If we draw a parallel between X.509 certificates and SD-JWTs, X.509 certificates can include CertificatePolicies.
SD-JWTs should be able to include IssuerPolicies.

At this moment, we are not yet at the end of the story.

SD-JWTs can be used in an on-line mode or in a proximity mode. For the moment, let us only consider an on-line mode involving an interaction with a web browser.

In the same way that only trusted Holder applications should be used, only trusted browsers applications should be used by trusted Holder applications. The trusted Holder applications should verify that it is in fact the case.

When the device is a smart phone, considerations should also be given about the use of the TEEs, not only for the protection of the private keys but also for their use by appropriate trusted Holder applications.

If we want to securely deploy SD-JWTs, these best practices are currently missing and should be considered.

[dickhardt]

@Denisthemalice am I understanding you correctly that you are proposing that the JWT BCP include language about the management of SD-JWT private keys?

[Denisthemalice]

No. It is more than simply the management of the private keys.

It is about the management of the private keys by an Holder application that runs on a device. Which trust relationships should there be between a web browser application and an Holder application ? Which parts of the Holder application should run in the RichOS and in the TEE ? What about the security characteristics of the RichOS and of the TEE ?

[dickhardt]

Which trust relationships should there be between a web browser application and an Holder application ? Which parts of the Holder application should run in the RichOS and in the TEE ? What about the security characteristics of the RichOS and of the TEE ?

A best current practice does not create new practices -- it pull together practices that have been proven to be the best practices.

What best practice are you suggesting would address the concerns you are raising?

[Denisthemalice]

The key point is that no "best practice" has currently been recommended to address this concern.

If this concern is not addressed, this will leave unsolved a major security concern which needs to be addressed when selective disclosure of claims is supported and the user cannot be uniquely identified.

A sketch of the beginning of best practices is detailed in the previous comments.

[dickhardt]

I appreciate your desire to help secure deployments, but the BCP is a collection of existing, accepted practices that have been developed from experience and proven threats. Prescribing a speculative practice is not in our scope.

[Denisthemalice]

draft-ietf-oauth-rfc8725bis-00 states:

(...)

2. Threats and Vulnerabilities

This section lists some known and possible problems with JWT
implementations and deployments.

 2.1.  Weak Signatures and Insufficient Signature Validation 
 2.2.  Weak Symmetric Keys 
 2.3.  Incorrect Use and Composition of Encryption and Signature
 2.4.  Plaintext Leakage through Analysis of Ciphertext Length
 2.5.  Insecure Use of Elliptic Curve Encryption
 2.6.  Multiplicity of JSON Encodings
 2.7.  Substitution Attacks
 2.8.  Cross-JWT Confusion
 2.9.  Indirect Attacks on the Server
 2.10. Computation Cost of Unreasonable Number of Hash Iterations
 2.11. Algorithm Verification Code Not Defensively Written
 2.12. JWE Decompression Bomb Attack
 2.13. JWT Format Confusion

The threat I mentioned is not listed in any of these sections.

The threat has been identified more than two years ago under the following title: Security of Trusty OS (TEE) Non-Secure World API.
https://security.stackexchange.com/questions/269155/security-of-trusty-os-tee-non-secure-world-api

The question raised were the following:

How can the trusted application make sure that only selected applications from the Non-Secure World can access the port?

Is there even a way how a trusted application can securely determine which application from the Non-Secure World connected to it?

If a rogue application can be installed by the owner of a device and use the keys that should normally only be used by a specific trusted application, then another individual can take benefit of the cryptographic results produced by the TEE.

There are several ways to name that threat. For the time being, I have identified it under the following wording :
" JWTs issued for one individual must not be usable by another individual with a complicity between these individuals".

This threat is particularly relevant when selective disclosure of claims is supported and the user cannot be uniquely identified.

draft-ietf-oauth-rfc8725bis-00 states:

This BCP specification furthermore replaces the existing JWT BCP
specification RFC 8725 to provide additional actionable guidance
covering threats and attacks that have been discovered since RFC 8725
was published.

(...)

The goal of this document is to facilitate secure implementation and
deployment of JWTs.

If we really want to "facilitate secure implementation and deployment of JWTs" covering threats and attacks that were not mentioned when RFC 8725 was published, we should not ignore that threat and we should indicate ways to counter it.