JWT: JSON Web Token

Definition

JWT Structure and Claims

A signed JWT (the most common form in EUDI Wallets) consists of three Base64URL-encoded segments separated by dots: the header, the payload, and the signature. The header specifies the token type and signing algorithm. The payload contains the claims -- key-value pairs asserting facts about the subject. The signature ensures integrity and authenticity.

JWT defines a set of registered claims with standardized semantics. The iss (issuer) claim identifies who created the token -- for EUDI credentials, this is the credential issuer's identifier. The sub (subject) claim identifies the holder. The iat (issued at), exp (expiration), and nbf (not before) claims manage token validity windows.

The cnf (confirmation) claim is particularly important for EUDI Wallets. It contains a reference to the holder's device key (typically as a JWK thumbprint), binding the credential to a specific device. During presentation, the holder proves possession of the corresponding private key, preventing credential theft or sharing.

Beyond registered claims, EUDI Wallet credentials include custom claims for identity attributes: family_name, given_name, birth_date, nationality, and other attributes defined by the credential schema. These claims carry the actual identity information that users share with verifiers.

From JWT to SD-JWT: Selective Disclosure for Privacy

Standard JWTs have a significant limitation for identity credentials: when a JWT is presented, all claims in the payload are visible to the verifier. If a user wants to prove they are over 18, a standard JWT containing their full date of birth, name, and address would expose all this information unnecessarily.

SD-JWT (Selective Disclosure JWT) solves this problem by extending the JWT format. In an SD-JWT, the issuer replaces individual claims with their cryptographic hashes in the signed JWT payload. The actual claim values are provided as separate disclosure objects. When presenting the credential, the wallet includes only the disclosures for the claims the verifier requested.

For example, an SD-JWT credential might contain hashed versions of family_name, given_name, birth_date, and address. If a verifier only needs age verification, the wallet presents the SD-JWT along with only the birth_date disclosure. The verifier can hash the disclosed birth_date, confirm it matches the hash in the signed JWT, and verify the age -- without ever seeing the user's name or address.

The EUDI Wallet Architecture and Reference Framework mandates SD-JWT VC (SD-JWT Verifiable Credentials) as one of two primary credential formats, alongside mDoc. SD-JWT VC extends SD-JWT with additional structure for verifiable credential metadata, issuer identification, and credential type information.

JWT Across the EUDI Wallet Protocol Stack

JWT appears at every level of the EUDI Wallet protocol stack. During credential issuance via OpenID4VCI, access tokens authorizing the issuance are JWTs. The issued credentials themselves are SD-JWTs. DPoP (Demonstrating Proof-of-Possession) tokens proving the wallet's identity during issuance are JWTs signed by the wallet's device key.

During credential presentation via OpenID4VP, the authorization request from the verifier may be a signed JWT (Request Object). The verifiable presentation response containing the credentials and key binding proof is structured around JWT objects. ID Tokens returned in OpenID Connect flows are JWTs.

This pervasive use of JWT throughout the EUDI Wallet ecosystem means that JWT processing libraries are among the most critical software components in any wallet implementation. Correct JWT validation -- checking signatures, verifying expiration, confirming issuer identity, and validating claims -- is fundamental to the security of the entire system.

Related Terms