10.5. Digital Credential Lifecycle

This chapter specifies the lifecycle, revocation, and status check of a Digital Credential. Revocation of a Wallet Instance is specified in Wallet Instance Revocation. Revocation of certificates and Trust Artifacts is specified in Revocation Mechanisms.

The Credential Issuer is responsible for creating and issuing Digital Credentials, as well as managing their lifecycle and validity status.

The Authentic Source is the entity responsible for the management and provisioning of User's attributes to Credential Issuers. There is a relationship between the lifecycle of the attributes managed by the Authentic Source and the Digital Credential lifecycle managed by the Credential Issuer. Indeed, one of the reasons for revocation or suspension of Digital Credentials is the update/revocation or suspension of the attributes contained in the Digital Credential. In IT Wallet, the provisioning of User's attributes and the notification of updates or changes in the state of the attributes are exchanged using the PDND infrastructure (see relative sections for more details).

Fig. 10.1 shows the states and transitions for Digital Credentials. It includes four distinct states: Issued, Valid, Expired, and Revoked. While, in case of (Q)EAAs there is an additional state: Suspended. A Digital Credential in all states can be deleted (PID/(Q)EAA DEL) and this ends its lifecycle.

Fig. 10.1 Digital Credential State Transactions.

Note

Users MAY present a Digital Credential in any state, it is up to the Relying Party's policy to accept a not Valid Digital Credential. An example of this scenario is when a Relying Party needs to verify that the User is not a minor. In this case, even if the User presents an Issued/Expired/Revoked or Suspended Digital Credential, the age claim is still reliable.

Note

While Issued, Valid, Expired, Revoked are explicitly mentioned in the ARF (see Figure 5 of ARF v1.4), Suspended is implicitly present in EIDAS-ARF. This specification explicitly considers it.

10.5.1. Credential Transitions

10.5.1.1. Credential Transition to Issued

For the state machine to start, the Wallet Instance MUST be in either the Operational or Valid state, enabling Digital Credentials to be issued to it. The state machine begins with the Issued state, when an issuance process is triggered and, as a result, a Digital Credential is issued to the Wallet Instance (PID/(Q)EAA ISS). Please refer to Digital Credential Issuance.

10.5.1.2. Credential Transition to Valid

A Digital Credential changes to Valid state when:

• it reaches its start date of validity.

• an unsuspension process is triggered if the (Q)EAA has been suspended.

10.5.1.3. Credential Transition to Expired

A Digital Credential naturally transitions to the Expired state when it automatically expires upon reaching its end date of validity (PID/(Q)EAA expiration).

If a Digital Credential is Expired, the Wallet Instance SHOULD notify the User that the Digital Credential has expired. The User MAY delete the Digital Credential (PID/(Q)EAA DEL). This ends its lifecycle.

10.5.1.4. Credential Transition to Revoked

A Digital Credential changes from Issued, Valid or Suspended states to Revoked state when it is actively revoked by the Credential Issuer by a revocation process (PID/(Q)EAA REV). The Relying Parties SHOULD no longer consider usable a particular Digital Credential when it is Revoked, even though it is still valid temporally and contains a valid Credential Issuer signature. Revocation can occur in the following cases:

• for technical security reasons relating to the compromise of cryptographic material.

• in case of explicit User requests.

• in case of a revocation of the attributes contained in the Digital Credential notified by the Authentic Source.

• death of the User.

• revocation of Wallet Instance to which the Digital Credential was issued.

• illegal activities of the User reported by Judicial or Supervisory Bodies.

In the case of PID and IT-Wallet ID only, the following cases are in addition to those listed above.

• detection of a breach of the digital identity issued by an Identity Provider and used to authenticate the User during the PID/IT-Wallet ID Issuance.

• as a result of obtaining a new PID/IT-Wallet ID on a new Wallet Instance from the same Wallet Provider that has provided the Wallet Instance containing a PID/IT-Wallet ID previously issued.

Note

A (Q)EAA Provider MAY revoke a (Q)EAA in case of PID/IT-Wallet ID revocation.

When a Digital Credential is Revoked, the Digital Credential cannot transition back to Valid. The Wallet Instance SHOULD notify the User that the Digital Credential has been revoked. The User MAY delete the Digital Credential (PID/(Q)EAA DEL). This ends its lifecycle.

