Skip to content

Trust Management and Lifecycle

Trust Management Process

This section describes the high level trust management process within the APTITUDE Trust Framework. Its scope is describing the lifecycle of Entities and Trust Artifacts related to WRPs and WPs within the ecosystem, and the relationships between them. Trust Artifacts are the transport mechanism of the Properties (specific Entity attributes categorized in Identity Information, Technical Information, and Policy and Authorization Information) which characterize the entities within the ecosystem, and they are issued and managed by other entities within the ecosystem (Trust Lists and Trust Artifacts Providers).

In particular, this section is structured as follows:

  • Section Ecosystem Participants describes the various entities within the ecosystem, their roles and relationships.
  • Section Entity Properties Schema describes the various Properties of WRPs and WPs, the Trust Artifacts in which these Properties are contained, and the relationships between them.
  • Section Abstract State Machine describes the lifecycle State (an abstraction at the governance level that captures the current operational status and trustworthiness within the ecosystem) of WRPs, WPs, Trust Artifacts, Trust Lists, their definitions, and the effects that these states have on the entities' operational capabilities and trustworthiness.
  • Section Entity Lifecycle Operations describes the operational procedures triggered by changes in the Properties of WRPs and WPs, and the resulting effects on their lifecycle states and trustworthiness within the ecosystem.

When a WRP's, WP's, or Trust Artifacts Properties change (e.g., key rotation), the Trust Artifact Providers or Scheme Operators have to update, revoke and issue or re-sign the corresponding Trust Artifacts or Trust Lists, without necessarily altering the underlying Abstract State of the WRP. These operational procedures are defined in Entity Lifecycle Operations.

Ecosystem Participants

The entities in the ecosystem are divided in different groups depending on their role and the artifact that they issue.

Terminology Differences Between ARF and ETSI Specifications

Please be aware of some differences between ARF and ETSI specifications terminology. The following table summarizes such differences, as well as the terminology choices for this document:

Artifact Name (ARF) Artifact Name (ETSI) Artifact Provider (ARF) Artifact Provider (ETSI) References Artifacts Name in this document Artifact Provider in this document
List of Trusted Entities (LoTE) List of Trusted Entities (LoTE) List of Trusted Entities (LoTE) Provider List of Trusted Entities Scheme Operator (LoTESO) [ETSI TS 119 602], [ARF, Annex I] LoTE List of Trusted Entities (LoTE) Provider
N/A List of Trusted Lists (LOTL) N/A List of Trusted Lists Scheme Operator (LOTLSO) [ETSI TS 119 615] LOTL LOTLSO
Trusted List (TL) Trusted List (TL) Trusted List (TL) Provider Trusted Lists Scheme Operator (TLSO) [ETSI TS 119 612], [ARF, Annex I] TL Trusted List (TL) Provider
N/A EUMS TL N/A EUMS TLSO [ETSI TS 119 615] N/A N/A

The diagram below highlights the relationships between the aforementioned entities and artifacts, and the dependences between them in terms of supervision, publication, and the effects that changes in the artifacts (represented as diamond shaped objects in the diagram) have on the entities (represented as rectangular objects in the diagram). The arrows indicate the direction of supervision, publication, and effect propagation.

flowchart LR
    %%Entities and Artifacts
    ms["Member States and European Commission"]
    sup["Supervisory Body<br>(EC, CAB, NAB, Member States)"]
    sup_art{{"Ecosystem Artifacts<br>(Attestation Rulebboks, Ecosystem Policies, Certification Schemas)"}}
    init_ent["Scheme Operators<br>(LoTE Providers, LOTL Scheme Operators, TL Providers)"]
    init_ent_art{{"Trust Lists<br>(LoTE, LOTL, TL)"}}
    mid_ent["Trust Artifacts Providers<br>(MS Registrars, QTSP, Providers of WRPAC/WRPRC)"]
    mid_ent_art{{"Trust Artifacts<br>(MS Registers, WRPAC, WRPRC, Signature/Seal Certificate)"}}
    end_ent["End-Entities<br>(Attestation Providers, PID Providers, Wallet Providers, Relying Parties, Relying Party Intermediaries)"]
    end_ent_art{{"User Attestations, Wallet Attestations"}}

    %% Modification propagation arrows
    sup =="Supervise"==> init_ent
    sup =="Supervise"==> mid_ent
    sup =="Supervise"==> end_ent
    ms --"Provides/Publishes"--> sup_art
    sup_art --"Affects"--> init_ent
    sup_art --"Affects"--> mid_ent
    sup_art --"Affects"--> end_ent
    mid_ent -."Are included".-> init_ent_art
    end_ent -."Are included".-> init_ent_art
    mid_ent_art --"to"--> end_ent
    init_ent --"Publishes"--> init_ent_art
    mid_ent --"Issue"--> mid_ent_art
    end_ent --"Issue"--> end_ent_art --"to"--> wi["Wallet Units"]
    wi["Wallet Units"] --"Present Attestations"--> end_ent

    linkStyle 0,1,2 stroke:#2ecc71,stroke-width:3px;
    linkStyle 4,5,6 stroke:#e74c3c,stroke-width:2px;

Entity Properties Schema

Trust Artifacts Providers and End-Entities are characterized by three main classes of Properties:

  • Identity Information: This includes the organization's name, contact information, and organizational policies.
  • Technical Configuration: This includes the cryptographic materials (signature/seal keys, authentication keys) and technical endpoints necessary for ecosystem interactions.
  • Policy and Authorization Information: This includes the entity's entitlements, attestation provision capabilities, attestation request capabilities, intermediary use permissions, intended use cases, EDPs, and compliance with certification schemas.

Properties Schema and associated Trust Artifacts

In the tables below are found the relationship between the aforementioned Properties and the Trust Artifacts in which they are contained for specific entity types: Relying Party (Intermediary), PID Providers, Attestation Providers, and Wallet Providers. Since different entity types have their information stored in different artifacts, the tables below are divided by specific types of entities.

All WRPs (Relying Parties, Intermediaries, PID Providers, and Attestation Providers) properties are embedded in various Trust Artifacts as follows:

Entity Type Properties Class Entity Properties Trust Artifacts
WRP Identity Information Organization name WRPAC, WRPRC, Register
WRP Identity Information Contact information WRPAC, Register
WRP Identity Information Organizational Policy WRPAC, WRPRC, Register
WRP Technical Configuration Authentication key WRPAC
WRP Authorization Information Entitlements WRPRC, Register
WRP Authorization Information Intermediary use permissions WRPRC, Register
WRP Authorization Information Service descriptions WRPRC, Register
WRP Authorization Information Supervision information WRPRC, Register

