Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)

Note

IETF specification describing how to declare in a JWT that its presenter possesses a proof-of-possession key and how the recipient confirms it.

Summary

Purpose

IETF RFC 7800 (April 2016) explains how to declare, in a JWT, that the presenter possesses a particular key, and how the recipient can verify this:

It serves to prove possession of a key (proof of possession); the presenter is also referred to as a “holder-of-key” presenter RFC 7800, Abstract. Implementing Regulation 2024/2977 uses it for PID in SD-JWT VC format.

Who it applies to

The RFC itself imposes nothing under eIDAS. It applies by reference to providers of person identification data (PID):

• they ensure that the PID issued comply with the annex to Implementing Regulation 2024/2977 Art. 3(3);
• they ensure that the PID are cryptographically bound to the wallet unit to which they are issued Art. 3(5).

In the SD-JWT VC format, the annex requires the PID to include the cnf claim defined in RFC 7800 Annex.

Key points

• A public key of the wallet. Under the annex, the cnf claim of the PID must be a public key generated from a private key stored in the wallet secure cryptographic device (WSCD) of the user’s wallet unit Annex. The WSCD is a tamper-resistant device that protects critical assets and provides cryptographic functions Art. 2(8).
• The role of cnf. In the RFC, this claim contains the information that identifies the proof-of-possession key RFC 7800, § 3.1. Confirmation Claim.
• A single key. The value of cnf must represent only a single proof-of-possession key RFC 7800, § 3.1. Confirmation Claim.
• Asymmetric key. When the presenter holds an asymmetric private key, the jwk member gives the corresponding public key, as a JSON Web Key (JWK) RFC 7800, § 3.2. Representation of an Asymmetric Proof-of-Possession Key.
• What the RFC leaves to protocols. Proof is generally given by signing a value set by the recipient (a “nonce”); how this nonce and its signature are conveyed is not described by the RFC RFC 7800, § 3.6. Specifics Intentionally Not Specified.
• The equivalent in mdoc format. For PID in ISO/IEC-mdoc format, the annex provides a parallel mechanism: a public key in the deviceKey member of the security object, corresponding to a private key stored in the WSCD Annex.

Clauses referred to by the act

• The annex to Implementing Regulation 2024/2977 refers to the definition of the cnf claim in the RFC, without a clause number, and adds a requirement of its own: the public key derives from a private key stored in the WSCD Annex.
• The annex to Implementing Regulation 2024/2977 was replaced by Implementing Regulation 2026/1731 Implementing Regulation (EU) 2026/1731; this summary cites the consolidated version that incorporates it.

Links

• Act that makes it applicable: Implementing Regulation 2024/2977 Implementing Regulation (EU) 2024/2977 — consolidated version of 11/08/2026.
• Related standards: RFC 7519, JWT RFC 7519; SD-JWT VC, an IETF draft draft-ietf-oauth-sd-jwt-vc-22.
• Learning path: step 3, the European wallet.

Written by Asphalia.