10.5.1.5. Credential Transition to Suspended

A (Q)EAA changes from Issued or Valid states to Suspended state when it is suspended by the Credential Issuer ((Q)EAA SUSP). The (Q)EAA remains Suspended until it is restored to the Issued or Valid state ((Q)EAA UNSUSP) depending on the previous state, i.e. the conditions leading to its suspension are resolved, or it changes in Revoked, Expired or it is deleted. The suspension of a (Q)EAA MAY be:

• Use case driven, based on the validity status of the attributes contained in the (Q)EAA. In this case, an Authentic Source MUST notify the Credential Issuer of any changes in the state of the attributes attested by the (Q)EAA.

• Explicitly requested by the User.

10.5.2. Digital Credential Lifecycle in a Batch

For Digital Credentials issued in a single batch, each Credential immediately enters its own lifecycle state machine. All state transitions (Issued → Valid → Expired/Suspended/Revoked) still occur on a per Credential basis, using Credential's individual parameters (e.g., validity dates, Status List).

10.5.3. Credential Lifecycle Management

While Fig. 10.1 shows the different states a Digital Credential may acquire during its lifecycle, Fig. 10.2 shows the point of view of Wallet Instances and Credential Issuers in managing the Digital Credential lifecycle and the effect on their local storage.

Fig. 10.2 Digital Credential Lifecycle Management.

A User, through the Wallet Instance, is able to acquire a new Digital Credential (Credential Acquisition) performing the PID/(Q)EAA ISS process. This MUST result in the storage of a Digital Credential in the Issued/Valid state, and delete it when it is not needed anymore or it is Expired/Revoked (Credential Deletion). Until the Credential Deletion, a Digital Credential can be presented to Relying Parties, this operation will not affect its lifecycle.

A Credential Issuer instead is responsible for:

• Digital Credential Generation: the Digital Credential is generated as a consequence of an issuance request and MUST be added to the local storage of the Credential Issuer after the successful issuance.

• Digital Credential Revocation/Suspension/Unsuspension (PID/(Q)EAA REV and (Q)EAA SUSP/UNSUSP): for technical security reasons or triggered by external entities (e.g., Users and Authentic Sources) the Digital Credential state MUST be locally updated.

• Data Purging: after reaching the Expired state, and based on the Credential Issuer retention policies, Digital Credentials MUST be removed from the local storage of the Credential Issuer.

10.5.3.1. Digital Credential Revocation and Suspension

This section describes the flows to request a Digital Credential status update (i.e. revocation or suspension), involved entities, and validation mechanisms for Digital Credentials in the IT-Wallet system.

As highlighted in Section Digital Credential Lifecycle, a Digital Credential's lifecycle is affected by:

• The lifecycle of its storing Wallet Instance

• The validity of Attributes managed by Authentic Sources

• For PIDs only, the status of the Digital Identity used for User authentication

External user-related factors can also influence a Digital Credential's lifecycle, such as:

• Explicit request from the Digital Credential holder

• User's death

• Illegal activities

10.5.3.2. Entities Involved

The Credential Issuer MUST directly manage the validity status of Digital Credentials it has issued. Other actors MAY trigger the Digital Credential revocation/suspension process.

• Users, through their Wallet Instance.

• Users, through the web service provided by the Issuer.

• The Authentic Source, when Credential attributes are updated or change validity status.

• The Wallet Provider, when revoking a Wallet Instance.

• The Identity Provider, if the Digital Identity used for PID/IT-Wallet ID issuance is stolen or compromised.

• Legal authorities or the Supervisory Body, in cases of proven illegal activities.

The following figure shows an entity relationships diagram relating to the Update Flow status.

Fig. 10.3 Entities involved in Credential Revocation Flow.

10.5.3.3. Status Update Flows

This section describes the main flows for managing Digital Credential Status Updates by the Issuer, in particular Status Update:

• related to the User.

• triggered by a Wallet Instance.

• triggered by a Wallet Provider.

• triggered by an Authentic Source.

Note

Detailed Status Update Flows for Identity Providers, legal authorities, and the Supervisory Body will be covered in future versions of the technical specification.