All PID Providers and Attestation Providers have additional specific property requirements embedded in various Trust Artifacts as follows:

Entity Type Properties Class Entity Properties Trust Artifacts
PID Provider or Attestation Provider Technical Configuration Signature/Seal key Signature/Seal Certificate
PID Provider or Attestation Provider Authorization Information RP Permissions EDP
PID Provider or Attestation Provider Authorization Information Attestation provision capabilities WRPRC, Register

All Relying Parties and Intermediaries have additional specific property requirements embedded in various Trust Artifacts as follows:

Entity Type Properties Class Entity Properties Trust Artifacts
Relying Party or RPI Authorization Information Attestation request capabilities WRPRC, Register

All Wallet Providers, PID Providers, and Pub-EAA Providers, being referenced in the LoTE as entities authorized to provide services to the ecosystem, have additional specific properties embedded in the LoTE as follows:

Entity Type Properties Class Entity Properties Trust Artifacts
WP, PID Provider and Pub-EAA Provider Identity Information Organization name LoTE
WP, PID Provider and Pub-EAA Provider Identity Information Contact information LoTE
WP, PID Provider and Pub-EAA Provider Identity Information Organizational Policy LoTE
WP, PID Provider and Pub-EAA Provider Authorization Information Service descriptions LoTE
WP, PID Provider and Pub-EAA Provider Authorization Information Service endpoints LoTE
WP, PID Provider and Pub-EAA Provider Authorization Information Service status LoTE
WP, PID Provider and Pub-EAA Provider Authorization Information Compliance to certification schema LoTE (implicit via inclusion)
WP, PID Provider and Pub-EAA Provider Technical Configuration Signature/Seal trust anchors LoTE

Note

The inclusion of Wallet Providers and PID/<Pub-EAA Providers|Pub-EAA Providers> in the LoTE is an implicit assertion of their role and authorization within the ecosystem. In particular, their inclusion is a result of the succesful completion of the registration and notification procedures as defined in [CIR 2025/848] (registration of WRP) and [CIR 2024/2980] (notifications of WRP and WP).

The diagram below highlights the dependences between WRP's and WP's Properties, the Trust Lists (diamond shaped boxes) in which these Properties (round shaped boxes) are contained and the Entities (square boxes) that use the Properties' information to issue additional Trust Artifacts. For both WRPs and WPs, the inclusion in the Trust Lists attests the implicit, ongoing, compliance to the polices set up by the European Commission and the Member State during onboarding for the respective roles.

flowchart LR
    wrp["WRP"]

    subgraph abst["WRP Properties"]
        direction LR
        id(["Identity Information<br>(organization name, contact information, organization policies)"])
        tech(["Technical Configuration<br>(signature/seal key,<br>AuthN key, endpoints)"])
        authz(["Policy and Authorization<br>(entitlements, attestation provision, attestation request, intermediary use, intended use, compliance to certification schema)"])
    end

    subgraph arti["WRP Artifacts"]
        direction LR
        ac{{"WRPAC"}}
        csig{{"Signature/Seal Certificate"}}
        rc{{"WRPRC"}}
    end

    tl{{"LoTE"}}
    reg{{"Register"}}

    ca["Signature/Seal<br>Certificate Authority or QTSP"]
    acca["Provider of WRPAC"]
    rcca["Provider of WRPRC"]
    ent_reg["Registrar"]
    tlp["LoTE Scheme Operator"]

    ent_reg --"publishes/manages"--> reg
    wrp --"characterized by"--> abst

    reg --"used by"--> acca
    tech --"used by"--> acca
    acca --"issues/manages"--> ac

    reg --"used by"--> ca
    tech --"used by"--> ca
    ca --"issues/manages"--> csig

    reg -."used by".-> rcca
    rcca --"issues/manages"--> rc

    id --"contained in"--> reg
    authz --"reflected in"--> tl
    authz --"contained in"--> reg
    abst --"used by<br>(when PID/Pub-EAA Provider)"--> tlp
    tlp --"issues/manages"--> tl


    wp["Wallet Provider"]

    subgraph abst_wp["WP Properties"]
        direction LR
        id_wp(["Identity Information<br>(organization name, contact information, organization policies)"])
        tech_wp(["Technical Configuration<br>(signature/seal key,<br>endpoints)"])
        authz_wp(["Policy and Authorization<br>(wallet attestation provvision, compliance to certification schema)"])
    end

    subgraph arti_wp["WP Artifacts"]
        direction LR
        csig_wp{{"Signature/Seal Certificate"}}
    end
    ca_wp["Signature/Seal<br>Certificate Authority or QTSP"]

    wp --"characterized by"--> abst_wp
    authz_wp --"reflected in"--> tl
    tech_wp --"used by"--> ca_wp
    ca_wp --"issues/manages"--> csig_wp

    abst_wp --"used by"--> tlp

In the tables below are found the relationship between the aforementioned Properties and the Trust Artifacts in which they are contained for specific entity types: Registrars, Providers of WRPAC, Providers of WRPRC, and QTSP. Since different entity types have their information stored in different artifacts, the tables below are divided by specific types of entities.

The following table describes the relationship between the Properties of Registrars and Providers of WRPAC/WRPRC and the Trust Lists in which these Properties are contained.

Entity Type Properties Class Entity Properties Trust Artifacts
Registrar, Provider of WRPAC, Provider of WRPRC Identity Information Organization name LoTE
Registrar, Provider of WRPAC, Provider of WRPRC Identity Information Contact information LoTE
Registrar, Provider of WRPAC, Provider of WRPRC Identity Information Organizational Policy LoTE
Registrar, Provider of WRPAC, Provider of WRPRC Authorization Information Service descriptions LoTE
Registrar, Provider of WRPAC, Provider of WRPRC Authorization Information Service endpoints LoTE
Registrar, Provider of WRPAC, Provider of WRPRC Authorization Information Service status LoTE
Registrar, Provider of WRPAC, Provider of WRPRC Technical Configuration Signature/Seal key Signature/Seal Certificate
Registrar, Provider of WRPAC, Provider of WRPRC Technical Configuration Signature/Seal Trust Anchor LoTE

The following table describes the relationship between the Properties of QTSPs and the Trust Lists in which these Properties are contained.

Entity Type Properties Class Entity Properties Trust Artifacts
QTSP Identity Information Organization name TL
QTSP Identity Information Contact information TL
QTSP Identity Information Organizational Policy TL
QTSP Authorization Information Service descriptions TL
QTSP Authorization Information Service endpoints TL
QTSP Authorization Information Service status TL
QTSP Technical Configuration Signature/Seal key TL

