Skip to content

Credential Lifecycle & Operations

Audience: EAA Providers running an issuance service in production. This is phase 4 of the EAA Provider roadmap — what happens after you have built and tested your issuer.

Overview

Once your issuer is live and credentials are in holders' wallets, you still have ongoing operational responsibilities: keeping credentials current, revoking them when something changes, rotating your signing keys over time, and responding to incidents.

Your rulebook defines the policy — validity periods, refresh conditions, revocation requirements, and signature rules. The EAA Issuance guide covers building the issuer. This page is about running it.

1. Credential validity periods

Every credential has a validity period. Your rulebook defines the default validity period for your credential type; this section covers the operational aspects of implementing that policy.

Implementation considerations:

Encode validity dates correctly in the credential format. SD-JWT VC uses iat and exp claims; mDoc uses validFrom and validUntil fields. Ensure your issuance logic calculates expiry dates according to your rulebook's policy. Store issuance and expiry dates in your backend systems for tracking and renewal purposes. Use UTC timestamps to avoid ambiguity across time zones.

User experience considerations:

If your rulebook specifies relatively short validity periods, consider implementing proactive user notifications. Alert holders at meaningful intervals before expiry (for example, 7 days before expiration, adjusted based on your validity period). Direct users to renewal or refresh flows with clear instructions and minimal friction.

2. Credential refresh

Credential refresh allows holders to obtain an updated version of a credential without repeating the full identification and verification process. Your rulebook defines whether refresh is supported and under what conditions.

Refresh spans build and operate

Refresh is triggered as a credential nears expiry (an operational concern), but it is implemented at the token endpoint you built during issuance (see EAA Issuance §4.3). It is documented here because it is fundamentally a lifecycle concern.

Refresh tokens are the protocol-native mechanism for credential refresh in OpenID4VCI and are particularly emphasized in the HAIP (High Assurance Interoperability Profile).

How refresh tokens work:

  1. At initial issuance, when the wallet exchanges an authorization code or pre-authorized code at the token endpoint, the issuer returns both an access_token (for immediate credential issuance) and a refresh_token (for future credential refresh).
  2. When refresh is needed, the wallet presents the refresh_token to the token endpoint using the refresh_token grant type.
  3. The issuer validates the refresh token and returns a new access_token (and optionally a new refresh_token).
  4. The wallet uses the new access token at the credential endpoint to obtain a refreshed credential.
  5. The holder does not need to repeat the authorization flow or provide identification again.

This approach is protocol-standard, aligned with OAuth 2.0 and OpenID4VCI specifications. It provides minimal user friction since no re-authentication or manual action is required. The wallet can manage refresh automatically as credential expiry approaches, and the issuer retains control through refresh token lifetime and rotation policies.

Implementing refresh tokens:

Set refresh token expiry based on your rulebook's refresh policy. For example, if credentials are valid for 24 months and can be refreshed without re-identification, the refresh token should remain valid for at least 24 months.

Consider implementing refresh token rotation where each refresh operation returns a new refresh token and invalidates the old one. This limits exposure if a refresh token is compromised. If implementing rotation, ensure old refresh tokens cannot be reused after rotation.

Provide a mechanism to revoke refresh tokens when a holder's eligibility ends, when the holder requests it, or in case of security incidents.

Refresh tokens are long-lived bearer credentials. Ensure wallets store them securely using encrypted storage or hardware-backed keystores where available.

Token endpoint implementation for refresh:

When the token endpoint receives a refresh token grant:

POST /token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&
refresh_token=<refresh_token_value>

Your token endpoint should:

  1. Validate the refresh token (signature, expiry, revocation status, issuer)
  2. Verify the holder's eligibility remains valid (query your internal records or source systems)
  3. Check whether attributes have changed since the last issuance
  4. Generate a new access token bound to the same credential configuration as the original issuance, the current holder eligibility state, and the credential endpoint audience
  5. Optionally return a new refresh token (if implementing rotation)
  6. Log the refresh event for audit purposes

Handling attribute changes during refresh:

When processing a refresh token request, check whether the underlying data has changed (for example, a professional license was suspended, a specialization was added). If attributes have changed, the new credential should reflect current values, not stale data from the original issuance. If attributes changed in a way that invalidates the old credential (for example, license suspended), revoke the old credential in addition to declining refresh.

Example refresh token response:

{
  "access_token": "<new_access_token>",
  "token_type": "Bearer",
  "expires_in": 86400,
  "refresh_token": "<new_refresh_token>"
}

The wallet uses the c_nonce from the new token response to build its proof-of-possession, then calls the credential endpoint with the new access_token to obtain the refreshed credential — exactly as in the original issuance flow.

2.2 Alternative refresh approaches

If refresh tokens are not suitable for your use case (for example, if your rulebook requires re-authentication or manual approval for renewal), consider these alternative approaches:

Self-service portal with on-demand generation: Provide an authenticated portal where holders can request refresh. Verify eligibility and generate a fresh credential offer. This is suitable when refresh requires holder-initiated action or manual approval workflows.

Authorization code flow with reduced authentication: If your rulebook permits re-using recent identification evidence (within a defined time window), implement an authorization flow that requires only account authentication (not full re-identification). This is useful for credentials where identification was strong at initial issuance but can be relied upon for a limited time.

2.3 Refresh implementation checklist

Regardless of which approach you use, you should consider the following topics:

  • Eligibility verification: Confirm the holder's underlying eligibility remains valid by querying internal records or source systems.
  • Attribute freshness: Query source systems at refresh time to ensure attribute values are current. Never blindly re-issue stale data.
  • Attribute change handling: If attributes have changed, issue an updated credential with new values and log the change for audit purposes.
  • Key binding policy: Determine whether refreshed credentials maintain holder binding to the same key or allow key rotation. Your rulebook should specify this.
  • Audit logging: Log refresh events with sufficient detail to support audits.
  • User notifications: If implementing proactive refresh, notify holders when a refresh is available or has occurred.
  • Error handling: Handle cases where refresh fails (eligibility ended, attributes cannot be verified, etc.) with clear user-facing messages.

3. Credential revocation

Revocation invalidates a credential before its natural expiry. Your rulebook defines the revocation policy including when revocation is required, which mechanism to use, and who can request it. This section covers the technical implementation.

Implementing status lists (recommended):

If your rulebook specifies status lists (for example, StatusList2021), implement the following components:

Status list infrastructure: Maintain a bit array representing credential status (0 = valid, 1 = revoked). Publish the status list at a stable, publicly accessible HTTPS URL. Update the list according to your rulebook's latency requirement (for example, within 4 hours).

Credential referencing: Include a status list reference in each credential at issuance time. Specify the status list URL and the credential's index position. For SD-JWT VC, include this in the status claim. For mDoc, include it in the appropriate namespace or element.

Revocation workflow: Provide an API or back-office interface for authorized parties to submit revocation requests. Validate the requestor's authority based on your rulebook policy. Update the status list by flipping the appropriate bit. Publish the updated list within the latency window defined in your rulebook. Log the revocation event with timestamp, requestor identity, and reason.

Privacy considerations: Status lists are fetched by relying parties, not by the issuer on each verification. Holders are not tracked when their credentials are verified. Use sufficiently large status lists to prevent correlation attacks.

Operational implementation:

Regardless of which revocation mechanism you use, implement the following operational capabilities:

Revocation request interface: Provide a web portal, API, or back-office system for authorized parties to request revocation.

Authorization checks: Verify that the requestor is authorized according to your rulebook policy (holder via authenticated portal, regulatory authority via trusted channel, etc.).

Notification system: Send notifications to affected holders when their credentials are revoked using email, wallet notification, or SMS.

Audit logging: Log all revocation requests and actions with sufficient detail to support compliance audits.

Monitoring: Monitor revocation infrastructure availability and latency to ensure compliance with your rulebook's SLA.

4. Issuer key and certificate rotation