10.5.3.3.1. Status Update related to the User

Users MAY change their Digital Credential validity status by:

1. Deleting the Digital Credential from their Wallet Instance: the Wallet Instance SHOULD prompt the User to be optionally notify the Credential Issuer about the User's intention to revoke the Digital Credential. When the User uses this functionality, the notification to be sent to the Credential Issuer MUST use the Notification Endpoint provided by the Issuer, as described in Section Status Update by Wallet Instance.

2. Using the Issuer's web portal:

1. Users MAY access a secure area with at least the same Level of Assurance used during the issuance phase.

2. The Issuer MUST allow Users to:

• View all their Digital Credentials contained in the Issuer's database.

• Verify data authenticity.

• View and update validity status (revoke their Digital Credentials and, if it is supported by the Issuer, suspend them).

In addition, when Users detect incorrect data in an issued Digital Credential, the Wallet Instance SHOULD initiate a data correction request via the Notification Endpoint as specified in Data Correction using credential_failure. Upon confirmation of the discrepancy, the Issuer SHOULD follow the Re-Issuance Flow.

Note

If the User activates another Wallet Instance from the same Wallet Provider and using the same Wallet Solution and obtains a new PID/IT-Wallet ID, the previous PID/IT-Wallet ID MUST be revoked. In case of PID revocation the previous Wallet Instance MUST transition to operational status.

In case of the death of the User, Issuers MUST ensure that Digital Credentials and Wallet Instances owned by the User are revoked. The User's death triggers a change in the validity status of the User's identification attributes contained in the public registry (ANPR). The User's death MUST produce the PID/IT-Wallet ID revocation. Therefore, the Authentic Source of the PID/IT-Wallet ID (ANPR) MUST notify the PID/EAA Provider that the User's attributes are no longer valid due to the death of the User. The Authentic Source and the PID/EAA Provider MUST use the mechanisms provided in the Section Status Update by Authentic Sources.

Note

Future versions of this technical specification will define how the information to (Q)EAA Issuers are propagated, according to national regulation. Moreover, automated procedures for Credential revocation due to illegal activities will be defined in future specifications.

10.5.3.3.2. Status Update by Wallet Instance

When the User deletes a Digital Credential from the Wallet Instance, the Wallet Instance by default MUST NOT notify the Credential Issuer of this deletion event. Deleting a Digital Credential from the Wallet Instance only removes the local copy and does not change the validity status at the Issuer.

The Wallet Instance MAY inform the User, prior to deletion, that deletion is a local action and does not imply revocation at the Issuer. The Wallet Instance MAY implement, under the User's explicit consent at deletion time, a notification feature to inform the Credential Issuer of the User's intention to revoke the Digital Credential.

If the User wants the Issuer to revoke a Digital Credential, the User SHOULD explicitly confirm this intention via the Wallet Instance's deletion prompt (when available). The Wallet Instance MUST then notify the Credential Issuer. Alternatively, the User MAY use the Issuer's web portal or other Issuer-provided channels.

When the revoked Credential is the PID/IT-Wallet ID, the Credential Issuer MUST send a notification of this event to the User within 24 hours. For any other Credential different from the PID/IT-Wallet ID, the Credential Issuer SHOULD send a notification of this event to the User. The notification to the User MAY be implemented in several ways, such as using a User's email address, telephone number, or any other verified and secure communication channel. The notification to the User MUST also include all the information about the Credential revocation status. The method used for the notification to the User is out of scope of the current technical implementation profile. When the revocation occurs, the Credential Issuer MUST update the status of the Digital Credential accordingly. When the Notification Response sent by the Credential Issuer is successfully received by the Wallet Instance, the Wallet Instance MUST delete the Digital Credential.

10.5.3.3.3. Status Update by Wallet Providers

Revocation of a Wallet Instance, including the status list of the Wallet Instance Attestation and the Key Attestation, is specified in Wallet Instance Revocation. The Credential Issuer check during the validity period, and the revocation of Credentials that depend on that Wallet Instance, are specified in Revocation Check Mechanisms.

10.5.3.3.4. Status Update by Authentic Sources