The diagram below highlights these dependences between Trust Artifact Provider Properties, artifacts in which these Properties are contained and entities that use this information to issue/publish Trust Artifacts:

flowchart LR
    mid_ent["Trust Artifact Provider<br>(Registrar, Provider of WRPAC/WRPRC, QTSP)"]

    subgraph abst["Entity Properties"]
        direction LR
        id(["Identity Information<br>(organization name, contact information, organization policies)"])
        tech(["Technical Configuration<br>(signature/seal key,<br> endpoints)"])
        authz(["Policy and Authorization<br>(compliance to certification schema)"])
    end

    subgraph arti["Entity Artifacts"]
        direction LR
        csig{{"Signature/Seal Certificate"}}
    end

    ms["Member State, European Commission"]

    tl{{"LoTE or TL"}}

    ca["Signature/Seal<br>Certificate Authority"]
    tlp["LoTE/TL Provider"]

    mid_ent --"characterized by"--> abst

    id --"used by"--> ca
    tech --"used by"--> ca
    ca --"issues/manages"--> csig

    abst --"used by"--> tlp
    tlp --"publishes/maintains"--> tl

    ms --"defines"--> authz
    authz --"is reflected in"--> tl

Abstract State Machine

This section describes the lifecycle State of WRPs and Wallet Providers, as well as Trust Artifacts and Trust Lists.

Entity Lifecycle State Machine

State Machines are described only for WRPs, Wallet Providers, and Trust Artifacts Providers. Their status is determined through Trust Artifacts or Trust Lists entries. WRPs, Wallet Providers, and Trust Artifacts Providers participating in the APTITUDE Trust Framework are classified into one of the following mutually exclusive lifecycle States at any given time. The State dictates the entity's authorization level, operational capabilities, and how other participants SHALL interact with its cryptographic artifacts.

  • UNREGISTERED: Indicates that an entity does not currently hold a valid subscription or registration within the APTITUDE Trust Framework. This is the default baseline state. Entities in this state are outside the trust boundary and SHALL NOT participate in framework operations or federation protocols.
  • REGISTERED: Indicates that an entity has successfully completed the onboarding process, verified its identity, and has established ecosystem access.
    • A WRP is in REGISTERED state if the Registrar has inserted its Identity information within the Register, and possesses the WRPAC binding this Identity information to a key controlled by the entity.
    • The Wallet Provider is in REGISTERED when it has completed the necessary certification and successfully completed the onboarding process.
  • OPERATIONAL: Indicates that an entity has successfully completed onboarding, and, crucially, has been authorized to perform role-related operations, provide services, and issue or verify artifacts in accordance with framework policies.
  • REMOVED: Indicates the revocation of an entity's REGISTERED status due to voluntary offboarding, a severe security breach, or a critical compliance failure.
    • A WRP is in REMOVED state if the WRPAC is revoked.
    • A Wallet Provider or Trust Artifacts Provider is in REMOVED state when it is not listed in the latest version of the relevant Trust List.
    • Forward Operations: Ecosystem participants SHALL reject new interactions or transactions initiated by a REMOVED entity, and all cryptographic keys, active attestations, and operational capabilities associated with the entity SHALL be immediately revoked.
    • Historical Operations: Ecosystem participants MAY continue to validate historical data, signatures, and attestations generated prior to the Removal timestamp, subject to local risk policies. These historical data are found in the corresponding Trust List's ServiceHistory component.

Below the state diagram of the various actors.

stateDiagram-v2
    %% Define states
    [*] --> Unreg

    state "UNREGISTERED" as Unreg
    state "REGISTERED" as Reg
    state "OPERATIONAL" as Op
    state "REMOVED" as Withdrawn

    %% Define transitions
    Unreg --> Reg : Onboarding & Identity Verification<br>(WRPAC Issued & Register Inclusion)

    Reg --> Op : Authorization Granted<br>(Signature/Seal Issued & listed in LoTE)

    Op --> Reg : Authorization Lost<br>(e.g., Signature Cert Expired, LoTE  ServiceStatus `withdrawn`)

    Reg --> Withdrawn : Registration Revoked<br>(WRPAC Revoked, Exclusion from Register)

    Op --> Withdrawn : Critical Failure / Offboarding<br>(WRPAC, Signature/Seal Cert. Revoked, & Removed from LoTE)

    Withdrawn --> [*] : Terminal State

    %% Add descriptive notes
    note right of Unreg
        Baseline state. 
        Outside the trust boundary.
    end note

    note right of Reg
        Identity established. 
        Ecosystem access granted.
    end note

    note right of Op
        Fully authorized. 
        Can issue/verify artifacts.
    end note

    note right of Withdrawn
        Forward operations rejected. 
        Historical operations may be validated.
    end note

The table below summarizes the lifecycle states, their definitions, the entity to which it refers, the Trust Artifacts that assert the entity's state, and the technical mean that conveys the validity of the Trust Artifacts.

State Definition Applicable Entities Asserting Trust Artifacts Technical Mean
UNREGISTERED Indicates that an entity does not currently hold a valid subscription or registration within the APTITUDE Trust Framework. All potential ecosystem participants prior to onboarding. N/A N/A
REGISTERED Indicates that an entity has successfully completed onboarding, verified its identity, and established baseline ecosystem network access. WRPs (RPs, PID Providers, and EAA Providers) and Wallet Providers. WRP: Valid WRPAC and identity inclusion in the Register.

Wallet Provider: Finalized certification and onboarding records.		 WRP: OCSP response with good status (or absence in CRL) for the WRPAC; active status in the Register.
OPERATIONAL Indicates that an entity is explicitly authorized to perform role-related operations, provide services, and issue or verify artifacts. REGISTERED WRPs and Wallet Providers. RP (Intermediary): Authorization in Register, WRPRC (optional).

EAA Provider / QEAA Provider: Valid Signature/Seal certificate, Authorization in Register, WRPRC (optional).

PID Provider / Pub-EAA Provider: Valid Signature/Seal certificate, entry in the relevant LoTE, Authorization in Register, WRPRC (optional).

Wallet Provider: Valid Signature/Seal certificate, entry in the relevant Trust List.		 Certificates: OCSP response with good status or absence in CRL for Signature/Seal certificates and WRPACs; Status List Token with status set to 0x00.

LoTE: Entry matching the entity.

Register: Validated role-specific authorization schema Properties.
REMOVED Indicates the revocation of an entity's REGISTERED status due to voluntary offboarding, a severe security breach, or a critical compliance failure. All deactivated, offboarded, or permanently banned framework participants. WRP: Revoked WRPAC, removal from LoTE (if applicable) and Register entry.

Wallet Provider: Removal from the current active LoTE.		 OCSP response with revoked status or presence in a CRL for the WRPAC.