EAA Providers sign credentials using cryptographic keys associated with a certificate issued under a trust framework. Over time, you will need to rotate these keys and certificates. Your rulebook defines signature requirements; this section covers the operational process of key and certificate rotation.

Routine rotation:

Key rotation is a normal part of secure operations. Certificates have a defined validity period and must be renewed before expiry. Periodic key rotation reduces risk exposure and is often required by security policies. During rotation, you should support a transition period where both old and new keys are trusted.

Implementation approach:

Obtain a new certificate from the trust framework before the current certificate expires. Publish the new certificate in the trust registry and update your issuer metadata. Begin signing new credentials with the new key. Continue to maintain the old certificate in the trust registry for the duration of its validity (or longer if credentials signed with it are still in circulation). Wallets and verifiers can validate credentials signed with either key during the transition period.

Impact on existing credentials:

Credentials issued and signed with the old key remain valid and verifiable as long as the old certificate is still within its validity period, or the trust registry maintains historical certificate information and verifiers are configured to accept credentials signed by expired-but-once-valid issuer certificates (depending on ecosystem policy).

Your rulebook and operational documentation should clarify the expected lifetime of credentials relative to issuer certificate lifetimes.

5. Security incident response

As an EAA Provider, you should prepare for security incidents that may affect the integrity of your issuance infrastructure or the credentials you've issued. While incidents vary in nature and severity, having a response plan helps minimize impact on holders and verifiers.

Types of security incidents to consider:

Key compromise: Your signing key is exposed or stolen, potentially allowing unauthorized credential issuance.

Infrastructure breach: Unauthorized access to your issuance systems, source systems, or holder data.

Process failure: Credentials issued with incorrect attributes or to wrong holders.

Trust framework changes: Changes in trust framework policy that affect your credentials' validity.

Certificate issues: Discovery that your issuer certificate was issued improperly or should be revoked.

Example response to key compromise:

If your signing key is compromised, you would typically follow these steps. First, contain the incident by securing your infrastructure and preventing further unauthorized issuance. Second, revoke the compromised certificate by submitting a revocation request to the trust framework authority. Third, assess the impact by determining which credentials may be affected and what the timeline of compromise was. Fourth, obtain a new certificate by completing the trust framework registration process with a new key pair. Fifth, notify affected parties by communicating with holders, verifiers, and the ecosystem operator about the incident, timeline, and next steps. Sixth, re-issue credentials by providing a clear process for holders to obtain new credentials signed with the new key. Finally, review and improve security by conducting a post-incident review and implementing measures to prevent recurrence.

Impact of certificate revocation:

Revoking your issuer certificate has significant consequences. All credentials signed with that key may be considered invalid by verifiers, depending on trust framework policy. Holders will need to obtain new credentials signed with a new, trusted key. You will need to communicate the incident and remediation steps clearly and quickly.

Operational planning:

Consider including the following in your operational documentation: an incident response plan covering various security scenarios, contact information and escalation paths for trust framework authorities, communication templates for notifying holders and relying parties, processes for mass re-issuance if necessary, roles and responsibilities during an incident, and procedures for testing and exercising your incident response capabilities.

6. Deferred issuance

Deferred issuance is an OpenID4VCI feature that allows an issuer to accept a credential request but defer the actual issuance until a later time (for example, pending manual review, background checks, or asynchronous data retrieval).

Current status in the EUDI ecosystem:

Deferred issuance is not yet supported by the EUDI Wallet reference implementation. If your use case requires deferred issuance, you should monitor ecosystem updates for support timelines and consider alternative approaches in the interim (for example, notify the holder out-of-band when the credential is ready and issue a new credential offer).

Use cases for deferred issuance:

  • Manual approval workflows where a credential requires human review.
  • Credentials that depend on slow or batch-processed source systems.
  • Credentials with complex eligibility rules that cannot be evaluated in real-time.

Planning considerations:

If you anticipate needing deferred issuance, document this requirement in your rulebook and integration plans. Design your issuance workflows to be adaptable when deferred issuance becomes available.