Authentic Sources manage attributes separately from Digital Credentials, which verify authenticity like physical documents. Losing a physical document doesn't mean losing the privileges it represents. It just means the User can't prove them. However, if a User loses privileges due to a serious infraction, the Authentic Source will revoke the related attributes. In such cases, when a User's attributes are updated, Authentic Sources MUST notify Credential Issuers to update the validity status of any Digital Credential containing those attributes.

Authentic Sources using PDND MUST use Signal Hub as the only notification update mechanism. In this case, they MUST deposit a Signal through the Signal Collection e-Service in the following cases:

• The value of one or more Attributes contained in the Authentic Source's database has changed.

• The validity status of the Attributes is updated (revocation or suspension).

In both cases, the Signal MUST have signalType set to UPDATE.

Credential Issuers MUST check the PDND Signal Hub Signal Distribution e-Service periodically for new Signals. For the Signal processing flow, please refer to the Section Signals Processing. The Credential Issuer is able to identify the nature of the UPDATE Signal by querying the Authentic Source get attribute API and inspecting the response payload, as described in Section Get Attribute Claims.

The following diagram illustrates the high-level status update process for Authentic Sources.

Fig. 10.4 Status update process of Authentic Sources

The process starts with data or data validity changes that occur in the Authentic Source data. Changes can also be initiated by third-party entities other than the Authentic Source, such as when law enforcement agencies report illegal activities.

Once the data changes, the Authentic Source notifies the Credential Issuers who received the original data using the Signal Hub. The Authentic Source deposits a Signal in the Signal Collection e-Service. Signal Collection e-Service.

The Credential Issuer periodically queries the Signal Hub Signal Distribution e-Service for new Signals. When a new Signal is found, the Credential Issuer retrieves it and processes it as described in Signals Processing. Then, the Credential Issuer updates the Credential Status according to the validity mechanism's defined mode. The Credential Issuer MAY notify the User through a registered out-of-band communication channel.

The Wallet instance, following periodic checks of the validity status of the stored Digital Credentials, receives the updated status. When the Credential Status is changed to INVALID, the Credential Issuer MUST inform the User about this change. In case the Credential status is modified to UPDATE (resp. 0x03) or ATTRIBUTE_UPDATE (resp. 0x0F), the Wallet Instance SHOULD proceed to the re-issuance of the Digital Credential, as described in Re-Issuance Flow.

10.5.3.4. Batch Credential Lifecycle Management

When multiple Digital Credentials are issued together in a single batch, their lifecycle remains fully granular:

• Grouped triggers, independent updates: regardless of the actor that triggers a batch status update (e.g. the Wallet Instance via Notification Endpoint with event=credential_deleted, Wallet Provider via updating Wallet Instance and Key Attestation status list) the status updating is handled as one or more separate status changes. The Credential Issuer updates each Credential's status individually (for instance, by flipping its status-list bit to INVALID or SUSPENDED). The Wallet Instance MUST NOT trigger batch status updates when the User deletes local Credentials. Upon deletion, the Wallet Instance MAY, under the User's explicit consent, notify the Credential Issuer of the User's intention to revoke the affected Credential(s).

Note

As the Wallet UI typically surfaces a batch as one Credential (e.g., 3 uses remaining), a User-driven deletion in the Wallet removes the entire batch locally. By default it does not request revocation at the Issuer. The Wallet MAY offer the User an optional prompt to request revocation at the Issuer as part of the deletion flow.

10.5.4. Validity Verification Mechanisms

For the verification of the validity status of a long-lived Digital Credential the Token Status List (TOKEN-STATUS-LIST) MUST be supported for both the remote and proximity scenario. The following table sums up the required revocation mechanisms for verifying the status of long-lived Digital Credentials.

Flow	Revocation Mechanism	Reference
Remote	[REQUIRED] Token Status List.	TOKEN-STATUS-LIST.
Proximity	[REQUIRED] Token Status List.	TOKEN-STATUS-LIST.

10.5.4.1. Token Status List (Digital Credentials Profile)

This section profiles the Token Status List (TSL) mechanism of TOKEN-STATUS-LIST for Digital Credentials. A TSL conveys the current status of many Digital Credentials in a compact, signed Status List Token (SLT).