Complete absence from the active Register or Trust List (if applicable); resolution of historical status via the ServiceHistory component.

Depending on the circumstances, an entity in the REMOVED state MAY have its Signature/Seal certificates revoked, when this is not the case, all artifacts the entity has issued SHALL be considered valid for historical operations. Further details on this are found in the Operational Effects of Removal section.

Trust Artifacts and Trust Lists Lifecycle State Machine

State Machines for Trust Artifacts and Trust Lists are described below:

  • For WRPAC, WRPRC and Signature/Seal Certificates, the lifecycle states are VALID and REVOKED. The transition from VALID to REVOKED is triggered by the revocation of the artifact, which can be initiated by the corresponding Trust Artifact Provider due to various reasons such as key compromise, organizational changes, or non-compliance with framework policies. Once an artifact is in the REVOKED state, it SHALL NOT be trusted for any operational use within the ecosystem, and any entity relying on it SHALL reject it for authentication, authorization, or any other trust-related operations.
    • A WRPAC in VALID state SHALL NOT be present in the designated CRL and/or SHALL return a good status in the OCSP response. A WRPAC in REVOKED state SHALL be present in the designated CRL and/or SHALL return a revoked status in the OCSP response.
    • A WRPRC in VALID state SHALL return a 0x00 status in the corresponding Status List Token. A WRPRC in REVOKED state SHALL have status value 0x01 within the corresponding Status List Token.
  • For Trust Lists (LoTE, LOTL, TL), the lifecycle states are CURRENT and HISTORICAL. The transition from CURRENT to HISTORICAL is triggered by the publication of a new version of the Trust List that replaces the previous version. Once a Trust List is in the HISTORICAL state, it SHALL NOT be used for any operational use within the ecosystem, the only exception being the validation of Trust List trustworthiness via the pivoting mechanism (see Trust Anchor Validation Process) and the validation of historical operations via the ServiceHistory component of the Trust List.
  • For Registers, EDPs, Status Lists, the lifecycle state is only CURRENT, since any change in these artifacts is reflected as an update of the artifact itself, and the previous version is not retained as a historical record.

The diagram below highlights the state machine of the aforementioned artifacts:

stateDiagram-v2
    %% Define Layout Orientation
    direction TB

    %% 1. Certificates Lifecycle Group
    state "Certificates (WRPAC, WRPRC, Signature/Seal)" as CertGroup {
        [*] --> VALID : Issuance / Provisioning
        VALID --> REVOKED : Revocation Trigger<br>(CRL, OCSP, or Status List)
        REVOKED --> [*] : Terminal State
    }

    %% 2. Trust Lists Lifecycle Group
    state "Trust Lists (LoTE, LOTL, TL)" as TLGroup {
        [*] --> TL_CURRENT : Publication of Current Version
        state "CURRENT" as TL_CURRENT

        TL_CURRENT --> HISTORICAL : Superseded by New Version<br>(The old one is archived to `ServiceHistory`)
        HISTORICAL --> [*]
    }

    %% 3. Registers, EDP, and Status Lists Lifecycle Group
    state "Registers, EDP, and Status Lists" as RegGroup {
        [*] --> REG_CURRENT : Initial Publication
        state "CURRENT" as REG_CURRENT

        REG_CURRENT --> REG_CURRENT : In-place Content Mutation<br>(No History Retained)
    }

The table below summarizes the lifecycle states, their definitions, the applicable Trust Artifacts and Trust Lists, and the technical mean that conveys the validity of these artifacts. The three tables are divided by artifact type since they have different lifecycle states and transition triggers, these are respectively: VALID and REVOKED for WRPAC, WRPRC and Signature/Seal Certificates, CURRENT and HISTORICAL for Trust Lists, and only CURRENT for Registers, EDPs and Status Lists.

State Definition Applicable Artifacts Technical Mean
VALID Indicates that a Trust Artifact is currently valid and can be trusted for operational use within the ecosystem. WRPAC, WRPRC, Signature/Seal Certificates. OCSP response with good status or absence in CRL for WRPACs and Signature/Seal certificates; Status List Token with status set to 0x00 for WRPRCs.
REVOKED Indicates that a Trust Artifact has been revoked and SHALL NOT be trusted for any operational use within the ecosystem. WRPAC, WRPRC, Signature/Seal Certificates. OCSP response with revoked status or presence in CRL for WRPACs and Signature/Seal certificates; Status List Token with status set to 0x01 for WRPRCs.
State Definition Applicable Artifacts Technical Mean
CURRENT Indicates that the current Trust List is the newest version, previous versions are no longer valid for operational use within the ecosystem. LoTE, LOTL, TL, Registers, EDPs, Status Lists. Publication of a new version of the Trust List; resolution of historical status via the ServiceHistory component for LoTE, LOTL, and TL.
HISTORICAL Indicates that a Trust List is a historical record and SHALL NOT be used for any operational use within the ecosystem, except for validating historical operations and trustworthiness via the pivoting mechanism. LoTE, LOTL, TL. Resolution of historical status via the ServiceHistory component; validation of trustworthiness via the pivoting mechanism.
State Definition Applicable Artifacts Technical Mean
CURRENT Indicates that the current version of a Register, EDP, or Status List has the newest information, previous versions are no longer valid, SHOULD NOT be published and SHALL NOT be used for operational use within the ecosystem. Registers, EDPs, Status Lists. Publication of an updated version of the artifact.

Entity Lifecycle Operations

Below are detailed the operational procedures, which affects the Properties of Trust Artifact Provider and End-Entities and the resulting effects on their State.

Onboarding Process

The onboarding process governs the transition of an End-Entity (WRP or Wallet Provider) from the UNREGISTERED state to the REGISTERED state. During the onboarding process, it is up to the Entities running the process and necessary validations to collect the onboardee's Properties and (depending on its role) issue the corresponding Trust Artifacts.

Active Operations and Maintenance

While in the OPERATIONAL state, entities MAY require organizational updates to their registered Properties, including their entity profiles, cryptographic materials, or operational parameters. Below we describe these updates and their operational effects on the trust artifacts and the entity's state.

Organizational Updates

As their organizational or regulatory circumstances evolve, WRPs and Wallet Providers SHALL update identity, authorization information and technical configurations accordingly through the standard channels as defined at Member State or European Commission level. Identity and cryptographic updates SHALL follow standard framework governance processes and SHOULD NOT affect the underlying technical operations of the Trust Framework. In particular, updates that directly affect federation protocol operations or cryptographic trust boundaries require strictly coordinated procedures. These technical updates SHALL be validated by the designated MS authority or EC designated body prior to deployment to maintain trust relationships and ecosystem operational integrity.