The SLT Provider MUST be the Credential Issuer.

10.5.4.1.1. Status List

A Status List contains a compressed byte array whose entries represent the statuses of many Digital Credentials. The Credential Issuer MUST allocate each issued Digital Credential a distinct, non-negative idx value and include it, together with the SLT uri, in the Digital Credential's status-list reference. For an SD-JWT Digital Credential, the reference is in status.status_list, idx is a JSON integer, and uri is a JSON string. For an mdoc MSO, the reference is in issuerAuth.status_list, idx is a CBOR unsigned integer, and uri is a CBOR text string. In both cases, uri MUST be a URI conforming to RFC 3986.

According to this specification, a Digital Credential can have one of the following statuses:

• VALID. The Digital Credential is valid. This status is represented by 0x00 in the SLT.

• INVALID. The Digital Credential is revoked. This status is represented by 0x01 in the SLT.

• SUSPENDED. The Digital Credential is temporarily invalid and may be restored to VALID. This status is represented by 0x02 in the SLT.

• UPDATE. The Digital Credential's metadata parameters have changed. This status is represented by 0x03 in the SLT.

• ATTRIBUTE_UPDATE. The Digital Credential's attributes have changed. This status is represented by 0x0F in the SLT.

As a result, the Credential Issuer MUST set the bits parameter in the SLT's status_list object to 4.

The Credential Issuer MAY define additional application-specific statuses within the range supported by bits. It SHOULD carefully consider the information disclosed to Relying Parties when defining additional statuses for the Digital Credential lifecycle.

The Credential Issuer MUST pack entries starting with the least significant bit of each byte. The Credential Issuer MUST compress the byte array using DEFLATE with the ZLIB data format. The Credential Issuer MUST publish the resulting Status List in the SLT.

10.5.4.1.2. Status List Token

The Credential Issuer MUST act as both the Status Issuer and the Status Provider. It MUST make each SLT available via HTTP GET at the URI specified by the Digital Credential's status-list reference, using application/statuslist+jwt for a JWT SLT or application/statuslist+cwt for a CWT SLT.

The SLT format MAY be either a JWT or a CWT. The SLT MUST be protected by a cryptographic signature. Regardless of the chosen format, the SLT MUST conform to Section 5.1 for JWTs or Section 5.2 for CWTs of TOKEN-STATUS-LIST.

Regardless of the format, the Credential Issuer MUST sign the SLT using one of the following.

• A valid X.509 certificate whose trust chain terminates at the Trust Anchor published in the Credential Issuer's LoTE when the Credential Issuer is registered in the EUDIW Trust Framework.

• A valid key attested by the Credential Issuer's Entity Configuration when the Credential Issuer is registered in the National Trust Framework.

10.5.4.1.3. Privacy Considerations

Credential Issuers MUST integrate the status information for many Digital Credentials into the same list. Credential Issuers MUST publish the SLT at the same uri for all those Digital Credentials. The purpose is to prevent Credential Issuers from tracking or profiling users based on their use of Digital Credentials. This specification requires Credential Issuers to configure Status Lists with at least 100,000 status entries. If more Digital Credentials are issued, the Credential Issuer MAY create additional SLTs. The Credential Issuer MAY increase the number of entries in the array. The choice depends on practical considerations such as the total size of each SLT and the management of multiple endpoints.

10.5.4.1.4. Checking Credentials Statuses

The fetching, processing and verification of a Status List Token may be performed by either the Wallet Instance or a Relying Party. The procedure below is described for the Wallet Instance. The same rules apply to the Relying Party.

Fig. 10.5 Status List Flow.

10.5.4.1.4.1. HTTP Status List Request

To obtain the Status List Token, the Relying Party MUST send an HTTP GET request to the URI specified by the Digital Credential's status-list reference.

The Relying Party SHOULD send an Accept header containing application/statuslist+jwt for a JWT Status List Token or application/statuslist+cwt for a CWT Status List Token.

The following is a non-normative example of a request for a Status List Token:

GET /statuslists HTTP/1.1
Host: example-issuer.com
Accept: application/statuslist+jwt

10.5.4.1.4.2. HTTP Status List Response