Operational Effects of Organizational Updates

When there are organizational updates, the Trust Framework infrastructure SHALL propagate these changes to the relevant trust artifacts. The specific operational effects depend on the entity's role, and the artifacts it utilizes.

WRP Updates: For WRP updating their Identity Information, Technical Configurations, and/or Policies and Authorizations, the update SHALL trigger the following procedures:

Wallet Providers and Trust Artifact Provider Updates: For Wallet Providers, Registrars, Providers of WRPAC/WRPRC updating their Identity Information and/or Technical Configurations, the update SHALL trigger the following procedures:

Removal Process

The Removal process defines the rapid-response workflows and administrative procedures executed to transition an entity from the OPERATIONAL state to the REMOVED state. This transition MAY be initiated voluntarily by the entity or forcefully enacted by the Supervisory Body.

Triggers for Removal

Removal events are categorized based on their initiation source:

  • Voluntary Exit: Organizations MAY choose to exit the federation for standard business or operational reasons. Permitted reasons include:
    • Business Changes: Organizational restructuring, mergers, acquisitions, or complete service discontinuation.
  • Supervisory Body Removal (use the MS, EC, CAB, NAB, DPA bodies): The Supervisory Body MAY initiate a forced Removal due to severe compliance failures, fatal security breaches, or other critical ecosystem threats.
Operational Effects of Removal

When an entity transitions to the REMOVED state, the relevant Trust Artifacts Providers and Scheme Operators SHALL immediately execute the necessary operations to halt the entity's operations while preserving historical evidence. The specific operational effects depend on the entity's role, and the artifacts it utilizes.

WRP Withdrawal or Removal: For WRP withdrawing or being removed from the Trust Framework following security incidents or policy violations, the removal event SHALL trigger the following procedures:

Wallet Providers and Trust Artifact Provider Withdrawal or Removal: For Wallet Providers, Registrars, Providers of WRPAC, Providers of WRPRC updating their Identity Information and/or Technical Configurations, the removal event SHALL trigger the following procedures:

  • LoTE Update: the Trust Artifact Provider or Supervisory Body SHALL notify the LoTE Provider which will publish a new version of the LoTE using the pivoting mechanism without the PID/Pub-EAA/Wallet Provider's ServiceInformation component. To maintain non-repudiation for past transactions, the superseded parameters MAY be retained as historical records within the TrustedEntityServices.ServiceHistory.

Revocation Mechanisms

This section describes the artifacts that are employed in Trust Management and Lifecycle to manage the status of certificates and entities by detailing respective formats and parameters. The main distinction is the following:

Token Status List

This section defines a Status List data structure, which is used to convey information regarding the individual statuses of multiple WRPRCs. A Status List describes the status of the WRPRCs by encoding their validity in a bit array. Each WRPRC is allocated an index during issuance; this index represents its position within the bit array. The value of the bit(s) at this index corresponds to the WRPRC's status. A Status List is provided within a cryptographically signed Status List Token in JWT format. This subsection follows [draft-ietf-oauth-status-list-19].

In this specification, the roles of the Provider of WRPRC and Status Issuer (i.e., the entity that issues the Status List Token about the status information of the WRPRC) SHALL coincide. Moreover, the Status Provider (i.e., the entity that provides the Status List Token on a public endpoint) SHALL be the Provider of WRPRC itself.

The Provider of WRPRC SHALL:

  • Define a number of bits, \(k\), (either 1, 2, 4, or 8) that represents the amount of bits used to describe the status of each WRPRC within this Status List. The Provider of WRPRC SHALL configure this number. Each WRPRC will therefore have \(2^k\) possible states.
  • Create a byte array of size \(\geq\) (expected number of WRPRCs) * \(k\) / 8. Depending on \(k\), each byte in the array corresponds to 8/\(k\) statuses (8 if \(k=1\), 4 if \(k=2\), 2 if \(k=4\), or 1 if \(k=8\)). Each time a WRPRC is issued, the Provider of WRPRC assigns it to a position in the array.
  • Set the status values for all issued WRPRCs within the byte array. The status of each WRPRC is identified using an index that maps to one or more specific bits within the byte array. The index starts counting at 0 and ends with (number of WRPRC) - 1. All bits of the byte array at a particular index are set to a status value.
  • Compress the byte array using DEFLATE [RFC 1951] with the ZLIB [RFC 1950] data format. Implementations are RECOMMENDED to use the highest compression level available.
  • Make an endpoint available to Wallet Units to request Status Lists Tokens.

The Provider of WRPRC SHALL use the following values for the possible statuses of the issued WRPRCs:

  • 0x00 - VALID - The WRPRC is valid.
  • 0x01 - INVALID - The WRPRC is revoked.

For example, if two states for a certain WRPRC are possible, then \(k=1\). If the Attestation Provider creates an array to store the statuses of 6 WRPRCs, whose validity statuses are 0, 0, 0, 1, 1, 0, respectively; then:

  • The bit array can be of the form a=[0, 0, 0, 0, 0, 0, 0, 0; 0, 0, 1, 1, 0, 0, 0, 0; 0, 0, 1, 0, 0, 0, 0, 1] which, in hexadecimal notation, corresponds to the byte array [0x00, 0x30, 0x21].
  • The status values are encoded in specific bit positions based on their assigned index.
  • The array is then compressed using DEFLATE.

Note

When the Provider of WRPRC chooses the number of bits for conveying statuses of the WRPRCs it issues, it MAY add other states besides those described above. The addition of many different states for the lifecycle of a WRPRC SHALL, however, be carefully pondered, as it discloses information to Relying Parties.

Once the Wallet Unit receives a WRPRC, it can request the Status List to validate its status through the provided URI parameter and look up the corresponding index in the list.

Status List Token

The Status List Token is available at the Status List Endpoint. It is formatted as a JSON Web Token (JWT) signed by the Provider of WRPRC and contains the following parameters:

Status List Token Header
Parameter Defined in Presence Format Description
alg [RFC 7515] REQUIRED String A digital signature algorithm identifier per the IANA "JSON Web Signature and Encryption Algorithms" registry. It SHALL NOT be set to none or to a symmetric algorithm (MAC) identifier.
typ [RFC 7515] REQUIRED String Specifies the type of the Web Token. It SHALL be set to statuslist+jwt.
x5c [RFC 7515] REQUIRED Array of Strings Contains the Base64-encoded certificate chain required to verify the Status List Token's signature.
Status List Token Payload
Parameter Defined in Presence Format Description
sub RFC 7519 REQUIRED String The subject claim SHALL specify the URI of the Status List Token. The value SHALL be equal to that of the uri claim contained in the status*list.uri claim of the WRPRC.
iat RFC 7519 REQUIRED NumericDate A timestamp indicating when the Status List Token was issued.
exp RFC 7519 REQUIRED NumericDate A timestamp indicating when the Status List Token expires.
status*list OAuth Status List Draft REQUIRED JSON Object A JSON Object that contains the Status List configurations and payload.
status*list.bits OAuth Status List Draft REQUIRED Integer Specifies the number of bits per WRPRC in the compressed byte array. The allowed values are 1, 2, 4, and 8.
status*list.lst OAuth Status List Draft REQUIRED Base64url-encoded String Contains the status values for all the WRPRCs. The value SHALL be the base64url-encoded compressed byte array.
ttl OAuth Status List Draft RECOMMENDED Integer Time to live claim expressed in seconds. It specifies the maximum amount of time, in seconds, that the Status List Token can be cached by a consumer before a fresh copy SHOULD be retrieved.

The following is an example of the Status List Token payload and header prior to signing and base64url encoding:

Header:

{
  "alg": "ES256",
  "typ": "statuslist+jwt",
  "x5c": [
    "MIIDqjCCApKgAwIBAgIESLNEvDA...",
    "MIICwzCCAasCCQCKVy9eKjvi+jA...",
    "MIIDTDCCAjSgAwIBAgIJAPlnQYH..."
  ]
}

Payload:

{
  "exp": 2291720170,
  "iat": 1686920170,
  "sub": "https://example-issuer.com/statuslists/1",
  "status*list": {
    "bits": 1,
    "lst": "eNrbuRgAAhcBXQ"
  }
}

Status List Request

The Wallet Unit SHALL request a Status List Token at the URI referenced within the status.status_list.uri claim of the WRPRC. The request SHALL use HTTP GET with media type application/statuslist+jwt.

Below it is represented an example of such a request.

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

Status List Response

The successful response SHALL contain a Status List Token and have HTTP status code 200. The content type of the successful response SHALL be application/statuslist+jwt.

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

  eyJhbGciOiJFUzI1NiIsImtpZCI6IjEyIiwidHlwIjoic3RhdHVzbGlzdCtqd3QifQ.e
  yJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9le
  GFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjEsImxzdCI6ImVOcmJ1UmdBQ
  WhjQlhRIn0sInN1YiI6Imh0dHBzOi8vZXhhbXBsZS5jb20vc3RhdHVzbGlzdHMvMSIsI
  nR0bCI6NDMyMDB9.2lKUUNG503R9htu4aHAYi7vjmr3sgApbfoDvPrl65N3URUO1EYqq
  Ql45Jfzd-Av4QzlKa3oVALpLwOEUOq-U*g

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

Certificate Revocation Lists

Certificate Revocation Lists (CRLs) [RFC 5280] MAY be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and an even broader spectrum of operational and assurance requirements.

CRL issuers issue CRLs. The CRL issuer is either the Certificate Authority (CA) or an entity that has been authorized by the CA to issue CRLs.

Note

Within APTITUDE the CRL Issuer SHALL be the Trust Anchor.

CAs publish CRLs to provide status information about the certificates they issued. Each CRL has a particular scope. The CRL scope is the set of certificates that could appear on a given CRL. For example, the scope could be "all certificates issued by CA X". A complete CRL lists all unexpired certificates, within its scope, that have been revoked for one of the revocation reasons covered by the CRL scope.

The CRL issuer MAY also generate delta CRLs. A delta CRL only lists those certificates, within its scope, whose revocation status has changed since the issuance of a referenced complete CRL. The referenced complete CRL is referred to as a base CRL. The scope of a delta CRL SHALL be the same as the base CRL that it references.

If supported by the CA, the CRL SHALL be available at the URI specified in the cRLDistributionPoints.distributionPoint [0] CHOICE structure within the WRPAC.

An X.509 v2 CRL is represented as the ASN.1 DER encoding of the CertificateList SEQUENCE. The ASN.1 DER encoding is a strictly defined tag, length, and value encoding system for each element. The final bytes transmitted represent the DER encoding of the top-level SEQUENCE containing the fields in the following table:

Parameter Defined in Presence Format Description
tbsCertList [RFC 5280, clause 5.1.1.1] REQUIRED SEQUENCE Contains the core CRL information including the name of the issuer, issue date, next update date, the optional list of revoked certificates, and optional CRL extensions.
signatureAlgorithm [RFC 5280, clause 5.1.1.2] REQUIRED SEQUENCE Contains the algorithm identifier for the algorithm used by the CRL issuer to sign the CertificateList. Selection SHOULD align with relevant standards (e.g., [ETSI TS 119 312]).
signatureAlgorithm.algorithm [RFC 5280, clause 4.1.1.2] REQUIRED OBJECT IDENTIFIER The OID of the signature algorithm.
signatureAlgorithm.parameters [RFC 5280, clause 4.1.1.2] OPTIONAL ANY Algorithm-specific parameters, dependent on the signature algorithm used.
signatureValue [RFC 5280, clause 5.1.1.3] REQUIRED BIT STRING Contains the digital signature computed upon the ASN.1 DER encoded tbsCertList.

Certificate List Content

The TBSCertList (To Be Signed Certificate List) is an ASN.1 SEQUENCE containing several fields and extensions. The following table lists all such fields and extensions that are required in a CRL or conditionally required.

Parameter Defined in Presence Format Description
version [RFC 5280, clause 5.1.2.1] OPTIONAL INTEGER Describes the version of the encoded CRL. When extensions are used (as is standard practice), this field SHALL be present and SHALL specify version 2 (the integer value is 1).
signature [RFC 5280, clause 5.1.2.2] REQUIRED SEQUENCE The algorithm identifier for the algorithm used to sign the CRL.
signature.algorithm [RFC 5280, clause 4.1.1.2] REQUIRED OBJECT IDENTIFIER The OID of the signature algorithm. SHALL match the signatureAlgorithm field in the parent CertificateList sequence.
signature.parameters [RFC 5280, clause 4.1.1.2] OPTIONAL ANY Algorithm-specific parameters, dependent on the algorithm used.
issuer [RFC 5280, clause 5.1.2.3] REQUIRED Name Identifies the entity that has signed and issued the CRL. It SHALL contain a non-empty X.500 distinguished name (DN) composed of AttributeType (OID) and AttributeValue sequences.
thisUpdate [RFC 5280, clause 5.1.2.4] REQUIRED UTCTime or GeneralizedTime Indicates the issue date of this CRL. Dates through 2049 SHALL use UTCTime; dates in 2050 or later SHALL use GeneralizedTime.
nextUpdate [RFC 5280, clause 5.1.2.5] REQUIRED UTCTime or GeneralizedTime Indicates the date by which the next CRL will be issued. Dates through 2049 SHALL use UTCTime; dates in 2050 or later SHALL use GeneralizedTime.
revokedCertificates [RFC 5280, clause 5.1.2.6] OPTIONAL SEQUENCE OF A sequence of revoked certificates. When there are no revoked certificates, this field SHALL be absent.
revokedCertificates.userCertificate [RFC 5280, clause 5.1.2.6] REQUIRED INTEGER The CertificateSerialNumber of the revoked certificate.
revokedCertificates.revocationDate [RFC 5280, clause 5.1.2.6] REQUIRED UTCTime or GeneralizedTime The date on which the revocation occurred.
revokedCertificates.crlEntryExtensions [RFC 5280, clause 5.1.2.6] OPTIONAL SEQUENCE OF Extensions specific to this revoked certificate entry. If present, the CRL version SHALL be v2.
crlExtensions [RFC 5280, clause 5.1.2.7] OPTIONAL [0] EXPLICIT SEQUENCE OF A sequence of one or more CRL extensions. If present, the CRL version SHALL be v2.

The crlExtensions field MAY contain various extensions. Notable standard extensions include:

Parameter Defined in Presence Format Description
authorityKeyIdentifier [RFC 5280, clause 5.2.1] REQUIRED SEQUENCE Provides a means of identifying the public key corresponding to the private key used to sign the CRL. Contains keyIdentifier (OCTET STRING), authorityCertIssuer, or authorityCertSerialNumber.
cRLNumber [RFC 5280, clause 5.2.3] REQUIRED INTEGER A non-critical extension conveying a monotonically increasing sequence number for a given CRL scope and issuer.

Note

Within the APTITUDE pilot, Delta CRLs are not used.

Online Certificate Status Protocol

Online Certificate Status Protocol (OCSP) [RFC 6960] enables applications to determine the exact revocation state of identified certificates. It provides more timely revocation information than is typically possible with CRLs and MAY also be used to obtain additional status information.

An OCSP client issues a status request to an OCSP responder and SHALL suspend the acceptance of the certificates in question until the responder provides a valid response.

If supported by the CA, the URI to which the OCSP Responder can be invoked SHALL be present in the authorityInfoAccess.accessLocation extension of the WRPAC.

This protocol specifies the data that SHALL be exchanged between the OCSP client (which checks the status of one or more certificates) and the OCSP server (which provides the corresponding status). In this specific ecosystem, the OCSP client can be a WU checking the WRPAC of a WRP, and the OCSP server is the Provider of the WRPAC.

Online Certificate Status Protocol Request Format

The OCSP request is the ASN.1 DER encoding of the OCSPRequest SEQUENCE, which contains the tbsRequest (To-Be-Signed Request) and an optional signature. The following table lists the parameters found within the tbsRequest structure.

Parameter Defined in Presence Format Description
version [RFC 6960, clause 4.1.1] OPTIONAL [0] EXPLICIT INTEGER Indicates the version of the protocol. If omitted, the default value is v1 (0).
requestList [RFC 6960, clause 4.1.1] REQUIRED SEQUENCE OF Contains one or more single certificate status requests.
requestList.reqCert [RFC 6960, clause 4.1.1] REQUIRED SEQUENCE The CertID structure carrying the identifier of a target certificate.
requestList.singleRequestExtensions [RFC 6960, clause 4.1.1] OPTIONAL [0] EXPLICIT SEQUENCE Includes extensions applicable to this single certificate status request.
requestExtensions [RFC 6960, clause 4.1.1] OPTIONAL [2] EXPLICIT SEQUENCE Includes extensions applicable to the overall requests found within the requestList.

The reqCert parameter utilizes the CertID structure, which is an ASN.1 SEQUENCE containing the following parameters:

Parameter Defined in Presence Format Description
hashAlgorithm [RFC 6960, clause 4.1.1] REQUIRED SEQUENCE Identifies the hash algorithm used to generate the issuer name and key hashes.
hashAlgorithm.algorithm [RFC 6960, clause 4.1.1] REQUIRED OBJECT IDENTIFIER The OID of the hash function (e.g.,SHA-256, depending on the profile).
hashAlgorithm.parameters [RFC 6960, clause 4.1.1] OPTIONAL ANY Algorithm-specific parameters, dependent on the hash algorithm used.
issuerNameHash [RFC 6960, clause 4.1.1] REQUIRED OCTET STRING The hash of the issuer's distinguished name (DN), calculated over the DER encoding of the issuer's name field.
issuerKeyHash [RFC 6960, clause 4.1.1] REQUIRED OCTET STRING The hash of the issuer's public key, calculated over the value (excluding tag and length) of the subject public key field.
serialNumber [RFC 6960, clause 4.1.1] REQUIRED INTEGER The serial number of the target certificate for which the status is being requested.

The requestExtensions and singleRequestExtensions structures MAY contain various extensions. A common extension is the nonce:

Parameter Defined in Presence Format Description
nonce [RFC 6960, clause 4.4.1] REQUIRED OCTET STRING Cryptographically fresh value used to bind a request and a response to prevent replay attacks. Identifier OID is id-pkix-ocsp-nonce.

Note

Within APTITUDE, OCSP requests SHALL use the nonce extension.

When sent over HTTP using POST, the body of this request is the raw DER encoding of this OCSPRequest, with the MIME type application/ocsp-request.

Below is a concrete example of an OCSP request:

OCSPRequest:
  tbsRequest:
    version = v1
    requestList = SEQUENCE OF
      Request:
        reqCert:
          hashAlgorithm:
            algorithm  = sha256
            parameters = null
          issuerNameHash = SHA256( DER-encode(Issuer Name) )
          issuerKeyHash  = SHA256( Issuer SubjectPublicKey BIT STRING )
          serialNumber   = 0x01A2B3C4D5
    requestExtensions:
      nonce = OCTET STRING (nonce)

Online Certificate Status Protocol Response Format

An OCSP response is the ASN.1 DER encoding of the OCSPResponse SEQUENCE. When transported over HTTP, the body of the HTTP response is the raw DER encoding of this OCSPResponse, with the MIME type application/ocsp-response. The OCSPResponse SEQUENCE contains the following parameters:

Parameter Defined in Presence Format Description
responseStatus [RFC 6960, clause 4.2.1] REQUIRED ENUMERATED Indicates the processing status of the prior request. Supported values are: successful (0), malformedRequest (1), internalError (2), tryLater (3), sigRequired (5), and unauthorized (6).
responseBytes [RFC 6960, clause 4.2.1] OPTIONAL [0] EXPLICIT SEQUENCE Present only when the responseStatus is successful (0). Contains the response type and the encoded response data.
responseBytes.responseType [RFC 6960, clause 4.2.1] REQUIRED OBJECT IDENTIFIER Identifier for the response type. For a basic OCSP responder, this value SHALL be id-pkix-ocsp-basic.
responseBytes.response [RFC 6960, clause 4.2.1] REQUIRED OCTET STRING Contains the DER encoding of the response syntax identified by responseType (e.g., the BasicOCSPResponse structure).

Note

Within APTITUDE, OCSP responders SHALL be capable of producing responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type.

BasicOCSPResponse is an ASN.1 SEQUENCE containing the following parameters:

Parameter Defined in Presence Format Description
tbsResponseData [RFC 6960, clause 4.2.1] REQUIRED SEQUENCE Contains the core response data to be signed by the responder.
tbsResponseData.version [RFC 6960, clause 4.2.1] OPTIONAL [0] EXPLICIT INTEGER The version of the response syntax. If omitted, the default value is v1 (0).
tbsResponseData.responderID [RFC 6960, clause 4.2.1] REQUIRED CHOICE Identifies the OCSP responder. It SHALL contain either byName or byKey.
tbsResponseData.responderID.byName [RFC 6960, clause 4.2.1] OPTIONAL [1] EXPLICIT Name The Name from the responder’s certificate subject.
tbsResponseData.responderID.byKey [RFC 6960, clause 4.2.1] OPTIONAL [2] EXPLICIT OCTET STRING The SHA-1 hash of the responder’s subjectPublicKey (excluding the tag and length fields).
tbsResponseData.producedAt [RFC 6960, clause 4.2.1] REQUIRED GeneralizedTime The time at which the OCSP response was generated.
tbsResponseData.responses [RFC 6960, clause 4.2.1] REQUIRED SEQUENCE OF A sequence of SingleResponse structures, providing the status of each requested certificate.
tbsResponseData.responseExtensions [RFC 6960, clause 4.2.1] OPTIONAL [1] EXPLICIT SEQUENCE OF Contains extensions applicable to the overall OCSP response.
signatureAlgorithm [RFC 5280, clause 4.1.1.2] REQUIRED SEQUENCE Identifies the cryptographic algorithm used to sign the response.
signatureAlgorithm.algorithm [RFC 5280, clause 4.1.1.2] REQUIRED OBJECT IDENTIFIER The OID of the signature algorithm. Selection SHOULD align with relevant standards (e.g., [ETSI TS 119 312]).
signatureAlgorithm.parameters [RFC 5280, clause 4.1.1.2] OPTIONAL ANY Algorithm-specific parameters, dependent on the OID defined in algorithm.
signature [RFC 6960, clause 4.2.1] REQUIRED BIT STRING The digital signature computed over the hash of the DER-encoded tbsResponseData.
certs [RFC 6960, clause 4.2.1] OPTIONAL [0] EXPLICIT SEQUENCE OF Certificate chain to help the client verify the responder's signature. If no certificates are included, this field SHOULD be absent.

The responseExtensions structure MAY contain various extensions. A notable parameter often required by specific profiles (such as to prevent replay attacks) is the nonce:

Parameter Defined in Presence Format Description
nonce [RFC 6960, clause 4.4.1] REQUIRED OCTET STRING Cryptographically fresh value used to bind a request and a response to prevent replay attacks. If included in the request, responders SHOULD include it in the response. Identifer OID is id-pkix-ocsp-nonce.

Note

Within APTITUDE, OCSP Responses SHALL use the nonce extension.

In the OCSP Response there SHALL be at least a SingleResponse for each CertID in the request. Each SingleResponse is an ASN.1 SEQUENCE that carries the following parameters:

Parameter Defined in Presence Format Description
certID [RFC 6960, clause 4.2.1] REQUIRED SEQUENCE Identifier of the certificate whose status is determined in certStatus.
certStatus [RFC 6960, clause 4.2.1] REQUIRED CHOICE The value of the certificate's status. It SHALL be exactly one of: good, revoked, or unknown.
certStatus.good [RFC 6960, clause 4.2.1] OPTIONAL [0] IMPLICIT NULL Indicates the certificate is valid.
certStatus.revoked [RFC 6960, clause 4.2.1] OPTIONAL [1] IMPLICIT SEQUENCE Indicates the certificate has been revoked. Contains the RevokedInfo structure.
certStatus.revoked.revocationTime [RFC 6960, clause 4.2.1] REQUIRED GeneralizedTime The time at which the certificate was revoked.
certStatus.revoked.revocationReason [RFC 6960, clause 4.2.1] OPTIONAL [0] EXPLICIT ENUMERATED Contains the CRLReason indicating why the certificate was revoked.
certStatus.unknown [RFC 6960, clause 4.2.1] OPTIONAL [2] IMPLICIT NULL Indicates the responder does not know the status of the certificate.
thisUpdate [RFC 6960, clause 4.2.1] REQUIRED GeneralizedTime Indicates the issue date and time of this OCSP Response.
nextUpdate [RFC 6960, clause 4.2.1] OPTIONAL [0] EXPLICIT GeneralizedTime Indicates the date and time by which the next update to the OCSP Responder database will be in place.
singleExtensions [RFC 6960, clause 4.2.1] OPTIONAL [1] EXPLICIT SEQUENCE Includes extensions applicable to this single certificate status response.

Below is a concrete example of an OCSP response with a single good status.

OCSPResponse:
  responseStatus = successful (0)
  responseBytes:
    responseType = id-pkix-ocsp-basic
    response = DER(BasicOCSPResponse)
      BasicOCSPResponse: 
        tbsResponseData:
          version = v1
          responderID"
            byName: 
             CN = Example OCSP Responder
             O  = Example CA
             C  = CZ
          producedAt = 20250101000000Z
          responses = SEQUENCE OF
            SingleResponse:
              certID:
                hashAlgorithm  = sha1
                issuerNameHash = SHA1( DER-encode(issuer Name) )
                issuerKeyHash  = SHA1( issuer SubjectPublicKey BIT STRING )
                serialNumber   = 0x01A2B3C4D5
              certStatus  = good
              thisUpdate  = 20250101000000Z
              nextUpdate  = 20250102000000Z
              singleExtensions = absent
          responseExtensions:
            nonce = OCTET STRING (nonce)
        signatureAlgorithm = sha256WithRSAEncryption
        signature          = BIT STRING (signature over hash(DER(tbsResponseData)))
        certs              = SEQUENCE OF
            Certificate (responder’s cert, possibly with its issuing CA cert)