The Status List Endpoint responds with a Status List Token and MUST use an HTTP status code in the 2xx range. In the successful response, the Status Provider MUST use application/statuslist+jwt for a JWT Status List Token or application/statuslist+cwt for a CWT Status List Token.

The HTTP response SHOULD use gzip Content-Encoding as defined in [RFC 9110].

If caching-related HTTP headers are present in the HTTP response, Relying Parties SHOULD prioritize the exp and ttl claims within the Status List Token over the HTTP headers for determining caching behavior.

The following is a non-normative example of a response for a Status List Token with type application/statuslist+jwt:

HTTP/1.1 200 OK
Content-Type: application/statuslist+jwt

eyJhbGciOiJFUzI1NiIsImtpZCI6IjEyIiwidHlwIjoic3RhdHVzbGlzdCtqd3QifQ.eyJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9leGFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjQsImxzdCI6ImVKeGpjRkFFQUFDa0FHSSJ9LCJzdWIiOiJodHRwczovL2V4YW1wbGUuY29tL3N0YXR1c2xpc3RzLzEiLCJ0dGwiOjQzMjAwfQ.SSdg3AnTHsyRtCHziLy-QnXg-YRldMEXkdEgDXgE_ZvIvjM0eULQlzEbLBLfCeGhlqKJSReC-m85K79CTjJDzg

Upon receiving a Digital Credential, a Relying Party MUST first perform the validation of the Digital Credential itself (e.g., checking for expected attributes, valid signature and expiration time). If this validation is not successful, the Digital Credential MUST be rejected. If the validation was successful, the Relying Party MUST perform the following validation steps to evaluate the status of the Digital Credential:

• For an SD-JWT Digital Credential, check for the status.status_list reference. For an mdoc MSO, check for the issuerAuth.status_list reference. In either case, validate the status-list reference according to Token Status List (Digital Credentials Profile).

• Resolve the Status List Token from the provided URI.

• Validate the Status List Token:

  • Validate the Status List Token's signature according to Section 7.2 of RFC 7519 for a JWT SLT or Section 7.2 of RFC 8392 for a CWT SLT. This step requires resolving a public key as described in Infrastructure of Trust.

  • Check for the existence of the required claims as defined in Token Status List (Digital Credentials Profile).

  • Check all other claims in the Status List Token according to Token Status List (Digital Credentials Profile):

    • The sub claim of a JWT SLT, or claim 2 of a CWT SLT, MUST equal the uri member in the Digital Credential's status-list reference.

    • If the Relying Party has a freshness policy, it SHOULD check the JWT iat claim or CWT claim 6.

    • If present, the JWT exp claim or CWT claim 4 MUST be checked to determine whether the Status List Token has expired.

    • If the Relying Party uses a caching system, it SHOULD check the JWT ttl claim or CWT claim 65534 and retrieve a fresh copy when resolution_time + ttl < current_time.

• Decompress the Status List using a decompressor compatible with DEFLATE (RFC 1951) and the ZLIB data format (RFC 1950).

• Retrieve the status value at the index specified in the Digital Credential's status-list reference as described in Checking Credentials Statuses. Fail if the provided index is outside the bounds of the Status List.

• Check the status value as described in Checking Credentials Statuses.

If any of these checks fails, no statement about the status of the Digital Credential can be made and the Digital Credential SHOULD be rejected.

For example, the decompressed byte array [0x00, 0x40, 0x21] corresponds to the bit array [0, 0, 0, 0, 0, 0, 0, 0; 0, 1, 0, 0, 0, 0, 0, 0; 0, 0, 1, 0, 0, 0, 0, 1]. The status of the Digital Credential whose idx claim has the value 5 refers to the last 4-bit pair (i.e., [0, 0, 1, 0] = 0x02), whose status is SUSPENDED.

If an error occurs while the Status List Endpoint generates a response, the following HTTP status codes MUST be supported:

Status Code	Description
500 Internal Server Error [REQUIRED]	The Status List Provider encountered an internal problem.
503 Service Unavailable [REQUIRED]	The Status List Provider is temporarily unavailable.
504 Gateway Timeout [OPTIONAL]	The Status List Provider cannot fulfill the request within the defined time interval.