Skip to content

Trust Artifacts

Register

This section specifies requirements for the Registrar of WRPs and the national Register of WRPs (the registry service) in the context of eIDAS2 and the EUDI Wallet ecosystem.

Formally, a Registrar is the designated body that:

  • Manages the WRP registration lifecycle (onboarding, update, suspension, cancellation),
  • Ensures the integrity and publication of registration information,
  • Ensures interoperability by exposing WRP registration data via a national website and a single common REST API.

The national Register of WRPs is the publicly accessible system (dataset + API) that provides signed/sealed registration statements about WRPs and their authorisations/declared usage.

Note

The national Register of WRPs is a single logical register. For scalability and resilience, a Member State MAY deploy multiple technical instances provided they expose a single coherent common REST API and return signed statements as required.

Additionally, sectorial registers may exist internally, but the decision regarding issuance of WRPAC is solely based on whether the WRP has been registered with an active status in the national Register.

References

The list below enumerates all the applicable standards and specifications that have been used to populate the table below:

  • CIR 2025/848 on WRP registration and Registers.
  • CIR 2025/848-Amendment. This draft slightly modifies Annexes I-V of [CIR 2025/848] and introduces Annex VI for common API and data schema for Register of WRPs.
  • ETSI TS 119 475 on WRP attributes, entitlement URIs, RP authorisation decision support.
  • RFC 7515
  • RFC 7519
  • RFC 8392
  • TS05 on common formats and API for WRP registration information.
  • TS06 on common set of WRP information to be registered.

Requirements

Register Requirements

ID Requirement Reference
REGISTER-PUB-01 Each Member State SHALL establish and maintain at least one national Register of WRPs. [CIR 2025/848, Article 3(1)]
REGISTER-PUB-02 The Register SHALL include at least the information set out in Annex I of [CIR 2025/848]. [CIR 2025/848, Article 3(2)]
REGISTER-PUB-03 Member States SHALL designate at least one Registrar to manage and operate at least one national Register. [CIR 2025/848, Article 3(3)]
REGISTER-PUB-04 Member States SHALL make Annex I information publicly available online in human-readable and machine-processable form. [CIR 2025/848, Article 3(4)]
REGISTER-PUB-05 Annex I information included in the Register (as for REGISTER-PUB-02) SHALL be available through a national website and a single common API, and SHALL be electronically signed/sealed by/on behalf of the Registrar. [CIR 2025/848, Article 3(5)]
REGISTER-API-01 The single common API SHALL be a REST API supporting JSON, and signed according to [RFC 7515]. [CIR 2025/848, Annex II §2(1)(a)]
REGISTER-API-02 The API SHALL allow any requestor, without prior authentication, to search and request complete lists, allowing partial matches on defined parameters. [CIR 2025/848, Annex II §2(1)(b)]
REGISTER-API-03 Replies to request that match at least one WRP SHALL include statements covering Annex I information [CIR 2025/848], current/historic WRPACs and WRPRCs, excluding Annex I point 4 information. [CIR 2025/848, Annex II §2(1)(c)]
REGISTER-API-04 The API SHALL be published as OpenAPI v3 with documentation enabling interoperability across the Union. [CIR 2025/848, Annex II §2(1)(d)]
REGISTER-API-05 The API SHALL provide security-by-default and by-design to ensure availability and integrity. [CIR 2025/848, Annex II §2(1)(e)]
REGISTER-API-06 Statements referred to in REGISTER-API-03 SHALL be electronically signed/sealed JSON files as for [RFC 7515]. [CIR 2025/848, Annex II §2(2)]

Note

The set of WRP information listed in Annex I of [CIR 2025/848] and mentioned in REGISTER-PUB-05 and REGISTER-API-03 will be described in the Register Data Schema section.

Registrar Requirements

ID Requirement Reference
REGISTRAR-REG-01 Registrars SHALL establish easy-to-use electronic, and where possible automated, registration processes. [CIR 2025/848, Article 6(1)]
REGISTRAR-REG-02 WRPs SHALL provide at least Annex I information to national registers. [CIR 2025/848, Article 5(1)]
REGISTRAR-REG-03 WRPs SHALL ensure information is accurate and SHALL update without undue delay. [CIR 2025/848, Article 5(2)–(3)]
REGISTRAR-REG-04 Where possible, Registrars SHALL verify (automated) accuracy/validity, power of attorney (if applicable), entitlement type(s), and absence of existing registration in another national Register. [CIR 2025/848, Article 6(3)]
REGISTRAR-REG-05 Registrars SHALL verify against supporting documentation or appropriate Authentic Sources/official records. [CIR 2025/848, Article 6(4)]
REGISTRAR-REG-06 Verification of entitlements SHALL be carried out according to Annex III of [CIR 2025/848]. [CIR 2025/848, Article 6(5)]
REGISTRAR-REG-07 If Registrar cannot verify according to Article 6(3)–(5) of [CIR 2025/848], Registrar SHALL reject the registration. [CIR 2025/848, Article 6(6)]
REGISTRAR-GOV-01 Registrars SHALL suspend/cancel a registration of a WRP where requested by a supervisory body (per eIDAS reference). [CIR 2025/848, Article 9(1)]
REGISTRAR-GOV-02 Registrars MAY suspend/cancel a registration of a WRP if info inaccurate/outdated/misleading, non-compliance, excessive attribute requests, breach of law. [CIR 2025/848, Article 9(2)]
REGISTRAR-GOV-03 Registrars SHALL suspend/cancel a registration of a WRP if requested by the WRP itself. [CIR 2025/848, Article 9(3)]
REGISTRAR-GOV-04 Registrar SHALL conduct proportionality assessment before suspension/cancellation under Article 9(2). [CIR 2025/848, Article 9(4)]
REGISTRAR-GOV-05 Registrar SHALL notify WRP and relevant Providers of WRPAC and WRPRC without undue delay and not later than 24 hours. [CIR 2025/848, Article 9(5)]
REGISTRAR-GOV-06 Providers of WRPAC and WRPRC SHALL revoke affected certificates without undue delay after notification (where applicable). [CIR 2025/848, Article 9(6)]
REGISTRAR-GOV-07 Registrars SHALL keep records (Annex I + issuance data + changes) for 10 years. [CIR 2025/848, Article 10]

Provider of WRPAC and WRPRC and Register Interactions Requirements

ID Requirement Reference
PROVIDER-WRPAC-01 Providers of WRPAC SHALL verify at issuance time that the WRP is included with valid registration status in the national Register and certificate info is consistent with Register info. [CIR 2025/848, Annex IV §3(c)]
PROVIDER-WRPAC-02 Providers of WRPAC SHALL continuously monitor changes in the national Register and revoke when changes require (especially suspension/cancellation). [CIR 2025/848, Annex IV §3(e)]
PROVIDER-WRPAC-03 Providers of WRPAC SHALL publish revocation status timely and in any event within 24 hours after receipt of revocation request. [CIR 2025/848, Annex IV §3(h)]
PROVIDER-WRPRC-01 Where a Member State authorises WRPRCs, it SHALL ensure each intended use is expressed in the WRPRC and that WRPRCs include a privacy policy URL and a general access policy. [CIR 2025/848, Article 8(2)(b)–(c) and (g), Article 8(3)]
PROVIDER-WRPRC-02 Providers of WRPRC SHALL verify at issuance time Register status, consistency with Register info, and validity of the WRPAC (when relevant). [CIR 2025/848, Annex V §3(c)]
PROVIDER-WRPRC-03 Providers of WRPRC SHALL monitor Register changes, reissue/revoke when changes require. [CIR 2025/848, Annex V §3(d)]
PROVIDER-WRPRC-04 Data exchange format for WRPRC SHALL be signed JWTs (RFC 7519) and CWTs (RFC 8392), using an Advanced Electronic Signature (AdES) with the B-B profile (JAdES per [ETSI TS 119 182-1] for JWT, COSE for CWT). [CIR 2025/848, Annex V §4]; [ETSI TS 119 475, Section 4.4]

Register Data Schema

This section defines the data schema for each WRP registered in the national Register of WRPs. The values are extracted from Annex VI of the [CIR 2025/848-Amendment].

Address field publication rule

The draft Annex VI text says the published API payload excludes WalletRelyingParty.physicalAddress, while Table 1 uses the attribute name postalAddress. This document uses postalAddress as the schema field name and applies the publication rule to that field (i.e., do not publish it in API statements).

Parameter Type Presence Description
legalPerson LegalPerson REQUIRED if legal person Specific attributes of a legal person. It SHALL be present if the legal entity is a legal person.
naturalPerson NaturalPerson REQUIRED if natural person Specific attributes of a natural person. It SHALL be present if the legal entity is a natural person.
identifier Identifier[] REQUIRED One or more identifiers from official records.
postalAddress string[] OPTIONAL Postal address(es) of the legal entity (registration view only; excluded from published API statements). Note: [ETSI TS 119 475, B.2.2] defines this as [1..1] string; Draft Annex VI Table 1 uses an array. This document follows Draft Annex VI.
country string REQUIRED ISO 3166-1 alpha-2 country code, or "EU" for providers operating in the Union.
email string[] OPTIONAL Contact email address(es) (RFC 5322 format).
phone string[] OPTIONAL Contact phone number(s), international form with + prefix.
infoURI string[] OPTIONAL Web page URI(s) for information about the entity.
providerType string REQUIRED Provider subtype. For WRP records, typically WalletRelyingParty.
policy Policy[] REQUIRED Policy/terms/privacy/registration policy URL(s) with policy type URI.
x5c string[] OPTIONAL X.509 certificate chain(s) for provider services (JWS x5c-style chains; supports rollover).
tradeName string OPTIONAL User-facing trade/service name recognisable to users.
supportURI string[] REQUIRED Support/helpdesk URI(s) for the service.
srvDescription MultiLangString[][] REQUIRED Array of service descriptions, each being an array of localised strings (one inner array per service).
intendedUse IntendedUse[] REQUIRED if the entity is not an intermediary Intended-use definitions and requested attestation data. Not required if registering only as a designated intermediary.
isPSB boolean REQUIRED Whether the WRP is a Public Sector Body (explicitly present; false if not PSB).
entitlement string[] REQUIRED Entitlement URI(s) (see note below).
providesAttestations Credential[] REQUIRED if PID/Attestation Provider Attestation types the WRP intends to issue to wallet units. It SHALL be present if any entitlement is QEAA_Provider, Non_Q_EAA_Provider, PUB_EAA_Provider, or PID_Provider.
supervisoryAuthority LegalEntity REQUIRED Competent supervisory authority (Art. 46a eIDAS) including contact information.
registryURI string REQUIRED URI of the API of the national register of WRPs.
usesIntermediary WalletRelyingParty[] OPTIONAL If present, indicates designated intermediary(ies). Only the subset {identifier, tradeName, registryURI} is needed for each intermediary reference.
isIntermediary boolean REQUIRED Whether the registered entity is a designated intermediary. SHALL be false if usesIntermediary is present.

Note

Mapping between CIR entitlement label and [ETSI TS 119 475, Annex A.2] normative URI:

CIR entitlement label Normative URI
Service_Provider https://uri.etsi.org/19475/Entitlement/Service_Provider
QEAA_Provider https://uri.etsi.org/19475/Entitlement/QEAA_Provider
Non_Q_EAA_Provider https://uri.etsi.org/19475/Entitlement/Non_Q_EAA_Provider
PUB_EAA_Provider https://uri.etsi.org/19475/Entitlement/PUB_EAA_Provider
PID_Provider https://uri.etsi.org/19475/Entitlement/PID_Provider
QCert_for_ESeal_Provider https://uri.etsi.org/19475/Entitlement/QCert_for_ESeal_Provider
QCert_for_ESig_Provider https://uri.etsi.org/19475/Entitlement/QCert_for_ESig_Provider
rQSigCDs_Provider https://uri.etsi.org/19475/Entitlement/rQSigCDs_Provider
rQSealCDs_Provider https://uri.etsi.org/19475/Entitlement/rQSealCDs_Provider
ESig_ESeal_Creation_Provider https://uri.etsi.org/19475/Entitlement/ESig_ESeal_Creation_Provider

[ETSI TS 119 475, Annex A.3] defines additional sub-entitlement URIs for specific service provider roles. For example, Payment Service Provider sub-entitlements include:

Sub-entitlement URI
Account Servicing PSP https://uri.etsi.org/19475/SubEntitlement/psp/psp-as
Payment Initiation Service Provider https://uri.etsi.org/19475/SubEntitlement/psp/psp-pi
Account Information Service Provider https://uri.etsi.org/19475/SubEntitlement/psp/psp-ai
PSP issuing card-based payment instruments https://uri.etsi.org/19475/SubEntitlement/psp/psp-ic
Unspecified PSP https://uri.etsi.org/19475/SubEntitlement/psp/unspecified

Future editions may define additional sub-entitlements at national or EU level.

Identifier

Parameter Type Presence Description
identifier string REQUIRED Identifier value of the LegalEntity.
type string REQUIRED Identifier scheme/type URI (see normative URIs below).

Normative identifier type URIs defined in [ETSI TS 119 475]:

Label Normative URI Description
EORI-No http://data.europa.eu/eudi/id/EORI-No Economic Operator Registration and Identification Number according to (EU) No 1352/2013.
LEI http://data.europa.eu/eudi/id/LEI Legal Entity Identifier according to (EU) 2022/1860; [ISO 17442-1].
EUID http://data.europa.eu/eudi/id/EUID European Unique Identifier according to (EU) 2020/2244; (EU) 2021/1042.
VATIN http://data.europa.eu/eudi/id/VATIN Value Added Tax Identification Number according to Council Directive 2006/112/EC.
TIN http://data.europa.eu/eudi/id/TIN Taxpayer Identification Number.
Excise http://data.europa.eu/eudi/id/Excise Excise Number according to Art. 2 (12) of the Council Regulation (EC) No 389/2012.

Note

Additional type identifiers may be defined at national or EU level.

MultiLangString

Parameter Type Presence Description
lang string REQUIRED Language tag (e.g., en, fr).
content string REQUIRED Language-specific content.

IntendedUse

Parameter Type Presence Description
intendedUseIdentifier string REQUIRED Registry-level unique identifier for the intended use.
purpose MultiLangString[] REQUIRED Description of intended use of the data to request from wallet units.
privacyPolicy Policy[] REQUIRED Privacy policy URL(s) for the intended use.
credential Credential[] REQUIRED Machine-readable list of requested data (attestations/attributes).
createdAt string REQUIRED Validity start date of the intended use in accordance with ISO86011 YYYY-MM-DD format.
revokedAt string OPTIONAL End date for the validity of the intended use in accordance with ISO86011 YYYY-MM-DD format.

Policy

Parameter Type Presence Description
type string REQUIRED Policy type URI (RFC 3986). See defined policy type URIs below.
policyURI string REQUIRED URL where the policy is published.

Defined policy type URIs:

Policy type URI Reference
Privacy policy http://data.europa.eu/eudi/policy/privacy-policy [ETSI TS 119 475, B.2.8]; [CIR 2025/848, Article 8(2)(g)]
Terms and conditions http://data.europa.eu/eudi/policy/terms-and-conditions [CIR 2025/848-Amendment, Annex VI, Table 7]
Privacy statement (intended use) http://data.europa.eu/eudi/policy/privacy-statement [CIR 2025/848-Amendment, Annex VI, Table 7]

Note

Additional policy type URIs may be defined at national or EU level.

Credential

Parameter Type Presence Description
format string REQUIRED Credential format identifier (e.g., dc+sd-jwt, mso_mdoc).
meta object REQUIRED Additional grouping/type metadata defined per credential format (e.g., {"vct": "..."} for dc+sd-jwt, {"doctype_value": "..."} for mso_mdoc). See OpenID4VP §6.1.
claim Claim[] OPTIONAL Requested claim paths and allowed values (if constrained).

Claim

Parameter Type Presence Description
path array REQUIRED Non-empty path array of strings / null / non-negative integers (OpenID4VP-style path pointer segments).
values array OPTIONAL Optional allowed values; elements may be string, integer, or boolean.

LegalEntity (for supervisoryAuthority)

Parameter Type Presence Description
legalPerson LegalPerson OPTIONAL Present when the authority is a legal person.
naturalPerson NaturalPerson OPTIONAL Present when the authority is a natural person.
identifier Identifier[] OPTIONAL Identifier(s) of the authority.
postalAddress string[] OPTIONAL Postal address(es) of the authority.
country string REQUIRED Country code (or EU where applicable).
email string[] OPTIONAL Email address(es) of the authority.
phone string[] OPTIONAL Phone number(s) of the authority.
infoURI string[] OPTIONAL Information URI(s) of the authority.

LegalPerson

Parameter Type Presence Description
legalName string[] REQUIRED Legal name(s) as in official records.
establishedBylaw Law[] REQUIRED if PSBs responsible for Authentic Sources Legal basis for establishment. It SHALL be present for PSBs responsible for Authentic Sources; present for other PSBs where applicable.

NaturalPerson

Parameter Type Presence Description
givenName string REQUIRED Current first name(s), including middle names where applicable.
familyName string REQUIRED Current surname(s).
dateOfBirth string OPTIONAL Date of birth (where present in official records).
placeOfBirth string OPTIONAL Place of birth (where present in official records).

Law

Parameter Type Presence Description
lang string REQUIRED Two-letter language code (ISO 639-1 style).
legalBasis string REQUIRED Legal basis text establishing the legal person (or requiring/recommending access to a claim).

Non-normative example: WRP object for a Relying Party

A bank registered as a service provider (requesting PID for KYC).

{
  "legalPerson": {
    "legalName": ["ExampleBank S.A."]
  },
  "identifier": [
    {
      "type": "http://data.europa.eu/eudi/id/EUID",
      "identifier": "FR-EUID-123456789"
    },
    {
      "type": "http://data.europa.eu/eudi/id/VATIN",
      "identifier": "FR12345678901"
    }
  ],
  "postalAddress": [
    "10 Rue Exemple, 75000 Paris, FR"
  ],
  "country": "FR",
  "email": [
    "wallet-rp-registration@examplebank.eu"
  ],
  "phone": [
    "+33100000000"
  ],
  "infoURI": [
    "https://examplebank.eu"
  ],
  "providerType": "WalletRelyingParty",
  "policy": [
    {
      "type": "http://data.europa.eu/eudi/policy/terms-and-conditions",
      "policyURI": "https://examplebank.eu/terms"
    },
    {
      "type": "http://data.europa.eu/eudi/policy/privacy-policy",
      "policyURI": "https://examplebank.eu/privacy"
    }
  ],
  "tradeName": "ExampleBank Mobile",
  "supportURI": [
    "https://examplebank.eu/support"
  ],
  "srvDescription": [
    [
      { "lang": "en", "content": "Retail banking services for individuals." },
      { "lang": "fr", "content": "Services bancaires pour particuliers." }
    ]
  ],
  "isPSB": false,
  "entitlement": [
    "https://uri.etsi.org/19475/Entitlement/Service_Provider"
  ],
  "supervisoryAuthority": {
    "legalPerson": {
      "legalName": ["Autorité de supervision Exemple"]
    },
    "country": "FR",
    "email": ["contact@supervisor.example.fr"],
    "infoURI": ["https://supervisor.example.fr"]
  },
  "registryURI": "https://registry.example.fr/api",
  "isIntermediary": false,
  "intendedUse": [
    {
      "intendedUseIdentifier": "iu-001",
      "purpose": [
        { "lang": "en", "content": "Open a bank account remotely." }
      ],
      "privacyPolicy": [
        {
          "type": "http://data.europa.eu/eudi/policy/privacy-statement",
          "policyURI": "https://examplebank.eu/privacy/wallet"
        }
      ],
      "credential": [
        {
          "format": "dc+sd-jwt",
          "meta": {
            "vct": "https://example.eu/schema/pid"
          },
          "claim": [
            { "path": ["family_name"] },
            { "path": ["given_name"] },
            { "path": ["birth_date"] }
          ]
        }
      ],
      "createdAt": "2026-01-01"
    }
  ]
}

Non-normative example: WRP object for a Relying Party that is also an Attestation Provider

A bank registered as both a service provider (requesting PID for KYC) and a QEAA_Provider (issuing bank account attestations to wallet units). It has both intendedUse and providesAttestations.

{
  "legalPerson": {
    "legalName": ["ExampleBank S.A."]
  },
  [...as previous example...] 
  "srvDescription": [
    [
      { "lang": "en", "content": "Retail banking services for individuals." },
      { "lang": "fr", "content": "Services bancaires pour particuliers." }
    ],
    [
      { "lang": "en", "content": "Issuance of qualified bank account attestations." },
      { "lang": "fr", "content": "Délivrance d'attestations de compte bancaire qualifiées." }
    ]
  ],
  "isPSB": false,
  "entitlement": [
    "https://uri.etsi.org/19475/Entitlement/Service_Provider",
    "https://uri.etsi.org/19475/Entitlement/QEAA_Provider"
  ],
  "providesAttestations": [
    {
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": ["https://examplebank.eu/schema/bank-account"]
      },
      "claim": [
        { "path": ["iban"] },
        { "path": ["account_holder_name"] },
        { "path": ["account_type"] },
        { "path": ["currency"] }
      ]
    }
  ],
  "intendedUse": [
    {
      "intendedUseIdentifier": "iu-account-opening",
      "purpose": [
        { "lang": "en", "content": "Open a bank account remotely." },
        { "lang": "fr", "content": "Ouvrir un compte bancaire à distance." }
      ],
      "privacyPolicy": [
        {
          "type": "http://data.europa.eu/eudi/policy/privacy-statement",
          "policyURI": "https://examplebank.eu/privacy/wallet/account-opening"
        }
      ],
      "credential": [
        {
          "format": "dc+sd-jwt",
          "meta": { "vct_values": ["https://example.eu/schema/pid"] },
          "claim": [
            { "path": ["family_name"] },
            { "path": ["given_name"] },
            { "path": ["birth_date"] },
            { "path": ["nationalities"] }
          ]
        }
      ],
      "createdAt": "2026-01-01"
    },
    {
      "intendedUseIdentifier": "iu-bank-account-attestation-issuance",
      "purpose": [
        {
          "lang": "en",
          "content": "Verify wallet holder identity to issue a bank account attestation."
        }
      ],
      "privacyPolicy": [
        {
          "type": "http://data.europa.eu/eudi/policy/privacy-statement",
          "policyURI": "https://examplebank.eu/privacy/wallet/attestation-issuance"
        }
      ],
      "credential": [
        {
          "format": "dc+sd-jwt",
          "meta": { "vct_values": ["https://example.eu/schema/pid"] },
          "claim": [
            { "path": ["family_name"] },
            { "path": ["given_name"] },
            { "path": ["birth_date"] }
          ]
        }
      ],
      "createdAt": "2026-01-01"
    }
  ],
  "supervisoryAuthority": {
    "legalPerson": {
      "legalName": ["Autorité de supervision Exemple"]
    },
    "country": "FR",
    "email": ["contact@supervisor.example.fr"],
    "infoURI": ["https://supervisor.example.fr"]
  },
  "registryURI": "https://registry.example.fr/api",
  "isIntermediary": false
}

Non-normative example: WRP object for a designated Intermediary

An entity registered as a designated Intermediary that acts on behalf of WRPs during Wallet interactions. It has isIntermediary: true and does not declare intendedUse (not required when registering solely as an intermediary).

{
  "legalPerson": {
    "legalName": ["TrustBridge Services B.V."]
  },
  "identifier": [
    {
      "type": "http://data.europa.eu/eudi/id/EUID",
      "identifier": "NL-EUID-112233445"
    },
    {
      "type": "http://data.europa.eu/eudi/id/VATIN",
      "identifier": "NL112233445B01"
    }
  ],
  "postalAddress": [
    "Keizersgracht 100, 1015 CN Amsterdam, NL"
  ],
  "country": "NL",
  "email": ["wallet-intermediary@trustbridge.example"],
  "phone": ["+31200000000"],
  "infoURI": ["https://trustbridge.example"],
  "providerType": "WalletRelyingParty",
  "policy": [
    {
      "type": "http://data.europa.eu/eudi/policy/terms-and-conditions",
      "policyURI": "https://trustbridge.example/terms"
    },
    {
      "type": "http://data.europa.eu/eudi/policy/privacy-policy",
      "policyURI": "https://trustbridge.example/privacy"
    }
  ],
  "tradeName": "TrustBridge",
  "supportURI": ["https://trustbridge.example/support"],
  "srvDescription": [
    [
      {
        "lang": "en",
        "content": "Intermediary services for wallet-relying parties operating in the Netherlands."
      },
      {
        "lang": "nl",
        "content": "Intermediaire diensten voor wallet-relying parties in Nederland."
      }
    ]
  ],
  "isPSB": false,
  "entitlement": [
    "https://uri.etsi.org/19475/Entitlement/Service_Provider"
  ],
  "supervisoryAuthority": {
    "legalPerson": {
      "legalName": ["Autoriteit Persoonsgegevens"]
    },
    "country": "NL",
    "email": ["info@autoriteitpersoonsgegevens.nl"],
    "infoURI": ["https://autoriteitpersoonsgegevens.nl"]
  },
  "registryURI": "https://registry.example.nl/api",
  "isIntermediary": true
}

Non-normative example: WRP object for a WRP using a designated Intermediary

A small e-commerce business that relies on TrustBridge (see example above) to conduct Wallet interactions on its behalf. It has usesIntermediary pointing to the Intermediary's registry entry, and isIntermediary: false.

{
  "legalPerson": {
    "legalName": ["ShopExample N.V."]
  },
  "identifier": [
    {
      "type": "http://data.europa.eu/eudi/id/EUID",
      "identifier": "NL-EUID-556677889"
    }
  ],
  "postalAddress": [
    "Damrak 50, 1012 LP Amsterdam, NL"
  ],
  "country": "NL",
  "email": ["wallet-rp@shopexample.example"],
  "infoURI": ["https://shopexample.example"],
  "providerType": "WalletRelyingParty",
  "policy": [
    {
      "type": "http://data.europa.eu/eudi/policy/terms-and-conditions",
      "policyURI": "https://shopexample.example/terms"
    },
    {
      "type": "http://data.europa.eu/eudi/policy/privacy-policy",
      "policyURI": "https://shopexample.example/privacy"
    }
  ],
  "tradeName": "ShopExample",
  "supportURI": ["https://shopexample.example/support"],
  "srvDescription": [
    [
      { "lang": "en", "content": "Online retail services." },
      { "lang": "nl", "content": "Online detailhandel." }
    ]
  ],
  "isPSB": false,
  "entitlement": [
    "https://uri.etsi.org/19475/Entitlement/Service_Provider"
  ],
  "intendedUse": [
    {
      "intendedUseIdentifier": "iu-age-verification",
      "purpose": [
        { "lang": "en", "content": "Verify the customer is of legal age for restricted product purchases." }
      ],
      "privacyPolicy": [
        {
          "type": "http://data.europa.eu/eudi/policy/privacy-statement",
          "policyURI": "https://shopexample.example/privacy/wallet"
        }
      ],
      "credential": [
        {
          "format": "mso_mdoc",
          "meta": {
            "doctype_value": "org.iso.18013.5.1.mDL"
          },
          "claim": [
            { "path": ["org.iso.18013.5.1", "age_over_18"] }
          ]
        }
      ],
      "createdAt": "2026-01-01"
    }
  ],
  "supervisoryAuthority": {
    "legalPerson": {
      "legalName": ["Autoriteit Persoonsgegevens"]
    },
    "country": "NL",
    "infoURI": ["https://autoriteitpersoonsgegevens.nl"]
  },
  "registryURI": "https://registry.example.nl/api",
  "isIntermediary": false,
  "usesIntermediary": [
    {
      "identifier": [
        {
          "type": "http://data.europa.eu/eudi/id/EUID",
          "identifier": "NL-EUID-112233445"
        }
      ],
      "tradeName": "TrustBridge",
      "registryURI": "https://registry.example.nl/api"
    }
  ]
}

Common Register API

This section documents a [TS05] aligned common Register API profile that satisfies [CIR 2025/848, Annex II] and [CIR 2025/848-Amendment] constraints.

Note

The OpenAPI Specification (OAS) of the API described in this section is available in this page.

API Methods on Registration and Updating of WRP Data

The common API write methods (POST, PUT and DELETE) are defined for purposes of managing the Register information of MS Registrars.

Note

These methods SHALL be accessible by authorised users only.

POST /wrp — create (REQUIRED)

POST is for creating a new WRP entry in the Register. Method expects a request body with the WalletRelyingParty schema, and returns a 201 on success.

Request (body)

Type Presence Description
WalletRelyingParty REQUIRED Full WRP object compliant with [CIR 2025/848-Amendment, Annex VI, Table 1] schema.

Response

HTTP Code Description
201 Created.
400 Bad request (invalid or incomplete payload).
401 Unauthorized (missing or invalid authentication).
403 Forbidden (caller not authorised by Member State).
PUT /wrp — update (REQUIRED)

PUT is for updating an existing WRP entry in the Register. Method expects a request body with the WalletRelyingParty schema, and can return 200 on success or 404 if not found.

Request (body)

Type Presence Description
WalletRelyingParty REQUIRED Full WRP object compliant with [CIR 2025/848-Amendment, Annex VI, Table 1] schema.

Response

HTTP Code Description
200 Successfully updated.
400 Bad request (invalid or incomplete payload).
401 Unauthorized (missing or invalid authentication).
403 Forbidden (caller not authorised by Member State).
404 Not found.
DELETE /wrp — delete (REQUIRED)

DELETE is for deleting an existing WRP entry in the Register. Method expects a request body with the WalletRelyingParty identifier, and returns a 204 on success.

Request (body)

Parameter Presence Description
identifier REQUIRED Identifier payload for the WRP to delete (profile-defined body shape, based on WalletRelyingParty.identifier).

Warning

For [TS05] and [CIR 2025/848-Amendment], this method expects a request body with the WalletRelyingParty identifier, while in the corresponding YAML file ts5-openapi31-registrar-api.yml the identifier is sent as a query parameter. This profile follows the [CIR 2025/848-Amendment].

Response

HTTP Code Description
204 Successfully deleted.
400 Bad request (invalid or incomplete payload).
401 Unauthorized (missing or invalid authentication).
403 Forbidden (caller not authorised by Member State).
404 Not found.

API Methods for Register Queries (Open API)

The common API read methods (GET) SHALL be open for public access (no prior authentication) and returns JWS-signed statements.

The public API SHALL provide methods for searching and querying complete data sets of registered WRPs matching with provided query parameters

GET /wrp — search/list (REQUIRED)

Get a list of WRPs (with optional filtering and pagination, list of all registered WRPs returned when no query parameters are provided).

Request (query parameters)

The common API SHALL support parameterised queries on GET /wrp. The following names align with the [CIR 2025/848-Amendment, Annex VI] query parameter naming.

Parameter Type Presence Description
identifier string OPTIONAL Filter by official/business registration number / identifier.
legalname string OPTIONAL Filter by official company name.
tradename string OPTIONAL Filter by trade name.
policy string OPTIONAL Filter by privacy policy URL (or policy URI as profiled).
entitlement string OPTIONAL Filter by entitlement type (URI).
usesintermediary string OPTIONAL Filter by intermediary identifier.
isintermediary boolean OPTIONAL Filter by intermediary status.
intendeduseidentifier string OPTIONAL Filter by registrar-provided intended-use identifier.
claimpath string OPTIONAL Filter by intended-use requested claim path.
credentialmeta string OPTIONAL Filter by intended-use credential metadata (format-specific).
credentialformat string OPTIONAL Filter by intended-use credential format.
cursor string OPTIONAL Cursor for pagination (profile-defined token format).
limit integer OPTIONAL The number of items to return per page (profile-defined).
providesattestation Credential OPTIONAL Filter by attestation types provided.

Warning

The name of some query parameters differ from [TS05] and the corresponding YAML file ts5-openapi31-registrar-api.yml containing the OpenAPI specification of the JSON and REST based application programming interfaces (e.g., intendedusecredentialmeta vs credentialmeta). This profile follows the OpenAPI specification.

In addition, this specification adds providesattestation to cover the [CIR 2025/848-Amendment] requirement for filtering parameter: type of attestations provided, returning the complete data set of each of the registered wallet-relying parties matching the value provided for this parameter.

Requirement
If no query parameters are provided, GET /wrp SHALL return the full list of registered WRPs (subject to pagination profile).
The endpoint SHALL support cursor-based pagination.
The endpoint SHALL support combined filters in a single query.

Response A successful response (200) SHALL be JWS-signed response body.

HTTP Code Media Type Description
200 application/jwt JWS compact string. Decoded payload SHALL contain an array of WalletRelyingParty objects (matching the query), with address field excluded from published entries, and, where relevant, accompanied by WRPAC history information in the statement/profile used by the Member State. (strict Annex VI form: array; profile envelope also allowed if documented).

Note

The published API view excludes only postalAddress ([CIR 2025/848-Amendment, Annex I, point 4]). All other fields, including intended-use credential claims, are published as registered.

GET /wrp/check-intended-use — intended use check (REQUIRED)

A dedicated intended-use check endpoint for making narrowed-down intended use related queries from the Register.

Request

This profile uses the following mapping (strictly aligned names for intended-use filters):

Parameter Type Presence Description
rpidentifier string REQUIRED Identifier of the WRP whose intended-use registration is being checked.
intendeduseidentifier string OPTIONAL Intended-use identifier registered by the registrar.
claimpath string OPTIONAL Requested claim path to check (serialised representation of path array; profile-defined encoding).
credentialformat string OPTIONAL Credential format to check.
credentialmeta string OPTIONAL Credential metadata filter (profile-defined serialisation).
policyurl string OPTIONAL Used when checking if the privacy policy URL is registered for the identified WRP.

Response

HTTP Code Media Type Description
200 application/jwt JWS compact string; decoded payload is boolean true or false.
400 - Bad request (invalid or incomplete request parameter).
404 - WRP with the given rpidentifier not found.
GET /wrp/{identifier} — get by identifier (OPTIONAL)

Get WRP by identifier.

Note

This endpoint is useful, but it is not explicitly defined in the [CIR 2025/848-Amendment, Annex VI] common API method list. If kept, mark it as a national/profile extension.

Request (query)

Parameter Type Presence Description
identifier string REQUIRED Identifier of the WRP to retrieve.

Response

HTTP Code Media Type Description
200 application/jwt JWS compact string; decoded payload contains one WalletRelyingParty entry (or profile envelope).
404 - Not found.

To preserve issuer/timestamp metadata and pagination in a stable schema, a Member State MAY define an envelope profile as follows (while still satisfying the endpoint semantics above):

SignedWRPArrayEnvelope (profile)
Parameter Type Presence Description
iss string REQUIRED Identifier of the Registry/Registrar issuing the statement.
iat integer REQUIRED Issued-at timestamp (Unix epoch seconds).
data WRPEntry[] REQUIRED Matching WRP entries (published view, address excluded), each bundled with its certificate history.
pagination Pagination OPTIONAL Cursor-based pagination metadata.
WRPEntry (per-WRP bundle)
Parameter Type Presence Description
wrp WalletRelyingParty REQUIRED WRP registration information (published view, address excluded).
wrpacHistory CertificateHistoryEntry[] OPTIONAL WRP access certificate history for this WRP (including CT-related references where available).
wrprcHistory CertificateHistoryEntry[] OPTIONAL WRP registration certificate history for this WRP (if provided by national profile).
SignedWRPEnvelope (profile, for non-common helper endpoints)
Parameter Type Presence Description
iss string REQUIRED Registry/Registrar identifier.
iat integer REQUIRED Issued-at timestamp.
data WalletRelyingParty REQUIRED Single WRP object (published view, address excluded).
wrpacHistory CertificateHistoryEntry[] OPTIONAL WRPAC history.
wrprcHistory CertificateHistoryEntry[] OPTIONAL WRPRC history (if supported).
SignedIntendedUseCheckEnvelope (profile)

Note

Annex VI strictly allows a JWS-signed boolean response. This object envelope is a non-normative profile convenience.

Parameter Type Presence Description
iss string REQUIRED Registry issuer.
iat integer REQUIRED Issued-at timestamp.
data boolean REQUIRED Result of intended-use check.
CertificateHistoryEntry (profile helper for certificate histories)
Parameter Type Presence Description
certificate string REQUIRED Certificate (e.g., PEM/DER-encoded representation, profile-defined).
x5c string[] OPTIONAL Certificate chain for the certificate entry.
status string REQUIRED Certificate status (e.g., current, revoked, expired, historic).
validFrom string OPTIONAL Validity start timestamp/date (profile-defined format).
validTo string OPTIONAL Validity end timestamp/date (profile-defined format).
ctLogEntries object[] OPTIONAL CT log / transparency references ([RFC 9162]-aligned, profile-defined structure).

Wallet-Relying Party Access Certificate

This section describes the purpose, format and content of Wallet-Relying Party Access Certificates (WRPACs).

According to the Article 2 of CIR (EU) 2025/848, a WRPAC, is a certificate for electronic seals or signatures authenticating and validating the Wallet-Relying Party (WRP). Issued by one or more designated providers under Member State supervision, the WRPAC serves to authenticate and verify the trustworthiness of the WRP when they interact with the EUDI Wallet. For more details on the authentication process, see Authentication Process. The suspension or cancellation of the WRP services, involves revocation of all valid WRPACs by the relevant issuing authority, such that the WRP is no longer able to interact with Wallet Units. For more detail on the Trust Management processes, see Trust Management and Lifecycle.

The Annex IV of [CIR 2025/848] also states that the WRPACs are meant for performing electronic signatures or seals and that they shall comply with at least the Normalised Certificate Policy (NCP) requirements specified in the ETSI standards. Taking into account these minimal requirements, different scenarios are possible and specified in the following clauses: certificates issued to natural or legal persons, supporting advanced signatures/seals or even qualified signature/seals. Conditional requirements are defined according to the specific case the WRPACs fall into.

References

To guarantee the interoperability across all the wallets provided within the Union, WRPACs should adhere to common requirements, with respect to their content and format. The technical standard specific to these certificates is [ETSI TS 119 411-8]. However, multiple other standards are referenced either directly or indirectly by [ETSI TS 119 411-8], containing requirements that are applicable to WRPACs as well. The list below enumerates all the applicable standards and specifications that have been used to populate the table below:

  • CIR 2025/848
  • ETSI EN 319 411-1
  • ETSI EN 319 411-2 (applicable if the certificate is qualified)
  • ETSI EN 319 412-1
  • ETSI EN 319 412-2 (applicable if the certificate is issued to natural persons)
  • ETSI EN 319 412-3 (applicable if the certificate is issued to legal persons)
  • ETSI EN 319 412-5 (applicable if the certificate is qualified)
  • ETSI TS 119 411-8
  • RFC 3647
  • RFC 3739
  • RFC 5280
  • RFC 9608

Dependency Considerations

The WRPAC attributes SHALL be derived from the information held in the Register as specified in clause 5.1.2 of [ETSI TS 119 475]. This also implies that for some specific attributes in the WRPAC the same value SHALL be encountered in the corresponding Wallet-Relying Party Registration Certificate if any.

Wallet Relying Party Access Certificate Content

The following table lists all the parameters and extensions that are mandatory in a WRPAC or mandatory with conditions. Optional parameters are not referenced and are not recommended, since they could cause conflicts with the content specified.

The column "Presence" contains the specification of the presence of the certificate parameter as follows:

  • REQUIRED: The parameter SHALL be present.
  • REQUIRED (C): The parameter SHALL be present if the condition specified in the "Description" column is fulfilled.
Parameter Defined in Presence Format Description
version [RFC 5280, clause 4.1.2.1] REQUIRED [0] EXPLICIT INTEGER Indicates the version of the encoded certificate. For this profile, it SHALL be v3 (2).
serialNumber [RFC 5280, clause 4.1.2.2] REQUIRED INTEGER The serial number of the certificate.
signature [RFC 5280, clause 4.1.2.3] REQUIRED SEQUENCE Identifies the signature algorithm used by the CA to sign the certificate. The signature algorithm SHOULD be selected according to [ETSI TS 119 312], but MAY be superseded by national recommendations.
signature.algorithm [RFC 5280, clause 4.1.1.2] REQUIRED OBJECT IDENTIFIER The OID of the signature algorithm.
signature.parameters [RFC 5280, clause 4.1.1.2] OPTIONAL ANY Algorithm-specific parameters, dependent on the algorithm used.
issuer [ETSI EN 319 412-2, clause 4.2.3] REQUIRED Name Identifies the entity that has signed and issued the certificate.

If the issuer is a legal person, the following attributes SHALL be present:
  • countryName indicating the country in which the issuer of the certificate is established;
  • organizationName indicating the full registered name of the certificate issuing organization;
  • commonName indicating a name commonly used by the subject to represent itself;
  • conditionally, an organizationIdentifier if an appropriate registration number is known to exist and it has a value different from the organization name.

If the issuer is a natural person, the following attributes SHALL be present:
  • countryName indicating a country that is consistent with the legal jurisdiction under which certificates are issued;
  • choice of (givenName and/or surname) or pseudonym; if the given name or surname of the issuer is known, the respective attribute SHALL be present;
  • commonName;
  • serialNumber.
validity [RFC 5280, clause 4.1.2.5] REQUIRED SEQUENCE Time interval during which the CA warrants that it will maintain information about the status of the certificate.
validity.notBefore [RFC 5280, clause 4.1.2.5] REQUIRED UTCTime or GeneralizedTime The date on which the certificate validity period begins. Dates through 2049 SHALL use UTCTime; dates in 2050 or later SHALL use GeneralizedTime.
validity.notAfter [RFC 5280, clause 4.1.2.5] REQUIRED UTCTime or GeneralizedTime The date on which the certificate validity period ends. Dates through 2049 SHALL use UTCTime; dates in 2050 or later SHALL use GeneralizedTime.
subject [ETSI EN 319 412-2, clause 4.2.4],
[ETSI EN 319 412-3, clause 4.2.1]		 REQUIRED Name Identifies the entity associated with the public key stored in the subject public key field. If present, the size of organizationName, organizationalUnitName and commonName MAY be longer than the limit as stated in [RFC 5280].

If the subject is a natural person, the following attributes SHALL be present:
  • countryName indicating the general context in which other attributes are to be understood;
  • choice of (givenName and/or surname) or pseudonym;
  • commonName indicating a name of the subject;
  • conditionally, serialNumber if the above attributes are not sufficient to ensure subject name uniqueness.
When a natural person subject is associated with an organization, the attributes MAY also identify such organization using attributes like organizationName and organizationIdentifier.

If the subject is a legal person, the following attributes SHALL be present:
  • countryName indicating the country in which the subject is established;
  • organizationName indicating the full registered name of the subject;
  • organizationIdentifier indicating an identification of the subject organization different from the organization name;
  • commonName indicating a name commonly used by the subject to represent itself.
subjectPublicKeyInfo [RFC 5280, clause 4.1.2.7] REQUIRED SEQUENCE Carries the public key and identifies the algorithm with which the key is used. The subject public key SHOULD be selected according to [ETSI TS 119 312] but MAY be superseded by national recommendations.
subjectPublicKeyInfo.algorithm [RFC 5280, clause 4.1.2.7] REQUIRED SEQUENCE The algorithm identifier for the public key.
subjectPublicKeyInfo.subjectPublicKey [RFC 5280, clause 4.1.2.7] REQUIRED BIT STRING The public key itself.
extensions [RFC 5280, clause 4.1.2.9] REQUIRED [3] EXPLICIT SEQUENCE A sequence of one or more certificate extensions.

The extensions field of the WRPAC SHALL contain various extensions, each of which is an ASN.1 SEQUENCE containing the following fields:

Parameter Defined in Presence Format Description
[extension_name].extnID [RFC 5280, clause 4.1.2.9] REQUIRED OBJECT IDENTIFIER The OID identifying the specific extension type.
[extension_name].critical [RFC 5280, clause 4.1.2.9] OPTIONAL BOOLEAN Indicates whether the extension is critical. DEFAULT is FALSE.
[extension_name].extnValue [RFC 5280, clause 4.1.2.9] REQUIRED OCTET STRING Contains the DER encoding of the ASN.1 value corresponding to the extension type identified by extnID.

Below there is a list of the mandatory extensions and their content, if applicable. The column "Criticality" of the certificate extensions takes the semantics defined in [RFC 5280, clause 4.2] and uses the following acronyms:

  • C: The extension SHALL be considered critical.
  • NC: The extension SHALL be considered non-critical.
Parameter Defined in Presence Criticality Format Description
authorityKeyIdentifier [ETSI EN 319 412-2, clause 4.3.1] REQUIRED Non-critical SEQUENCE Extension with the OID 2.5.29.35.

Key identifier for the issuing CA's public key.

Contains: keyIdentifier (OCTET STRING), authorityCertIssuer (GeneralNames), and authorityCertSerialNumber (INTEGER).
keyUsage [ETSI EN 319 412-2, clause 4.3.2],
[ETSI EN 319 412-3, clause 4.3.1]		 REQUIRED Critical BIT STRING Extension with the OID 2.5.29.15.

It SHALL be one of the following:
  1. non-repudiation
  2. non-repudiation and digital signature
  3. digital signature
  4. digital signature and (key encipherment or key agreement)
  5. key encipherment or key agreement
  6. non-repudiation and digital signature and (key encipherment or key agreement)
Type A, C, or E should be used to avoid mixed usage of keys.

Certificates issued to natural persons and used to validate commitment to signed content (e.g., documents/agreements) SHALL be limited to type A, B, or F (type A should be used).

Certificates issued to legal persons and used to validate digital signatures over content SHALL be limited to type A, B, or F (type A should be used).

Certificate issuers are invited to take into account the security implications, particularly SC-1, when this parameter is set up.
cRLDistributionPoints [ETSI EN 319 412-2, clause 4.3.11] REQUIRED (C) Non-critical SEQUENCE Extension with the OID 2.5.29.31.

Sequence of distributionPoint represented by a CHOICE of FullName (GeneralNames) or nameRelativeToCRLIssuer, reasons (BIT STRING), and cRLIssuer (GeneralNames).

Applicable condition: If the certificate does not include any access location of an OCSP responder or the validity assured extension as defined in [ETSI EN 319 412-1].

It contains at least one reference to a publicly available Certificate Revocation List.
ext-etsi-valassured-ST-certs [ETSI EN 319 412-1, clause 5.2] REQUIRED (C) NC EXTENSION Extension with the OID 0.4.0.194121.2.1.

Applicable condition: For short-term certificates which cannot be revoked.

Indicates that the certificate issuer ensures the validity of the certificate is assured at time of use of the corresponding private key. Upon presence of such statement, the WRP can decide not to check the certificate revocation status (e.g., when validating a digital signature).
noRevAvail [RFC 9608] clause 2 REQUIRED (C) NC EXTENSION Extension with the OID 2.5.29.56.

Applicable condition: If the certificate includes the validity assured extension, but neither includes a CRL distribution point nor access location of an OCSP responder.
authorityInfoAccess [ETSI EN 319 412-2, clause 4.4.1] REQUIRED Non-critical SEQUENCE Extension with the OID 1.3.6.1.5.5.7.1.1.

Sequence of AccessDescription, containing an accessMethod (OID) and an accessLocation (GeneralName).

It SHALL at least include the id-ad-caIssuers OID specifying at least one access location of a valid CA certificate of the issuing CA.

If OCSP is supported, it SHALL include the id-ad-ocsp OID specifying at least one access location of an OCSP responder providing status information for the present certificate.

If the certificate does not include any CRL distribution point and does not include the validity assured extension, a reference to at least one OCSP responder SHALL be present.
certificatePolicies [RFC 3647, clause 3.3.1],
[RFC 5280, clause 4.2.1.4]		 REQUIRED NC SEQUENCE Sequence of PolicyInformation elements, each being a SEQUENCE of policyIdentifier (OID) and policyQualifiers.

The extension is mandatory as stated in [ETSI TS 119 411-8], requirement GEN-6.6.1-03. [ETSI TS 119 411-8] defines the following policy identifiers:
  • 0.4.0.194118.1.1 for NCP-n-eudiwrp
  • 0.4.0.194118.1.2 for NCP-l-eudiwrp
  • 0.4.0.194118.1.3 for QCP-n-eudiwrp
  • 0.4.0.194118.1.4 for QCP-l-eudiwrp
The cpsURI under Certificate policies SHALL indicate a URL where the CPS of the Provider of WRPACs is located.
subjectAltName [RFC 5280, clause 4.2.1.6] REQUIRED NC SEQUENCE Extension with the OID 2.5.29.17.

Sequence of GeneralName elements, each representing a possible alternative name for the subject of the certificate.

Each GeneralName element contains contact information of the WRP and there SHALL be at least one element among the following:
  • uniformResourceIdentifier indicating a website where the WRP can be contacted for helpdesk/support matters.
  • otherName with type-id id-at-telephoneNumber indicating a phone number for WRP registration/usage matters.
  • rfc822Name indicating an email address for WRP registration/usage matters.
The extension is mandatory as stated in [ETSI TS 119 411-8, clause 6.6.1].
qcStatements (esi4-qcStatement-1) [RFC 3739, clause 3.2.6],
[ETSI EN 319 412-5, clause 4.2.1]		 REQUIRED (C) NC SEQUENCE QCStatement with the OID 0.4.0.1862.1.1.

Applicable condition: For qualified certificates. It indicates that the certificate is qualified within the defined legal framework. For the eIDAS regulatory environment, the QcCClegislation SHALL be absent.
qcStatements (esi4-qcStatement-4) [RFC 3739, clause 3.2.6],
[ETSI EN 319 412-5, clause 4.2.2]		 REQUIRED (C) NC SEQUENCE QCStatement with the OID 0.4.0.1862.1.4.

Applicable condition: For qualified certificates. It indicates that the private key related to the certified public key resides in a QSCD according to eIDAS regulation. The extension is mandatory as stated in [ETSI EN 319 411-2, GEN-6.6.1-03].
qcStatements (esi4-qcStatement-6) [RFC 3739, clause 3.2.6],
[ETSI EN 319 412-5, clause 4.2.3]		 REQUIRED (C) NC SEQUENCE QCStatement with the OID 0.4.0.1862.1.6.

Applicable condition: Mandatory for qualified certificates issued to legal persons for the purpose of electronic seal ([ETSI EN 319 412-5, clause 5]). MAY be present for certificates issued to natural persons for the purpose of electronic signatures.

Declares that a certificate is issued for one and only one of the purposes: electronic signature, electronic seal, or web site authentication.

Examples

The following is an example of a WRPAC for legal persons following the NCP.

AccessCertificate cert = {

  tbsCertificate: {

    version: 2,                     // integer value 2 for v3  
    serialNumber: "0x6F3A0B91D2...", 
    signature: AlgorithmIdentifier { 
      oid: "1.2.840.113549.1.1.11",  // sha256WithRSAEncryption 
      params: NULL 
    }, 

    issuer: DistinguishedName {      // issuer attributes for legal person 
      countryName: "FR", 
      organizationName: "Example Trust Services CA S.A.", 
      commonName: "Example TS CA - Issuing", 
      organizationIdentifier: "VATFR-123456789" 
    }, 

    validity: { 
      notBefore: "2026-01-27T00:00:00Z", 
      notAfter:  "2027-01-27T00:00:00Z" 
    }, 

    subject: DistinguishedName {     // subject attributes for legal person 
      countryName: "FR", 
      organizationName: "Relying Party Example S.A.", 
      organizationIdentifier: "LEIXYZ-5493001KJTIIGC8Y1R12", 
      commonName: "RP Example" 
    }, 

    subjectPublicKeyInfo: { 
      algorithm: AlgorithmIdentifier { 
        oid: "1.2.840.113549.1.1.1", 
        params: NULL 
      }, 

      subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)" 
    }, 


    extensions: [

      Extension { 
        oid: "2.5.29.35",            // authorityKeyIdentifier 
        critical: false, 
        value: AuthorityKeyIdentifier { 
          keyIdentifier: "HEX(20B_KEYID_OF_ISSUING_CA_PUBLIC_KEY)" 
        } 
      },

      Extension {
        oid: "2.5.29.15",            // keyUsage 
        critical: true, 
        value: KeyUsage { 
          nonRepudiation: true        // Type A 
          // all others false 
        } 
      }, 

      Extension {
        oid: "1.3.6.1.5.5.7.1.1",    // authority information access
        critical: false, 
        value: AuthorityInfoAccess [ 
          AccessDescription { 
            accessMethod: "1.3.6.1.5.5.7.48.2",            // id-ad-caIssuers 
            accessLocation: URI("https://ca.example.test/caIssuers/issuing-ca.cer") 
          }, 

          AccessDescription { 
            accessMethod: "1.3.6.1.5.5.7.48.1",            // id-ad-ocsp 
            accessLocation: URI("https://ocsp.example.test") 
          } 
        ] 
      }, 

      Extension { 
        oid: "2.5.29.32",            // certificatePolicies 
        critical: false, 
        value: CertificatePolicies [ 
          PolicyInformation { 
            policyIdentifier: "0.4.0.194118.1.2",          // NCP-l-eudiwrp (legal person) 
            policyQualifiers: [ 
              CPSuri("https://rpca.example.test/cps") 
            ] 
          } 
        ] 
      }, 

      Extension { 
        oid: "2.5.29.17",            // subjectAltName 
        critical: false, 
        value: SubjectAltName [ 
          GeneralName.uniformResourceIdentifier("https://rp.example.test/support"), 
          GeneralName.rfc822Name("wallet-support@rp.example.test"), 
          GeneralName.otherName( 
            typeId: "2.5.4.20",       // id-at-telephoneNumber 
            value: "+33-1-23-45-67-89" 
          ) 
        ] 
      }, 

      Extension { 
        oid: "2.5.29.31",            // cRLDistributionPoints 
        critical: false,
        value: CRLDistributionPoints [ 
          DistributionPoint { 
            distributionPoint: URI("https://crl.example.test/issuing-ca.crl") 
          } 
        ] 
      } 
    ] 
  }, 

  signatureAlgorithm: AlgorithmIdentifier { 
    oid: "1.2.840.113549.1.1.11",    // must match/align with tbsCertificate.signature 
    params: NULL 
  }, 
  signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))" 
}

Below there is an example of a WRPAC for natural persons following the QCP policy that is short-term and therefore non-revocable.

WRPAC cert = { 

  tbsCertificate: { 

    version: 2,                     // integer value 2 for v3  
    serialNumber: "0x02A94F10C3B7",
    signature: AlgorithmIdentifier { // M: per [ETSI TS 119 312] (or national) 
      oid: "1.2.840.113549.1.1.11",  // example: sha256WithRSAEncryption 
      params: NULL 
    }, 

    issuer: DistinguishedName {      // issuer attributes for legal person 
      countryName: "FR", 
      organizationName: "Qualified Trust Service Provider CA S.A.", 
      commonName: "QTSP CA - Qualified Issuing", 
      organizationIdentifier: "VATFR-987654321" 
    }, 

      validity: {                    // short-term validity 
      notBefore: "2026-01-27T10:00:00Z", 
      notAfter:  "2026-01-27T22:00:00Z" 
    }, 

    subject: DistinguishedName { 
      countryName: "FR", 
      givenName: "Alice", 
      surname: "Martin", 
      commonName: "Alice Martin", 
      serialNumber: "PNO-FR-ALICEMARTIN-839201"
    }, 

    subjectPublicKeyInfo: {
      algorithm: AlgorithmIdentifier { 
        oid: "1.2.840.10045.2.1",     // ecPublicKey 
        params: "1.2.840.10045.3.1.7" // prime256v1 
      }, 

      subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)" 
    }, 

    extensions: [ 

      Extension {                 // authority key identifier
        oid: "2.5.29.35", 
        critical: false, 
        value: AuthorityKeyIdentifier { 
          keyIdentifier: "HEX(ISSUING_CA_KEYID)" 
        } 
      }, 

      Extension { 
        oid: "2.5.29.15",           // key usage
        critical: true, 
        value: KeyUsage { 
          nonRepudiation: true        // Type A 
        } 
      }, 

      Extension {                 // subject alternative name
        oid: "2.5.29.17", 
        critical: false, 
        value: SubjectAltName [ 
          GeneralName.rfc822Name("helpdesk@relyingparty.example.test"), 
          GeneralName.uniformResourceIdentifier("https://relyingparty.example.test/support") 
        ] 
      }, 

      Extension {                  // authority information access 
        oid: "1.3.6.1.5.5.7.1.1", 
        critical: false, 
        value: AuthorityInfoAccess [ 
          AccessDescription { 
            accessMethod: "1.3.6.1.5.5.7.48.2",  // id-ad-caIssuers 
            accessLocation: URI("https://qtsp.example.test/caIssuers/qualified-issuing-ca.cer") 
          } 
        ] 
      }, 

      Extension { 
        oid: "2.5.29.32",                      // certificate policies
        critical: false, 
        value: CertificatePolicies [ 
          PolicyInformation { 
            policyIdentifier: "0.4.0.194118.1.3",  // QCP-n-eudiwrp 
            policyQualifiers: [ 
              CPSuri("https://qtsp.example.test/cps") 
            ] 
          } 
        ] 
      }, 

      Extension { 
        oid: "0.4.0.194121.2.1",   // ext-etsi-valassured-ST-certs
        critical: false, 
        value:DER(NULL)             // (DER encoding: 0500)
      }, 

      Extension { 
        oid: "2.5.29.56",           // id-ce-noRevAvail
        critical: false, 
        value:DER(NULL)             // (DER encoding: 0500)
      }, 

      Extension { 
        oid: "1.3.6.1.5.5.7.1.3",   // qcStatements container 
        critical: false, 
        value: QCStatements [ 
          QCStatement {          // esi4-qcStatement-1
            statementId: "0.4.0.1862.1.1",
          }, 
          QCStatement { 
            statementId: "0.4.0.1862.1.4", // esi4-qcStatement-4
          }, 
          QCStatement { 
            statementId: "0.4.0.1862.1.6",  // esi4-qcStatement-6
            value: 0.4.0.1862.1.6.1  // purpose : electronicSignature
            } 
          } 
        ] 
      } 
    ] 
  }, 

  signatureAlgorithm: AlgorithmIdentifier { 
    oid: "1.2.840.113549.1.1.11", 
    params: NULL 
  }, 

  signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))" 
}

Security Considerations

A WRPAC is a certificate for electronic seals or signatures that is used to authenticate and validate a WRP when interacting with Wallet Units. Because the corresponding private key is a signature/seal key, implementations SHALL prevent the WRPAC key from becoming a general-purpose signing oracle.

SC-1 — No blind signing of attacker-controlled inputs. The WRP (and any remote signing component used on its behalf, e.g., HSM/QSCD/remote seal) should only sign well-defined, locally constructed protocol artefacts and should not sign arbitrary bytes received from outside (e.g., random nonces, hashes, or opaque challenges supplied by an attacker). For instance, when the interaction with the Wallet Unit takes plase as described in the protocol [OpenID4VP], the WRP signs a self-constructed Request Object. Before signing, the WRP SHOULD validate that the Request Object is fully context-bound (e.g., correct aud, client_id/iss, exp, nonce, and correct endpoint binding such as response_uri/redirect_uri, and the intended presentation definition). Any signing API should enforce a strict schema/allowlist and reject unexpected fields. This is particularly important when the key usage is set to non-repudiation, since this protects against the signing entity falsely denying some action and allows a reliable third party to determine the authenticity of signed data in case of later conflict.

SC-2 — Bind signatures to the intended protocol context. Signed protocol objects should be clearly typed and scoped to the protocol to reduce cross-context misuse. In particular:

  • Use an explicit JOSE typ value appropriate for secured authorization requests / OpenID4VP Request Objects.
  • Constrain accepted JOSE algorithms and key types, and reject insecure or unexpected values (e.g., alg=none).

SC-3 — Key protection, access control, and monitoring. Private keys corresponding to WRPACs SHOULD be protected and operated under strong controls (access control for key use, audit logging, incident response, and operational monitoring). For remote signing, apply rate limiting and anomaly detection to reduce abuse.

Wallet-Relying Party Registration Certificate

This section defines Wallet-Relying Party Registration Certificates (WRPRC), as described in [ARF]. The WRPRC provides detailed information about the Attestation Provider's entitlements, the Attestations they issue, and their intended use.

References
  • CIR 2025/848
  • ETSI EN 319 411-1
  • ETSI TS 119 182-1
  • ETSI TS 119 475
  • ISO 3166-1
  • RFC 5646
  • RFC 7519
  • RFC 8392

Format

  1. The WRPRC shall be formatted as signed JSON Web Token (JWT) or CBOR Web Token (CWT).
  2. The WRPRC shall comply with the syntactic and semantic requirements specified in Annex V paragraph 3 of CIR (EU) 2025/848 [i.2].
  3. The WRPRC shall be signed with the digital signature of provider of the wallet-relying party registration certificates.
  4. The JWT shall be signed with a JSON Advanced Electronic Signature with the B-B profile as defined in [ETSI TS 119 182-1] [18].
  5. The CWT shall be signed with an Advanced Electronic Signature following structure as defined in [RFC 9052] and [RFC 9360].

Attribute Overview

Attribute group Description Required
Header Attributes Required header fields used to identify, sign, and validate WRPRC. Required
Core Identity Attributes Identity attributes of the WRP subject (natural person or legal entity). Required
Service Description Attributes Multilingual service descriptions defining the WRP’s provided services. Required
Entitlements Attribute Entitlements defining what the WRP is authorised to do. Required
Privacy and Policy Attributes Privacy policy information. Some of them
Supervisory Authority Attributes Supervisory authority contact details for reporting suspicious data-processing behaviour. Required
Service Provider Attributes Credential queries, purposes, and intended-use identifiers for service providers. Required for Service Provider
Attestation Provider Attributes Attributes describing attestations issued by an EAA Provider. Required for EAA Provider
Technical Attributes Technical metadata such as policies, timestamps, and status-list configuration. Some of them
Uses Intermediary Attributes Attributes required when the WRP operates through an intermediary entity. Required if Intermediary is used

Header Attributes

JWT Header Attributes

Listed header attributes are mandatory.

Attribute Type Description Reference
typ string Specifies the type of the Web Token. The value is set to rc-wrp+jwt for JWT [ETSI TS 119 475, Table 5]
alg string Indicates the algorithm used to sign the JWT as defined in clause 5.1.2 of [ETSI TS 119 182-1] [18]. [ETSI TS 119 475, Table 5]
x5c array[string] Contains the whole certificate chain to verify the JWT or CWT as defined in clause 5.1.8 of [ETSI TS 119 182-1] [18] [ETSI TS 119 475, Table 5]

CWT Header Attributes

Listed header attributes are mandatory.

Attribute Type Description Reference
typ string Specifies the type of the Web Token. The value is set to rc-wrp+cwt for CWT [ETSI TS 119 475, Table 6]
alg string Indicates the algorithm used to sign the CWT as specified in [RFC 9052], clause 3.1 [ETSI TS 119 475, Table 6]
x5chain array[string] Contains the whole certificate chain to verify the CWT as specified in [RFC 9360], clause 2 [ETSI TS 119 475, Table 6]

Payload Attributes

Core Identity Attributes

Attribute Type Description Required Reference
name string The subject of the WRPRC trade name Required [ETSI TS 119 475, Table 7] - tradeName
sub_gn string Given Name of Natural Person Required for Natural Person [ETSI TS 119 475, Table 7] - givenName
sub_fn string Family Name of Natural Person Required for Natural Person [ETSI TS 119 475, Table 7] - familyName
sub_ln string Official legal name Required for Legal Entity [ETSI TS 119 475, Table 7] - legalName
sub string Organizational identifier per clause 5.1.3 Required for Legal Entity [ETSI TS 119 475, Table 7] - identifier
country string ISO 3166-1 alpha-2 code Required [ETSI TS 119 475, Table 7] - country
registry_uri string URL pointing to the national registry API endpoint of the registered WRP Required [ETSI TS 119 475, Table 7] - registryURI
info_uri string URL general-purpose web address Required [ETSI TS 119 475, Table 7] - infoURI
support_uri string URL or email address to use in data deletion or portability requests related to the WRP Required [ETSI TS 119 475, Table 7] - supportURI

Service Description Attributes

Attribute Type Description Required Reference
srv_description array[object] Multilingual service descriptions Required [ETSI TS 119 475, Table 7] - srvDescription
srv_description[].lang string Language identifier, referring the BCP47 language tag format defined in RFC 5646 [9] Required [ETSI TS 119 475, Table 7] - lang
srv_description[].value string Service description in specified language Required [ETSI TS 119 475, Table 7] - content

Entitlements Attribute

Attribute Type Description Required Reference
entitlements array[string] A list of entitlements assigned to the WRP as defined in [ETSI TS 119 475, Annex A.2] Required [ETSI TS 119 475, Table 7] - entitlement

Privacy and Policy Attributes

Attribute Type Description Required Reference
privacy_policy string URL to the WRP's privacy policy explaining data processing and storage practices Required [ETSI TS 119 475, Table 7] - policyURI
public_body boolean Boolean indicating whether the WRP is a Public Sector Body Optional [ETSI TS 119 475, Table 10] - isPSB

Supervisory Authority Attributes

Attribute Type Description Required Reference
supervisory_authority object DPA Info Required [ETSI TS 119 475, Table 7] - supervisoryAuthority
spervisory_authority.uri string The URL of web form provided by the Data Protection Authority supervising the Relying Party, which Users can use to report suspicious attribute presentation requests Required [ETSI TS 119 475, Table 7] - infoURI
supervisory_authority.email string An e-mail address of that DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users Required [ETSI TS 119 475, Table 7] - email
supervisory_authority.phone string A telephone number of that DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users Required [ETSI TS 119 475, Table 7] - phone

Service Provider Attributes

Attribute Type Description Required Reference
credentials array[object] A set of credential queries, used to request credentials from the Wallet. The EUDI Wallet will use this information to perform an over-asking validation Required for Service Provider [ETSI TS 119 475, Table 9] - credential
credentials[].format string Format of the attestation Required for Service Provider [ETSI TS 119 475, Table 9] - format
credentials[].meta object Object defining additional properties. Required for Service Provider [ETSI TS 119 475, Table 9] - meta
credentials[].claim array[object] Array of objects that specifies attributes in the requested attestation. If claim is absent, the WRPRC does not declare any specific attributes intended to be requested by the WRP Required for Service Provide [ETSI TS 119 475, Table 9] - claim
purpose array[object] A list describing the data processing associated with the intended use Required for Service Provider [ETSI TS 119 475, Table 9] - purpose
purpose[].lang string Language identifier, referring the BCP 47 language tag format defined in [RFC 5646] Required for Service Provider [ETSI TS 119 475, Table 9] - lang
purpose[].value string Purpose description provided in the language specified above Required for Service Provider [ETSI TS 119 475, Table 9] - value
intended_use_id string Unique identifier of the intended use if provided by the registry. Used to fetch the intented use directly from the registry Required for Service Provider only if provided by registry [ETSI TS 119 475, Table 9] - intendedUserIdentifier

Attestation Provider Attributes

Attribute Type Description Required Reference
provides_attestations array[object] A set of credentials issued by the WRP with EAA entitlements. Required for EAA Provider [ETSI TS 119 475, Table 8] - providesAttestations
provides_attestations[].format string Format of the credential. Required for EAA Provider [ETSI TS 119 475, Table 8] - format
provides_attestations[].meta object Metadata to identify the credential type. Required for EAA Provider [ETSI TS 119 475, Table 8] - meta
provides_attestations[].claim array[object] Objects that specifies attributes in the requested attestation. Required for EAA Provider only if provided by registry. [ETSI TS 119 475, Table 8] - claim

Technical Attributes

Attribute Type Description Required Reference
policy_id array[string] List of policy identifiers as defined in clause 6.1.3 Required [ETSI TS 119 475, Table 7] - technical
certificate_policy string URL to the certificate policy and certificate practice statement Required [ETSI TS 119 475, Table 7] - technical
iat unix_timestamp Unix timestamp indicating when the WRP was issued Required [ETSI TS 119 475, Table 7] - technical
exp unix_timestamp Expiration time of the JWT/CWT as a Unix timestamp Optional [ETSI TS 119 475, Table 10] - technical
status object A URI to a Status List Token presenting information about validity of the WRPRC Required [ETSI TS 119 475, Table 7] - technical
status.status_list.idx int Position in status bitstring Required [ETSI TS 119 475] GEN-6.2.6.1-04, GEN-6.2.6.1-05
status.status_list.uri string Status List Token URI Required [ETSI TS 119 475] GEN-6.2.6.1-04

Uses Intermediary Attributes

Attribute Type Description Required Reference
intermediary object Used when the WRP operates via an intermediary Required if Intermediary is used [ETSI TS 119 475, Table 10] - usesIntermediary
intermediary.sub string Identifier of the intermediary as specified by the intermediary WRPAC Required if Intermediary is used [ETSI TS 119 475, Table 10] - usesIntermediary
intermediary.sname string commonName of the intermediary as specified by the intermediary WRPAC Required if Intermediary is used [ETSI TS 119 475, Table 10] - usesIntermediary

Examples

JWT Header

{
  "typ": "rc-wrp+jwt",
  "alg": "ES256",
  "x5c": ["<base64-encoded-certificate-chain>"]
}

CWT Header

{
  1: -7,    / alg: ES256 /,
  16: "rc-wrp+cwt", / typ /
  33: [     / x5chain /
    h'...', / binary end cert /
    h'...', / binary intermediate cert /
    h'...'  / binary root cert /
  ]
}

JWT Payload Example - Service Provider

{
  "name": "Online Shop AG",
  "sub_ln": "Online Shop AG",
  "sub": "LEIXG-529900T8BM49AURSDO55",
  "country": "DE",
  "registry_uri": "https://wrp-register.de/api/v1/relying-parties/DE-WRP-00789",
  "srv_description": [
    { "lang": "de-DE", "value": "Online-Einkaufsplattform mit Altersverifikation" },
    { "lang": "en-US", "value": "Online shopping platform with age verification" }
  ],
  "entitlements": ["https://uri.etsi.org/19475/Entitlement/Service_Provider"],
  "purpose": [
    { "lang": "de-DE", "value": "Altersverifikation für altersbeschränkte Produkte gemäß JuSchG" },
    { "lang": "en-US", "value": "Age verification for age-restricted products" }
  ],
  "credentials": [
    {
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["https://credentials.example.eu/pid"] },
      "claim": [{ "path": ["age_over_18"] }]
    }
  ],
  "privacy_policy": "https://shop.example.de/privacy",
  "info_uri": "https://shop.example.de",
  "support_uri": "https://shop.example.de/support",
  "supervisory_authority": {
    "uri": "https://www.bfdi.bund.de",
    "email": "poststelle@bfdi.bund.de",
    "phone": "+49 228 997799 0"
  },
  "public_body": false,
  "policy_id": ["0.4.0.19475.3.1"],
  "certificate_policy": "https://wrp-register.de/policies/service-provider",
  "iat": 1704067200,
  "exp": 1735689600,
  "status": { "status_list": { "idx": 156, "uri": "https://status.wrp-register.de/statuslist/1" } }
}

JWT Payload Example - Qualified EAA Provider

{
  "name": "Spanish Driving License Attestation Service",
  "sub_ln": "Ministerio del Interior - Dirección General de Tráfico",
  "sub": "VATES-S2800001J",
  "country": "ES",
  "registry_uri": "https://registro.mineco.gob.es/wrp/api/v1/relying-parties/ES-WRP-00123",
  "srv_description": [
    {
      "lang": "es-ES",
      "value": "Servicio de emisión de permisos de conducir digitales y attestaciones relacionadas con la conducción"
    },
    {
      "lang": "en-US",
      "value": "Digital driving license and driving-related attestation issuance service"
    }
  ],
  "entitlements": [
    "https://uri.etsi.org/19475/Entitlement/QEAA_Provider",
    "https://uri.etsi.org/19475/Entitlement/PUB_EAA_Provider"
  ],
  "provides_attestations": [
    {
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "https://credentials.dgt.es/mobile-driving-license"
        ]
      },
      "claim": [
        { "path": ["family_name"] },
        { "path": ["given_name"] },
        { "path": ["birth_date"] },
        { "path": ["portrait"] },
        { "path": ["driving_privileges"] },
        { "path": ["issue_date"] },
        { "path": ["expiry_date"] },
        { "path": ["issuing_authority"] },
        { "path": ["document_number"] },
        { "path": ["issuing_country"] }
      ]
    },
    {
      "format": "mso_mdoc",
      "meta": {
        "doctype_value": "org.iso.18013.5.1.mDL"
      },
      "claim": [
        { "path": ["org.iso.18013.5.1", "family_name"] },
        { "path": ["org.iso.18013.5.1", "given_name"] },
        { "path": ["org.iso.18013.5.1", "birth_date"] },
        { "path": ["org.iso.18013.5.1", "portrait"] },
        { "path": ["org.iso.18013.5.1", "driving_privileges"] }
      ]
    }
  ],
  "privacy_policy": "https://dgt.es/privacy-policy",
  "info_uri": "https://dgt.es",
  "supervisory_authority": {
    "uri": "https://www.aepd.es",
    "email": "ciudadano@aepd.es",
    "phone": "+34 91 266 35 17"
  },
  "public_body": true,
  "policy_id": [
    "0.4.0.19475.3.1"
  ],
  "certificate_policy": "https://pki.dgt.es/wrprc-policy",
  "iat": 1704067200,
  "exp": 1735689600,
  "status": {
    "status_list": {
      "idx": 42,
      "uri": "https://status.dgt.es/wrprc/statuslist/1"
    }
  }
}

JWT Payload Example - Non-Qualified EAA Provider (University)

{
  "name": "University of Amsterdam Credential Service",
  "sub_ln": "Universiteit van Amsterdam",
  "sub": "NTRNLD-KVK34567890",
  "country": "NL",
  "registry_uri": "https://wrp-register.nl/api/v1/relying-parties/NL-WRP-00456",
  "srv_description": [
    {
      "lang": "nl-NL",
      "value": "Uitgifte van digitale studentenkaarten en academische credentials"
    },
    {
      "lang": "en-US",
      "value": "Issuance of digital student cards and academic credentials"
    }
  ],
  "entitlements": [
    "https://uri.etsi.org/19475/Entitlement/Non_Q_EAA_Provider"
  ],
  "provides_attestations": [
    {
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "https://credentials.uva.nl/student-id"
        ]
      },
      "claim": [
        { "path": ["family_name"] },
        { "path": ["given_name"] },
        { "path": ["student_id"] },
        { "path": ["faculty"] },
        { "path": ["program"] },
        { "path": ["enrollment_date"] },
        { "path": ["expected_graduation"] },
        { "path": ["student_status"] }
      ]
    },
    {
      "format": "dc+sd-jwt",
      "meta": {
        "vct_values": [
          "https://credentials.uva.nl/diploma"
        ]
      },
      "claim": [
        { "path": ["family_name"] },
        { "path": ["given_name"] },
        { "path": ["degree_title"] },
        { "path": ["field_of_study"] },
        { "path": ["graduation_date"] },
        { "path": ["honors"] },
        { "path": ["diploma_number"] }
      ]
    }
  ],
  "privacy_policy": "https://uva.nl/privacy",
  "info_uri": "https://credentials.uva.nl",
  "supervisory_authority": {
    "uri": "https://autoriteitpersoonsgegevens.nl",
    "email": "info@autoriteitpersoonsgegevens.nl",
    "phone": "+31 70 888 85 00"
  },
  "public_body": false,
  "policy_id": [
    "0.4.0.19475.3.1"
  ],
  "certificate_policy": "https://pki.uva.nl/wrprc-policy",
  "iat": 1704067200,
  "exp": 1735689600,
  "status": {
    "status_list": {
      "idx": 78,
      "uri": "https://status.uva.nl/wrprc/statuslist/1"
    }
  }
}

JWT Payload Example - Banking KYC (Multiple Credentials)

{
  "name": "Dutch Bank Customer Onboarding",
  "sub_ln": "Dutch Bank N.V.",
  "sub": "LEIXG-724500VKKSH9QOLTFR81",
  "country": "NL",
  "registry_uri": "https://wrp-register.nl/api/v1/relying-parties/NL-WRP-00234",
  "entitlements": [
    "https://uri.etsi.org/19475/Entitlement/Service_Provider",
    "https://uri.etsi.org/19475/SubEntitlement/psp/psp-as"
  ],
  "purpose": [
    { "lang": "en-US", "value": "Identity verification and KYC check for bank account opening" }
  ],
  "credentials": [
    {
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["https://credentials.example.eu/pid"] },
      "claim": [
        { "path": ["family_name"] }, { "path": ["given_name"] },
        { "path": ["birth_date"] }, { "path": ["nationality"] },
        { "path": ["resident_address"] }, { "path": ["personal_identifier"] }
      ]
    },
    {
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["https://credentials.example.eu/address-attestation"] },
      "claim": [
        { "path": ["resident_address"] }, { "path": ["resident_country"] }
      ]
    }
  ],
  "privacy_policy": "https://dutchbank.nl/privacy",
  "supervisory_authority": {
    "uri": "https://autoriteitpersoonsgegevens.nl",
    "email": "info@autoriteitpersoonsgegevens.nl"
  },
  "public_body": false,
  "policy_id": ["0.4.0.19475.3.1"],
  "iat": 1704067200,
  "status": { "status_list": { "idx": 89, "uri": "https://status.wrp-register.nl/statuslist/1" } }
}

JWT Payload Example - With Intermediary

{
  "name": "Small Business Verification",
  "sub_ln": "Small Business GmbH",
  "sub": "VATDE-DE123456789",
  "country": "DE",
  "entitlements": ["https://uri.etsi.org/19475/Entitlement/Service_Provider"],
  "credentials": [
    {
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["https://credentials.example.eu/pid"] },
      "claim": [{ "path": ["age_over_18"] }]
    }
  ],
  "intermediary": {
    "sub": {
      "id": "LEIXG-529900INTERMEDIARY01",
      "name": "Verification Services AG"
    }
  },
  "policy_id": ["0.4.0.19475.3.1"],
  "iat": 1704067200,
  "status": { "status_list": { "idx": 567, "uri": "https://status.wrp-register.de/statuslist/2" } }
}

JWT Payload Example - Natural Person (Notary)

{
  "name": "Notaio Marco Rossi",
  "sub_gn": "Marco",
  "sub_fn": "Rossi",
  "sub": "TINIT-RSSMRC80A01H501U",
  "country": "IT",
  "registry_uri": "https://wrp-register.gov.it/api/v1/relying-parties/IT-WRP-00890",
  "entitlements": ["https://uri.etsi.org/19475/Entitlement/Service_Provider"],
  "purpose": [
    { "lang": "it-IT", "value": "Identificazione delle parti per atti notarili" }
  ],
  "credentials": [
    {
      "format": "dc+sd-jwt",
      "meta": { "vct_values": ["https://credentials.example.eu/pid"] },
      "claim": [
        { "path": ["family_name"] }, { "path": ["given_name"] },
        { "path": ["birth_date"] }, { "path": ["personal_identifier"] }
      ]
    }
  ],
  "privacy_policy": "https://notaio-rossi.it/privacy",
  "supervisory_authority": { "uri": "https://www.garanteprivacy.it", "email": "protocollo@gpdp.it" },
  "public_body": false,
  "policy_id": ["0.4.0.19475.3.1"],
  "iat": 1704067200,
  "status": { "status_list": { "idx": 345, "uri": "https://status.wrp-register.gov.it/statuslist/1" } }
}

Other Information

Algorithms

Algorithms used should be one of the algorithms for digital signatures recommended by in [ETSI TS 119 312].

[OpenID4VC HAIP] also defines its own requirements for digital signatures. However, those requirements are not directly related to WRPRCs.

List of Possible Entitlements

Per [ETSI TS 119 475, Annex A.2]:

Entitlement URI OID ETSI Reference Description
Service_Provider https://uri.etsi.org/19475/Entitlement/Service_Provider id-etsi-wrpa-entitlement 1 Annex A.2.1 General service provider
QEAA_Provider https://uri.etsi.org/19475/Entitlement/QEAA_Provider id-etsi-wrpa-entitlement 2 Annex A.2.2 Qualified EAA provider
Non_Q_EAA_Provider https://uri.etsi.org/19475/Entitlement/Non_Q_EAA_Provider id-etsi-wrpa-entitlement 3 Annex A.2.3 Non-qualified EAA provider
PUB_EAA_Provider https://uri.etsi.org/19475/Entitlement/PUB_EAA_Provider id-etsi-wrpa-entitlement 4 Annex A.2.4 Public sector EAA provider
PID_Provider https://uri.etsi.org/19475/Entitlement/PID_Provider id-etsi-wrpa-entitlement 5 Annex A.2.5 Provider of person identification data
QCert_for_ESeal_Provider https://uri.etsi.org/19475/Entitlement/QCert_for_ESeal_Provider id-etsi-wrpa-entitlement 6 Annex A.2.6 QTSP issuing qualified certificates for electronic seals
QCert_for_ESig_Provider https://uri.etsi.org/19475/Entitlement/QCert_for_ESig_Provider id-etsi-wrpa-entitlement 7 Annex A.2.7 QTSP issuing qualified certificates for electronic signatures
rQSealCDs_Provider https://uri.etsi.org/19475/Entitlement/rQSealCDs_Provider id-etsi-wrpa-entitlement 8 Annex A.2.8 QTSP managing remote qualified electronic seal creation devices
rQSigCDs_Provider https://uri.etsi.org/19475/Entitlement/rQSigCDs_Provider id-etsi-wrpa-entitlement 9 Annex A.2.9 QTSP managing remote qualified electronic signature creation devices
ESig_ESeal_Creation_Provider https://uri.etsi.org/19475/Entitlement/ESig_ESeal_Creation_Provider id-etsi-wrpa-entitlement 10 Annex A.2.10 Non-qualified provider for remote signature/seal creation

Organizational Identifier Formats

Per [ETSI TS 119 475, clause 5.1.3 - Table 2 and 5.1.5 - Table 4]:

Type URI (B.2.5) Semantic Prefix ETSI Reference EU Regulation
http://data.europa.eu/eudi/id/EUID NTR GEN-5.1.3-02, Table 2 CIR 2020/2244
http://data.europa.eu/eudi/id/LEI LEI GEN-5.1.3-02, Table 2 CIR 2022/1860
http://data.europa.eu/eudi/id/VATIN VAT GEN-5.1.3-02, Table 2 Directive 2006/112/EC
http://data.europa.eu/eudi/id/TIN TIN GEN-5.1.5-02, Table 4

CBOR Web Token (CWT) Claims

CWT token claims must be registered in a register created by IANA.

The register is available at https://www.iana.org/assignments/cwt/cwt.xhtml

List of Trusted Entities and List of Trusted Lists

This section describes the format and contents of the Trusted Lists and how they are used for the purpose of the List Of Trusted Lists (LOTL) and List of Trusted Entities (LoTE) within the context of the EUDI Wallet.

Regulatory Background

The Trusted List is defined in article 22 of eIDAS regulation EU 910/2014 as the means to keep current and historical information about the accredited trust service providers in each Member State. One Trusted List must be maintained and published by each Member State.

Furthermore, according to Chapter II of Annex I of The CID (EU) 2015/1505, further amended by CID (EU) 2025/2164, Trusted Lists must follow the technical specification [ETSI TS 119 612] version 2.4.1, becoming effective and live on April 29th, 2026.

Also in CID (EU) 2015/150, article 4(3) establishes that the Commission publishes the information received from MS about their Trust Lists in machine-readable format for automated processing. This is what is known by "List Of Trusted Lists (LOTL)". Under article 4(4), the Commission may also publish the same information in human-readable format.

Specifically for the EUDI Wallet, the Commission defines the additional "List of Trusted Entities (LoTE)". The principles of the LoTEs are established under Articles 4 and 5 in [CIR 2024/2980], which points the direction to the creation and publishing of two lists:

  1. one list to include: - Registrars of Wallet-Relying Parties - Registers of Wallet-Relying Parties
  2. another list to include: - Wallet Providers - PID Providers - and Providers of Wallet Relying Party Access Certificates

Trusted List

The Trusted List (TL) is a mechanism to convey information about trust anchors in an wide interoperable ecosystem such as the eIDAS framework. It was originally designed to hold current and historical information about the accreditation of trust service providers, particularly QTSPs, albeit other non-qualified can also be included, including those recognized exclusively at a national level.

For each trust service provider included, the following services can be listed:

  1. Qualified certificates issuing
  2. OCSP for qualified certificates (e.g. if the OCSP responder is external to the QTSP or is not listed in the OCSP URL is not indicated in the Authority Information Access extension)
  3. CRL for qualified certificates (e.g. if the CRL issuing is delegated or the CRL publishing URL is not included in the CRL Distribution Point extension)
  4. Qualified timestamping
  5. Qualified electronic registered delivery
  6. Qualified electronic registered mail delivery
  7. Qualified preservation for Qualified Electronic Signatures and/or qualified electronic seals
  8. Qualified validation of Qualified Electronic Signatures and/or qualified electronic seals
  9. Remote Qualified Electronic Signatures creation device, also known as "remote signing"
  10. Remote qualified Electronic Seal creation device, also known as "remote sealing"
  11. Qualified electronic attestations of attributes issuing
  12. Qualified electronic archiving
  13. Qualified electronic ledgers

Further to the qualified services, a similar set of services can be listed for non-qualified trust services as well as the following additional services:

  1. Not qualified electronic attestation of attributes issued by or on behalf of a Public Sector Body responsible for an Authentic Source (usually referred to as PuB-EAA)
  2. Certificate validation
  3. Preservation of certificates
  4. Validation of electronic attestation of attributes
  5. Validation of timestamps
  6. Validation of data transmitted through electronic registered delivery services and the validation of related evidences
  7. Certificates issuing for purposes other than electronic signing/sealing
  8. Validation of certificates issued for purposes other than electronic signing/sealing

A TL may also include additional trust services defined at national level:

  1. Registration service
  2. Attribute certificates issuing
  3. Policy authority for issuing, publishing and maintaining signature policies
  4. Archiving
  5. Identity verification
  6. Key escrow
  7. Identity credentials based on static passwords
  8. Trusted List issuing (e.g. a sector specific national Trusted List)
  9. National Root CA
  10. Other trust services

The structure and semantics of the TL are defined in [ETSI TS 119 612]. For automated processing, the TL is provided in XML format. A browsable and human-readable format is also available on the eIDAS Dashboard at https://eidas.ec.europa.eu/efda/trust-services/browse/eidas/tls.

Within eIDAS, one TL is maintained per Member State, responsible for keeping record of the trusted services providers under their respective jurisdiction. TLs are numbered and renewed periodically, and published in a website for unrestricted download. To protect their integrity and assure authenticity TLs are also signed with trusted certificates.

List of Trusted Lists

The Trusted List standard [ETSI TS 119 612] allows a hierarchy of Trusted Lists by means of referencing to other TLs from a parent TL.

Within eIDAS, a decentralized trust model is established, where the parent TL is the List Of Trusted Lists (LOTL), managed and operated by the Commission. For each Member State, the LOTL contains a URL that points to the respective TL.

Currently, the LOTL is published in the following URI: https://ec.europa.eu/tools/lotl/eu-lotl.xml.

LOTL Signing and Pivot XML

The LOTL is electronically signed with a XAdES-B-B signature as defined by [ETSI EN 319 132-1]. For verification of the signature, the original signing certificates were initially published on the Official Journal of the European Union, here https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.C_.2019.276.01.0001.01.ENG.

Afterwards, a follow up method of providing traceable changes to the LOTL is provided through the "Pivot LOTL". Whenever the LOTL signing certificates are changed (as they expire over time and are replaced by new certificates), and/or the LOTL publishing URL is changed, a "Pivot LOTL" is created. A "snapshot" of the current LOTL is created and published at a specific URL and a reference to that Pivot LOTL is added to the new (main) LOTL. The LOTL contains the history of Pivot LOTLs, which allows participants in the eIDAS ecosystem to rebuild the history of the LOTL trust any given point in time. More information about the Pivot LOTL mechanism is available here: https://ec.europa.eu/tools/lotl/pivot-lotl-explanation.html.

List of Trusted Entities

The LoTE is a compilation of the information submitted by Member States about the following entities:

  1. PID Providers;
  2. Wallet Providers;
  3. Providers of Wallet Relying Party Access Certificate;
  4. Public sector bodies issuing electronic attestations of attributes.

The LoTE follows the same structure defined for TLs on [ETSI TS 119 612], yet a specific data model is defined in [ETSI TS 119 602] and 2 formats - JSON or XML - are allowed, depending on the type of LoTE.

The LoTE types can be one of the following, as defined in annex C.2:

Tools

This section presents a non-exhaustive list of tools to processing Trusted Lists.

TLManager: The TLManager is a tool for creating Trusted Lists compliant with [ETSI TS 119 612]. Examples of use of the TLManager are:

  • non-EU countries willing to establish a national Trusted List compatible with eIDAS. Following the same standard may facilitate bilateral trust.
  • setup of a sector specific Trusted List - for example, healthcare, energy production and distribution, transportation, etc.
  • setup of a lab Trusted List for testing purposes

TLManager is licenced under LGPL and is available for download here:

https://ec.europa.eu/digital-building-blocks/sites/spaces/TLSO/pages/75665517/Trusted+List+Manager+non-EU

eIDAS Dashboard: The eIDAS Dashboard is a platform in the format of a dynamic website where all information and tools necessary to make use of the EUDI Wallet, Trust Services and eID schemes are openly available.

The eIDAS Dashboard is available online here: https://eidas.ec.europa.eu/efda/home. Specifically for the EUDI Wallet ecosystem, the eIDAS Dashboard already has the placeholders for the several types of entities to be listed in the LoTEs, here: https://eidas.ec.europa.eu/efda/wallet.

Data Models

This section specifies the profiles and formats that the various Trusted Lists defined above SHALL utilize, depending on their specific use cases.

The following table dictates the governing standard, publication scope (i.e., at the Member State or European Union level), and the mandated data format for each list type.

List Type Governing Standard Publication Scope Format
Traditional eIDAS Trusted Lists TS 119 612 Member State XML
List of Trusted Lists (LOTL) TS 119 612 European Union XML
PID Provider Lists TS 119 602 Annex D European Union JSON
Wallet Provider (WP) Lists TS 119 602 Annex E European Union JSON
Provider of WRPAC TS 119 602 Annex F European Union JSON
Provider of WRPRC TS 119 602 Annex G European Union JSON
PuB-EAA Provider Lists TS 119 602 Annex H European Union JSON or XML
Registrar and Register Provider Lists TS 119 602 Annex I European Union JSON

Trusted List and List of Trusted Lists

The following URLs provide the normative XML schemas required for implementing the TLs and the LOTL:

List of Trusted Entities

The following repository provides the normative JSON and XML schemas required for implementing the List of Trusted Entities (LoTE):

Trusted List Terminology Comparison

The LoTE and the LOTL / TL differ not only in their underlying schemas but also in their parameter nomenclature. The following table maps the equivalent terms between the two standards:

TS 119 602 (LoTE) TS 119 612 (TSL)
LoTE TSL
Trusted Entity (TE) Trust Service Provider (TSP)
Trusted Entity Service Trust Service
LoTE Version Identifier TSL Version Identifier
LoTE Sequence Number TSL Sequence Number
LoTE Type TSL Type
Scheme Operator Scheme Operator
Service Digital Identity Service Digital Identity

Specific Formats and Uses

The following table details the governing standards, publication scopes, and mandated data formats regarding the specific provider lists utilized within the ecosystem:

List Type Governing Standard Publication Scope Format
Traditional eIDAS Trusted Lists TS 119 612 Member State XML
List of Trusted Lists (LOTL) TS 119 612 European Union XML
PID Provider Lists TS 119 602 Annex D European Union JSON
Wallet Provider (WP) Lists TS 119 602 Annex E European Union JSON
Provider of WRPAC Lists TS 119 602 Annex F European Union JSON
Provider of WRPRC Lists TS 119 602 Annex G European Union JSON
PuB-EAA Provider Lists TS 119 602 Annex H European Union JSON or XML
Registrar and Register Provider Lists TS 119 602 Annex I European Union JSON

Note

Within the APTITUDE project, the PuB-EAA Provider Lists are published in JSON format.

LoTE Additional Requirements

Following Annexes D - I in [ETSI TS 119 602], below are detailed the additional requirements spelled out by type. As seen in List of Trusted Entities, the LoTE contains a sequence of two components: ListAndSchemeInformation and TrustedEntitiesList. Depending on the LoTE type, the ListAndSchemeInformation component is further specified by the following parameters:

Parameter Defined in Presence Format Description
LoTEVersionIdentifier [ETSI TS 119 602, clause 6.3.1] REQUIRED Integer The value of the LoTEVersionIdentifier component SHALL be 1.
LoTESequenceNumber [ETSI TS 119 602, clause 6.3.2] REQUIRED Integer The first instance of the PID Providers list SHALL be issued with the value of the LoTESequenceNumber component number set to 1.
LoTEType [ETSI TS 119 602, clause 6.3.3] REQUIRED String Depending on the LoTE type, the value of the LoTEType component SHALL be one of the following URIs:
  • "http://uri.etsi.org/19602/LoTEType/EUPIDProvidersList" for PID Providers;
  • "http://uri.etsi.org/19602/LoTEType/EUWalletProvidersList" for Wallet Providers;
  • "http://uri.etsi.org/19602/LoTEType/EUWRPACProvidersList" for Providers of WRPAC;
  • "http://uri.etsi.org/19602/LoTEType/EUWRPRCProvidersList" for Providers of WRPRC;
  • "http://uri.etsi.org/19602/LoTEType/EUPubEAAProvidersList" for Pub-EAA Providers;
  • "http://uri.etsi.org/19602/LoTEType/RegistrarsAndRegistersList" for Registrars.
SchemeOperatorName [ETSI TS 119 602, clause 6.3.4] REQUIRED Object No additional requirements.
SchemeOperatorAddress [ETSI TS 119 602, clause 6.3.5] REQUIRED Object No additional requirements.
SchemeName [ETSI TS 119 602, clause 6.3.6] REQUIRED Object No additional requirements.
SchemeInformationURI [ETSI TS 119 602, clause 6.3.7] REQUIRED Object Depending on the LoTE type, the SchemeInformationURI component SHALL contain a URI where users can receive information about the respective list (PID Provider, Wallet Provider (WP), Provider of WRPAC, Provider of WRPRC, PuB-EAA Provider, Registrar and Registers), and a URI where users can retrieve all previous instances of those lists.
StatusDeterminationApproach [ETSI TS 119 602, clause 6.3.8] REQUIRED String Depending on the LoTE type, the value of the StatusDeterminationApproach component SHALL be one of the following URIs:
  • "http://uri.etsi.org/19602/PIDProvidersList/StatusDetn/EU" for PID Providers;
  • "http://uri.etsi.org/19602/WalletProvidersList/StatusDetn/EU" for Wallet Providers;
  • "http://uri.etsi.org/19602/WRPACProvidersList/StatusDetn/EU" for Providers of WRPAC;
  • "http://uri.etsi.org/19602/WRPRCProvidersList/StatusDetn/EU" for Providers of WRPRC;
  • "http://uri.etsi.org/19602/PubEAAProvidersList/StatusDetn/EU" for Pub-EAA Providers;
  • "http://uri.etsi.org/19602/RegistrarsAndRegistersList/StatusDetn/EU" for Registrars.
SchemeTypeCommunityRules [ETSI TS 119 602, clause 6.3.9] REQUIRED Object Depending on the LoTE type, the value of the SchemeTypeCommunityRules component SHALL be one of the following URIs:
  • "http://uri.etsi.org/19602/PIDProvidersList/schemerules/EU" for PID Providers;
  • "http://uri.etsi.org/19602/WalletProvidersList/schemerules/EU" for Wallet Providers;
  • "http://uri.etsi.org/19602/EUWRPACProviders/schemerules/EU" for Providers of WRPAC;
  • "http://uri.etsi.org/19602/WRPRCProvidersList/schemerules/EU" for Providers of WRPRC;
  • "http://uri.etsi.org/19602/EUPubEAAProvidersList/schemerules/EU" for Pub-EAA Providers;
  • "http://uri.etsi.org/19602/RegistrarsAndRegistersList/schemerules/EU" for Registrars.
SchemeTerritory [ETSI TS 119 602, clause 6.3.10] REQUIRED String The value of the SchemeTerritory component SHALL be EU.
LoTEPolicyLegalNotice [ETSI TS 119 602, clause 6.3.11] REQUIRED Object No additional requirements.
HistoricalInformationPeriod [ETSI TS 119 602, clause 6.3.12] REQUIRED Integer For the PID Provider, Wallet Provider (WP), Provider of WRPAC, Provider of WRPRC, Registrar and Registers LoTE, the HistoricalInformationPeriod component SHALL NOT be present.

For the Pub-EAA Providers LoTE, the HistoricalInformationPeriod component value SHALL be 65535 (representing a year).
PointersToOtherLoTEs [ETSI TS 119 602, clause 6.3.13] REQUIRED Object For the PID Provider, Wallet Provider (WP), Provider of WRPAC, Provider of WRPRC, Registrar and Registers LoTE, the PointersToOtherLoTE component SHALL contain (at least) a pointer to the present LoTE itself.

For the PuB-EAA Provider LoTE, the PointersToOtherLoTE component SHALL NOT be present.
ListIssueDateTime [ETSI TS 119 602, clause 6.3.14] REQUIRED String No additional requirements.
NextUpdate [ETSI TS 119 602, clause 6.3.15] REQUIRED String The maximum value between the list issue date and time and the next update SHALL be 6 months.
DistributionPoints [ETSI TS 119 602, clause 6.3.16] REQUIRED Object No additional requirements.
SchemeExtensions [ETSI TS 119 602, clause 6.3.17] REQUIRED Object No additional requirements.

The TrustedEntitiesList is an Array of Objects, each possessing two primary subcomponents: the TrustedEntityInformation and TrustedEntityServices components. The following table details the additional requirements the TrustedEntityInformation Object component SHALL satisfy depending on the LoTE type.

Parameter Defined in Presence Format Description
TEName [ETSI TS 119 602, clause 6.5.1] REQUIRED Array Depending on the LoTE type, the value of the TEName component SHALL be the name of the PID Provider, Wallet Provider (WP), Provider of WRPAC, Provider of WRPRC, PuB-EAA Provider, or Registrar.
TETradeName [ETSI TS 119 602, clause 6.5.2] REQUIRED Array Depending on the LoTE type, the value of the TETradeName component SHALL include an official registration identifier as registered in official records (where such a registered identifier exists) that unambiguously identifies the entity.

In the case of a legal entity, the TETradeName component SHALL have the same semantics as the organizationIdentifier attribute in [ETSI EN 319 412-1].

In the case of a natural person, the TETradeName component SHALL have the same semantics as the serialNumber attribute in [ETSI EN 319 412-1].

For Pub-EAA Providers, the TETradeName SHALL additionally include the reference to the Union or national law under which the Public Sector Body is established as responsible for the Authentic Source, formatted as a URI: OJ for the scheme part, followed by either EU or the 2 ISO 3166-1 country code characters, terminating with the unique identifier of the law.
TEAddress [ETSI TS 119 602, clause 6.5.3] REQUIRED Array Depending on the LoTE type, the TEAddress component SHALL contain:
  • the postal address of the provider;
  • the contact email and contact phone number of the provider.
TEInformationURI [ETSI TS 119 602, clause 6.5.4] REQUIRED Object Depending on the LoTE type, the TEInformationURI component SHALL contain:
  • The URL of the webpage that contains the policies, terms, and conditions of the respective provider applying to the provision and use of their services/components;
  • where applicable, the URL of the webpage that contains additional information about the provider;
  • a URI formatted as http://uri.etsi.org/19602/ListOfTrustedEntities/[Type]/CC, where [Type] aligns with the provider type and CC is replaced by the ISO 3166-1 Alpha 2 country code of the responsible Member State.
TEInformationExtensions [ETSI TS 119 602, clause 6.5.5] REQUIRED Array No additional requirements.

Warning

The TEAddress component's description for the Pub-EAA Providers LoTE differs from c) of the TEAddress component's description in [ETSI TS 119 602, Annex H.3, Table H.2], which states "the URI "http://uri.etsi.org/19602/ListOfTrustedEntities/PubEAAProvider/CC" where "CC" is replaced by the ISO 3166-1 [2] Alpha 2 code of the Member State which is responsible for that Pub-EAA provider". For conformance to the other LoTE types, this has been moved to the TEInformationURI component's description, as it is more appropriate for the information it conveys.

The TrustedEntityServices is an Array of TrustedEntityService Objects. Each TrustedEntityService Object possesses two primary subcomponents: the ServiceInformation and ServiceHistoryInstance components. The following table details the additional requirements the ServiceInformation Object component SHALL satisfy depending on the LoTE type.

Parameter Defined in Presence Format Description
ServiceTypeIdentifier [ETSI TS 119 602, clause 6.6.1] REQUIRED String Depending on the LoTE type, specific URIs MAY be used as the value of the ServiceTypeIdentifier component, to the exclusion of any other (e.g., .../SvcType/PID/Issuance and .../Revocation for PID services).
ServiceName [ETSI TS 119 602, clause 6.6.2] REQUIRED Array For a Wallet Provider (WP), the ServiceName component SHALL be the name of the Wallet Solution it provides.

For a Registrar, the ServiceName component SHALL contain the name of the Register for which the Registrar is responsible.

No additional requirements for the other LoTE types.
ServiceDigitalIdentity [ETSI TS 119 602, clause 6.6.3] REQUIRED Object Depending on the LoTE type, the ServiceDigitalIdentity component SHALL contain one or more X.509 (Trust Anchor) certificates used to verify the signature or seal created by the provider to validate and authenticate their respective artifacts. The certified identity data SHALL include the name and registration number as specified in the TEName and TETradeName components.

PuB-EAA Provider LoTE types MAY contain one or more X.509 certificates, which SHALL nonetheless be referenced on a QTSP TL.
ServiceStatus [ETSI TS 119 602, clause 6.6.4] REQUIRED String The ServiceStatus component SHALL be present for PuB-EAA Provider LoTE. Specific URIs MAY be used as the value to indicate if the entity is notified or withdrawn.

The ServiceStatus component SHALL NOT be used for the other LoTE types.
StatusStartingTime [ETSI TS 119 602, clause 6.6.5] REQUIRED String The StatusStartingTime component SHALL be present for PuB-EAA Provider LoTE.

The StatusStartingTime component SHALL NOT be used for the other LoTE types.
SchemeServiceDefinitionURI [ETSI TS 119 602, clause 6.6.6] REQUIRED Array No additional requirements.
ServiceSupplyPoint [ETSI TS 119 602, clause 6.6.7] REQUIRED Array For the Registrar LoTE, the ServiceSupplyPoint component SHALL contain the URI where the Register is available in a machine-processable manner. Any signed or sealed Register data obtained at this URI SHALL be able to be authenticated using one of the certificates listed in the ServiceDigitalIdentity component.

No additional requirements for the other LoTE types.
TEServiceDefinitionURI [ETSI TS 119 602, clause 6.6.8] REQUIRED Array No additional requirements.
ServiceInformationExtensions [ETSI TS 119 602, clause 6.6.9] REQUIRED Array For a Wallet Provider (WP), the ServiceInformationExtensions component SHALL be used to provide the reference number of the Wallet Solution identified by the ServiceName component.

No additional requirements for the other LoTE types.

The following table details the additional requirements the ServiceHistory.ServiceHistoryInstance Object component SHALL satisfy depending on the LoTE type.

Parameter Defined in Presence Format Description
ServiceName [ETSI TS 119 602, clause 6.6.2] REQUIRED Array No additional requirements.
ServiceDigitalIdentity [ETSI TS 119 602, clause 6.6.3] REQUIRED Object The ServiceDigitalIdentity of a PuB-EAA Provider LoTE SHALL contain at least the X509SKI component and SHALL NOT contain an X509Certificate component.

No additional requirements for the other LoTE types.
ServiceStatus [ETSI TS 119 602, clause 6.6.4] REQUIRED String No additional requirements.
StatusStartingTime [ETSI TS 119 602, clause 6.6.5] REQUIRED String No additional requirements.

Embedded Disclosure Policy

This section specifies the Embedded Disclosure Policy (EDP) for the EUDI Wallet ecosystem. It defines the following aspects:

  • What an EDP is, and which policy types are supported.
  • The data model and structure.
  • The distribution mechanism.
  • The lifecycle rules.

The authorization evaluation logic that the WI applies when processing an EDP during presentation is defined in the Authorization Process section of this specification.

Definition and Applicability

An Embedded Disclosure Policy is defined in Article 2(9) of [CIR 2024/2979] as:

"A set of rules, embedded in an electronic attestation of attributes by its provider, that indicates the conditions that a wallet-relying party has to meet to access the electronic attestation of attributes".

The EDP allows APs to indicate which RPs can access specific Attestations. APs can optionally express an EDP for their Attestations (EDP_01). The Article 10 of [CIR 2024/2979] establishes that Wallet Providers SHALL ensure that Attestations with common EDPs (as listed in Annex III of [CIR 2024/2979]) can be processed by their Wallet Instances.

EDPs are applicable to QEAAs, PuB-EAAs, and non-qualified EAAs. They are not applicable to PIDs as the EUDI Wallet Regulation does not provide any requirement for PIDs to contain an EDP (EDP_01 note).

The main use cases enabled by EDPs are:

  • Implementing sector-specific access control (e.g., only public sector RPs or only healthcare RPs).
  • Implementing Member-State-specific access control (e.g., only RPs registered within a specific Member State).

Policy Types

Annex III of [CIR 2024/2979] defines three common EDP types:

No Policy. No EDP is present, or the EDP explicitly indicates that no restrictions apply (ISS-MDATA-EBD-4.2.5.2-06).

Authorized Relying Parties Only. The EDP contains a list of RPs that are allowed to access the Attestation. According to [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-07), authorized RPs are identified by their subject distinguished name as held in the WRPAC, in LDAP string form as defined in RFC 4514. For legal persons, the relevant DN attributes are commonName, organizationName, organizationIdentifier, and countryName. For natural persons: commonName, givenName, surname, serialNumber, and countryName. The organizationIdentifier attribute type is represented by the LDAP string "ORGID"; the serialNumber attribute type is represented by "SN" (according to [ETSI TS 119 472-3] NOTE 1 and NOTE 2 to ISS-MDATA-EBD-4.2.5.2-07).

Note

[ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-07) also allows identifying authorized RPs by URI-encoded entitlements as specified in [ETSI TS 119 475], held in the WRPRC. [ETSI TS 119 475, Annex A.3] defines sub-entitlements for Service Providers, currently for Payment Service Providers (e.g. https://uri.etsi.org/19475/SubEntitlement/psp/psp-ai). Future versions may include additional sector-specific sub-entitlements at national or EU level. This specification supports both the subject DN and the entitlement URI identification mechanisms.

Note

[ARF] HLR EDP_02 refers to "EU-wide unique identifiers", as defined in Reg_32, for the authorized RP list. [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-07) identifies authorized RPs by their subject DN from the WRPAC. The organizationIdentifier attribute within the DN has the same semantics as the identifier given in Reg_32. This specification aligns with the [ETSI TS 119 472-3] formulation. Future ARF versions are expected to align accordingly.

Specific Root of Trust. The EDP contains a list of trusted roots or intermediate certificates. Only RPs whose WRPACs chain to one of these roots are allowed to access the Attestation. According to [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-08/09), each authorized root is identified by its issuer distinguished name in LDAP string form as defined in RFC 4514 and the issuer's certificate serial number.

Data Model

The data model of the EDP is defined in [ETSI TS 119 472-3, Section 4.2.5.2] through requirements ISS-MDATA-EBD-4.2.5.2-01 to ISS-MDATA-EBD-4.2.5.2-13.

Data Model Requirements

The data model defines the following elements:

  • The EDP SHALL be identified by a unique URI (ISS-MDATA-EBD-4.2.5.2-01). The EDP MAY be accessible through this URI (ISS-MDATA-EBD-4.2.5.2-02).
  • The EDP association with an EAA SHALL be established by including its unique URI. The AP SHALL either include the URI together with the full policy data set, or provide only the URI if the policy data set has already been pre-loaded into the WI (ISS-MDATA-EBD-4.2.5.2-03).
  • The EDP MAY include a description of the applicability of the policy to a particular community and/or class of application with common security requirements (ISS-MDATA-EBD-4.2.5.2-04).
  • The EDP MAY include an identifier of the authority responsible for the policy (ISS-MDATA-EBD-4.2.5.2-05).
  • The EDP MAY indicate that no policy restrictions apply for the associated EAA (ISS-MDATA-EBD-4.2.5.2-06).
  • The EDP MAY contain a list of authorized RPs, identified by subject DN as described in the Policy Types section (ISS-MDATA-EBD-4.2.5.2-07).
  • The EDP MAY define a specific list of roots of trust, identified by issuer DN and certificate serial number (ISS-MDATA-EBD-4.2.5.2-08/09).
  • Other information MAY be included in an EDP Extension which MAY be ignored by the WI (ISS-MDATA-EBD-4.2.5.2-10). The WI SHOULD be able to process the EDP even if unrecognized extensions are present (ISS-MDATA-EBD-4.2.5.2-11).
  • An EDP Extension MAY contain alternative policy rules to be applied to specified attributes within the EAA which are subject to Selective Disclosure (ISS-MDATA-EBD-4.2.5.2-12).
  • The EDP SHOULD contain a link to a website of the AP explaining the disclosure policy in layman's terms (ISS-MDATA-EBD-4.2.5.2-13, EDP_05).

Note

[ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-12) provides for attribute-level policies, where alternative policy rules (no policy, authorized RP only, or specific root of trust) can be defined for specific attributes within an EAA that are subject to Selective Disclosure. This capability is recognized but is not further detailed in this specification. Detailed handling of attribute-level EDP will be addressed when the ETSI JSON schema for EDP is finalized and the policy mechanisms are fully defined.

Structure and Encoding

The following JSON structure is derived from the [ETSI TS 119 472-3] data model requirements.

Warning

The JSON schema and the parameter names are defined in this section and are not based on a normative ETSI specification. [ETSI TS 119 472-3, Section 4.2.5.2] defines the high level requirements for data model, but the final JSON schema will be published separately by ETSI (see [ETSI TS 119 472-3, Annex C]). The structure defined here is an implementation profile based on the ETSI data model requirements, and parameter names MAY change when the ETSI schema is published.

Parameter Type Description Based on
policy_uri string (URI) REQUIRED. Unique identifier of the EDP. ISS-MDATA-EBD-4.2.5.2-01
policy_type string REQUIRED. Policy type. Values: "no_policy", "authorized_rp_only", "specific_root_of_trust". ISS-MDATA-EBD-4.2.5.2-06/07/08
description string OPTIONAL. Description of the applicability of the policy to a particular community or class of application. ISS-MDATA-EBD-4.2.5.2-04
policy_authority string OPTIONAL. Identifier of the authority responsible for the policy. ISS-MDATA-EBD-4.2.5.2-05
policy_info_url string (URL) OPTIONAL. Link to a website explaining the policy in layman's terms. ISS-MDATA-EBD-4.2.5.2-13, EDP_05
authorized_parties array of objects REQUIRED if policy_type is "authorized_rp_only". List of authorized RPs. ISS-MDATA-EBD-4.2.5.2-07
authorized_parties[].subject_dn string OPTIONAL. Subject DN of the RP from the WRPAC, in LDAP string form as defined in RFC 4514. At least one of subject_dn or entitlement_uri SHALL be present in each element. ISS-MDATA-EBD-4.2.5.2-07
authorized_parties[].entitlement_uri string (URI) OPTIONAL. URI-encoded entitlement or sub-entitlement as specified in [ETSI TS 119 475, Annex A], held in the WRPRC. At least one of subject_dn or entitlement_uri SHALL be present in each element. ISS-MDATA-EBD-4.2.5.2-07
trusted_roots array of objects REQUIRED if policy_type is "specific_root_of_trust". List of trusted roots. ISS-MDATA-EBD-4.2.5.2-08
trusted_roots[].issuer_dn string REQUIRED. Issuer DN in LDAP string form compliant with RFC 4514. ISS-MDATA-EBD-4.2.5.2-09
trusted_roots[].serial_number string REQUIRED. Certificate serial number of the issuer. ISS-MDATA-EBD-4.2.5.2-09

Distribution

The EDP is distributed through Credential Issuer Metadata at issuance time. The AP SHALL include the EDP (if any) by value in the Issuer Metadata, within the credential_configurations_supported parameter, in compliance with [OpenID4VCI] or the extension thereof specified in [ETSI TS 119 472-3] (EDP_09). The EDP SHALL NOT be revealed to the RP through the presentation protocol (per [ETSI TS 119 472-3, Section 4.2.5.1]).

Warning

According to ISS-MDATA-EBD-4.2.5.2-03, the AP may provide only the policy_uri if the policy data set has already been pre-loaded into the WI. As the mechanism for pre-loading policies into a WI is not specified in the current normative references, this option SHALL be considered out-of-scope of this specification, at least until further implementation details are provided by ETSI.

As described in section Authorization Process, during attestation issuance, the EDP (if available) is stored locally by the WI and it is associated with the specific Attestation for which it was retrieved.

Lifecycle

Validity Binding

The locally stored EDP SHALL remain valid as long as the Attestation it is associated with is valid and not revoked. The EDP SHALL NOT have an independent validity status or revocation mechanism separate from the Attestation.

Update Mechanism

If an AP adds, changes, or deletes an EDP for an Attestation, the AP SHALL revoke that Attestation (EDP_11). The WI detects the policy change indirectly through the normal Attestation status checking mechanism (Status List), which will report that the Attestation is revoked. The locally stored EDP is then implicitly invalidated together with the Attestation. The User needs to request a new issuance to obtain the Attestation with the updated policy.

Even a minor policy change (e.g., adding a single RP to the authorized list) requires revocation and re-issuance. The timing of detection depends on when the WI checks the Attestation status: if the WI checks only at presentation time, a policy change will not be detected until the next presentation attempt.

Warning

Proactive refresh. The AP MAY provide EDP though its URI. In this case, the Wallet Instance MAY proactively fetch the policy content at the policy_uri to check for updates, without waiting for an Attestation revocation signal. However, this mechanism SHALL NOT be used in this specification for the following reason:

  • It enables AP to unilaterally change an EDP, and it may introduce privacy risks and management overhead (as stated in the Discussion Topic D)
  • Technical details of this mechanism are not defined within ETSI standard.
References
Reference Description
[CIR 2024/2979, Article 2(9)] Definition of Embedded Disclosure Policy
[CIR 2024/2979, Article 10] Wallet Provider (WP) obligations for EDP processing
[CIR 2024/2979, Annex III] Common EDP types
[ETSI TS 119 472-3, Section 4.2.5] EDP data model requirements (ISS-MDATA-EBD-4.2.5.2-01 through 13)
[ETSI TS 119 475] Annex A.2 Common entitlement URIs
[ETSI EN 319 412-1, Section 5.1.4] organizationIdentifier semantics
RFC 4514 LDAP string representation of Distinguished Names

Trust Anchor Certificate

This section defines an interoperable X.509 certificate profile for entity trust anchors used in the EUDIW ecosystem.

A Trust Anchor is a trusted public key (and associated data) used as an input to certification path validation. In this profile, the Trust Anchor is represented and distributed as an X.509 certificate. When published through TLs or LoTE infrastructure, that certificate is referenced from the corresponding service entry through the serviceDigitalIdentity component.

According to HAIP, clause 6.1:

The implication of that is that the Attestation Provider's sign/seal certificate SHALL NOT be a Trust Anchor certificate.

Out of Scope

End-entity "provider sign/seal certificates" issued to PID Providers, Wallet Providers, EAA/QEAA Providers, and PSBEAA Providers. Those are profiled by [ETSI TS 119 412-6] and referenced [ETSI EN 319 412] parts.

Definitions

Trust Anchor

A trust anchor is an authoritative entity represented by a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative.

Entity Trust Anchor Certificate (EUDIW context)

An Entity Trust Anchor Certificate is an X.509 certificate that is explicitly trusted by policy because it is published as a Trust Anchor for a given entity/service in LoTE/Trusted List trust sources.

Warning

A Trust Anchor certificate may be self-signed or non-self-signed. In both cases it is treated as a Trust Anchor if the relying party's trust policy (here: LoTE/Trusted List-based trust source) designates it as such.

Termination of certificate path validation

Relying parties validate a presented certificate by building a certification path that terminates at a Trust Anchor. In this ecosystem, path construction and validation SHALL terminate at the first certificate that matches a LoTE-listed Trust Anchor.

References
  • CIR 2024/2980
  • ETSI TS 119 602
  • ETSI TS 119 612
  • RFC 5280
  • RFC 5914

Trust model assumptions for entity trust anchors

What the trust anchor certificate is used for

The entity trust anchor certificate is not the certificate used to sign application payloads. Instead, it is used as the trust termination point for validating other certificates (typically end-entity certificates) that are used to sign/seal data.

CA capability requirement (issuer-style trust anchor)

If the entity trust anchor certificate is used to issue/sign other certificates (i.e., it appears as an issuer in the validated path), then it SHALL be a CA certificate for X.509 path validation purposes (i.e., it SHALL signal CA capability using X.509 v3 extensions).

Validity checking policy

Relying parties SHALL check the validity period of the trust anchor certificate and treat it as invalid if expired or not yet valid.

Self-signed and non-self-signed trust anchors

A LoTE/Trusted List-published trust anchor certificate MAY be:

  • Self-signed (traditional root CA style); or
  • Non-self-signed but treated as a trust anchor by policy (a "pinned" intermediate CA certificate).

Relying parties SHALL NOT require an additional issuer chain above a LoTE-designated trust anchor, even if it is not self-signed, because the trust anchor is a trust-store input designated by policy.

Trust Anchor Certificate Profile (X.509)

Presence semantics

The column "Presence" in tables below contains the specification of the presence of the certificate parameter as follows:

  • REQUIRED: The parameter SHALL be present.
  • REQUIRED (C): The parameter SHALL be present if the condition specified in the "Description" column is fulfilled.
  • OPTIONAL: The parameter is not required and can be omitted.

The column "Criticality" of the certificate extensions uses the semantics defined in RFC 5280.

Basic certificate fields

The following table lists common parameters that are mandatory for an entity trust anchor certificate.

Parameter Defined in Presence Format Description
version [RFC 5280] §4.1.2.1 REQUIRED [0] EXPLICIT INTEGER Indicates the version of the encoded certificate. For this profile, it SHALL be v3 (2).
serialNumber [RFC 5280] §4.1.2.2 REQUIRED INTEGER The serial number of the certificate.
signature [RFC 5280] §4.1.2.3 REQUIRED SEQUENCE Identifies the signature algorithm used by the issuer to sign the certificate.
issuer [RFC 5280] §4.1.2.4 REQUIRED Name Identifies the entity that signed and issued the certificate. For self-signed trust anchors, the issuer SHALL be identical to the subject.
validity [RFC 5280] §4.1.2.5 REQUIRED SEQUENCE Time interval during which the certificate is valid (notBefore, notAfter).
subject [RFC 5280] §4.1.2.6 REQUIRED Name Identifies the entity associated with the public key.
subjectPublicKeyInfo [RFC 5280] §4.1.2.7 REQUIRED SEQUENCE Carries the public key and identifies the algorithm with which the key is used.
extensions [RFC 5280] §4.1.2.9 REQUIRED [3] EXPLICIT SEQUENCE A sequence of one or more certificate extensions.

Required extensions

The following table lists the extensions that are mandatory or conditional for an entity trust anchor certificate.

Parameter Defined in Presence Criticality Format Description
basicConstraints [RFC 5280] §4.2.1.9 REQUIRED C SEQUENCE SHALL indicate cA = TRUE. The pathLenConstraint field:
  • is OPTIONAL;
  • if present, SHALL limit the number of non-self-issued intermediate CA certificates below this trust anchor;
  • it is RECOMMENDED to set pathLenConstraint = 0 to prevent subordinate CA layers, unless a documented operational need exists to support additional intermediate CA tiers.
keyUsage [RFC 5280] §4.2.1.3 REQUIRED C BIT STRING SHALL include keyCertSign. MAY include cRLSign if the CA signs CRLs.
subjectKeyIdentifier [RFC 5280] §4.2.1.2 REQUIRED NC OCTET STRING Provides a key identifier for the trust anchor public key, enabling reliable chain building and LoTE matching.
authorityKeyIdentifier [RFC 5280] §4.2.1.1 REQUIRED (C) NC SEQUENCE REQUIRED for non-self-signed trust anchors to facilitate chain building towards the LoTE trust anchor. For self-signed certificates it is RECOMMENDED.
Note: Path length constraint policy

The pathLenConstraint restricts the depth of certification paths below the trust anchor.

  • A value of 0 means that the trust anchor MAY issue end-entity certificates but SHALL NOT allow additional non-self-issued intermediate CA certificates in the path.
  • Absence of the pathLenConstraint implies that no explicit limit is imposed by the certificate itself.

This profile allows the field to be OPTIONAL to support interoperability with different PKI deployment models. However, setting pathLenConstraint = 0 is RECOMMENDED to reduce trust hierarchy complexity, improve predictability of certificate chains, and limit the risk associated with unintended subordinate certification authorities.

Optional (deployment-driven) extensions

The following extensions are OPTIONAL because their necessity depends on the revocation/status model used in a given deployment.

Parameter Defined in Presence Criticality Format Description
authorityInfoAccess (AIA) [RFC 5280] §4.2.2.1 OPTIONAL NC SEQUENCE MAY include id-ad-caIssuers and/or id-ad-ocsp access locations.
cRLDistributionPoints [RFC 5280] §4.2.1.13 OPTIONAL NC SEQUENCE MAY include CRL distribution point URIs when CRL-based revocation is used.
certificatePolicies [RFC 5280] §4.2.1.4 OPTIONAL NC SEQUENCE MAY be used to signal policy OIDs relevant to the issuing CA's practices.
authorityInfoAccess [RFC 5280] §4.2.2.1 REQUIRED (C) NC SEQUENCE If the certificate contains the Basic Constraints extension with cA = TRUE and pathLenConstraint > 0, then this extension SHALL be present and SHALL contain at least one AccessDescription with:
  • accessMethod = id-ad-caIssuers
  • accessLocation = URI that SHALL use the http:// scheme and SHALL NOT use the https:// scheme

Certificate content requirements derived from LoTE

Below are more in details defined requirements on the Trust Anchor certificate fields based on ETSI TS 119 602 and ETSI TS 119 612.

Subject Distinguished Name requirements
  • The Trust Anchor certificate SHALL contain a non-empty subject distinguished name.
  • The subject distinguished name SHALL identify the entity associated with the trust anchor public key in a clear and unambiguous manner.
  • If the Trust Anchor represents a legal or organizational entity, the subject distinguished name SHALL contain an organizationName attribute identifying that entity.
Validity requirements
  • The Trust Anchor certificate SHALL contain a validity field specifying the notBefore and notAfter time interval during which the certificate is valid.
  • Relying parties SHALL check the validity period of the Trust Anchor certificate and SHALL treat the certificate as invalid if the current time is before notBefore or after notAfter.
Issuer Distinguished Name requirements
  • The Trust Anchor certificate SHALL contain an issuer distinguished name.
  • If the Trust Anchor certificate is self-signed, the issuer distinguished name SHALL be identical to the subject distinguished name.
  • If the Trust Anchor certificate is non-self-signed, the issuer distinguished name SHALL identify the entity that signed and issued the certificate and MAY differ from the subject distinguished name.
Subject Key Identification requirements
  • The Trust Anchor certificate SHALL contain a non-critical subjectKeyIdentifier extension identifying the trust anchor public key.
  • The value of the subjectKeyIdentifier extension SHOULD be derived from the trust anchor public key in a stable and interoperable manner.
  • The subjectKeyIdentifier extension SHOULD support reliable certificate path construction and certificate matching in LoTE / Trusted List based deployments.
Authority Key Identifier requirements
  • For a non-self-signed Trust Anchor certificate, a non-critical authorityKeyIdentifier extension SHALL be present.
  • For a self-signed Trust Anchor certificate, a non-critical authorityKeyIdentifier extension is RECOMMENDED.
  • Where present, the authorityKeyIdentifier extension SHOULD identify the key of the certificate issuer.
Basic Constraints requirements
  • The Trust Anchor certificate SHALL contain a critical basicConstraints extension with cA set to TRUE.
  • The pathLenConstraint field in the basicConstraints extension MAY be present.
  • If present, pathLenConstraint SHALL limit the number of non-self-issued intermediate CA certificates below the Trust Anchor certificate.
  • Setting pathLenConstraint to 0 is RECOMMENDED unless a documented operational need exists to support additional subordinate CA tiers.
Key Usage requirements
  • The Trust Anchor certificate SHALL contain a critical keyUsage extension that includes the keyCertSign bit.
  • The keyUsage extension MAY include the cRLSign bit where the Trust Anchor certificate is used by a CA that signs certificate revocation lists.
  • The keyUsage extension SHOULD be limited to usages consistent with the certification authority role of the Trust Anchor certificate.

Examples (pseudo-structure)

The following examples are illustrative. They focus on the profile-relevant fields and extensions.

Example A — Self-signed entity trust anchor (root-style)

AccessCertificate trustAnchor = {
  tbsCertificate: {
    version: 2,  // v3
    serialNumber: "0x01A2B3C4...",
    signature: AlgorithmIdentifier { oid: "1.2.840.113549.1.1.11", params: NULL },

    issuer:  DistinguishedName {
      countryName: "CZ",
      organizationName: "Example Entity Trust Anchor CA",
      commonName: "Example Entity Trust Anchor Root"
    },

    validity: {
      notBefore: "2026-01-01T00:00:00Z",
      notAfter:  "2031-01-01T00:00:00Z"
    },

    subject: DistinguishedName {
      countryName: "CZ",
      organizationName: "Example Entity Trust Anchor CA",
      commonName: "Example Entity Trust Anchor Root"
    },

    subjectPublicKeyInfo: {
      algorithm: AlgorithmIdentifier { oid: "1.2.840.113549.1.1.1", params: NULL },
      subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
    },

    extensions: [
      Extension {
        oid: "2.5.29.19", // basicConstraints
        critical: true,
        value: BasicConstraints { cA: true, pathLenConstraint: 0 }
      },
      Extension {
        oid: "2.5.29.15", // keyUsage
        critical: true,
        value: KeyUsage { keyCertSign: true, cRLSign: true }
      },
      Extension {
        oid: "2.5.29.14", // subjectKeyIdentifier
        critical: false,
        value: SubjectKeyIdentifier { keyIdentifier: "SHA-1(SUBJECT_PUBLIC_KEY_VALUE)" }
      },
      Extension {
        oid: "2.5.29.35", // authorityKeyIdentifier
        critical: false,
        value: AuthorityKeyIdentifier { keyIdentifier: "SHA-1(SUBJECT_PUBLIC_KEY_VALUE)" }
      }
    ]
  }
}

Example B — Non-self-signed entity trust anchor (pinned intermediate CA)

AccessCertificate trustAnchor = {
  tbsCertificate: {
    version: 2,  // v3
    serialNumber: "0x0F0E0D0C...",
    signature: AlgorithmIdentifier { oid: "1.2.840.113549.1.1.11", params: NULL },

    issuer: DistinguishedName {
      countryName: "CZ",
      organizationName: "Example Superior CA",
      commonName: "Example Superior CA"
    },

    validity: {
      notBefore: "2026-01-01T00:00:00Z",
      notAfter:  "2029-01-01T00:00:00Z"
    },

    subject: DistinguishedName {
      countryName: "CZ",
      organizationName: "Example Entity Trust Anchor CA",
      commonName: "Example Entity Trust Anchor (Pinned Intermediate)"
    },

    subjectPublicKeyInfo: {
      algorithm: AlgorithmIdentifier { oid: "1.2.840.113549.1.1.1", params: NULL },
      subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
    },

    extensions: [
      Extension {
        oid: "2.5.29.19", // basicConstraints
        critical: true,
        value: BasicConstraints { cA: true, pathLenConstraint: 0 }
      },
      Extension {
        oid: "2.5.29.15", // keyUsage
        critical: true,
        value: KeyUsage { keyCertSign: true }
      },
      Extension {
        oid: "2.5.29.14", // subjectKeyIdentifier
        critical: false,
        value: SubjectKeyIdentifier { keyIdentifier: "SHA-1(SUBJECT_PUBLIC_KEY_VALUE)" }
      },
      Extension {
        oid: "2.5.29.35", // authorityKeyIdentifier
        critical: false,
        value: AuthorityKeyIdentifier { keyIdentifier: "HEX(KEYID_OF_SUPERIOR_CA_PUBLIC_KEY)" }
      },
      Extension {
        oid: "1.3.6.1.5.5.7.1.1", // authorityInfoAccess
        critical: false,
        value: AuthorityInfoAccess [
          AccessDescription {
            accessMethod: "1.3.6.1.5.5.7.48.2", // id-ad-caIssuers
            accessLocation: URI("https://ca.example.test/caIssuers/superior-ca.cer")
          }
        ]
      }
    ]
  }
}

Entity Sign/Seal Certificate

This section describes the purpose, format and content of End Entity Sign/Seal Certificates in the European Digital Identity Wallet (EUDIW) ecosystem that are used for signing and sealing purposes.

References

To guarantee the interoperability across all entities of the EUDIW ecosystem, End Entity Sign/Seal Certificates should adhere to common requirements, with respect to their content and format. The technical specifications describing such content are distributed between multiple documents and for a purpose of proper referencing are listed below:

  • ETSI EN 319 411-1
  • ETSI EN 319 411-2 (applicable if the certificate is qualified)
  • ETSI EN 319 412-1
  • ETSI EN 319 412-2 (applicable if the certificate is issued to natural persons)
  • ETSI EN 319 412-3 (applicable if the certificate is issued to legal persons)
  • ETSI EN 319 412-5 (applicable if the certificate is qualified)
  • ETSI TS 119 412-6 (profiles the Sign/Seal certificate for various entities in the EUDIW ecosystem)
  • ETSI TS 119 612
  • RFC 3986
  • RFC 5280

End Entity Sign/Seal Certificate Content

In the following sections we are providing tables with parameters and extensions that are mandatory for the specific End Entity Sign/Seal Certificate as described in ETSI specifications. For simplicity, optional attributes are omitted from this document, unless their requirement is conditional, or it could be useful to mention them.

The column "Presence" in tables below contains the specification of the presence of the certificate parameter as follows:

  • REQUIRED: The parameter SHALL be present.
  • REQUIRED (C): The parameter SHALL be present if the condition specified in the "Description" column is fulfilled.
  • OPTIONAL: The parameter is not required and can be skipped.

The extensions field of the Trust Anchor Certificates SHALL contain various extensions, each of which is an ASN.1 SEQUENCE containing the following fields:

Parameter Defined in Presence Format Description
[extension_name].extnID [RFC 5280] clause 4.1.2.9 REQUIRED OBJECT IDENTIFIER The OID identifying the specific extension type.
[extension_name].critical [RFC 5280] clause 4.1.2.9 OPTIONAL BOOLEAN Indicates whether the extension is critical. DEFAULT is FALSE.
[extension_name].extnValue [RFC 5280] clause 4.1.2.9 REQUIRED OCTET STRING Contains the DER encoding of the ASN.1 value corresponding to the extension type identified by extnID.

The column "Criticality" of the certificate extensions has the semantics defined in [RFC 5280, clause 4.2] and uses the following acronyms:

  • C: The extension SHALL be considered critical.
  • NC: The extension SHALL be considered non-critical.

General Content

The following table lists all the common parameters that are mandatory or conditional for end-certificates of all entities of EUDIW ecosystem described in this document. Details of those parameters are described in IETF RFC 5280 and further scoped in ETSI EN 319 412-2 (in case of Natural Persons) and ETSI EN 319 412-3 (in case of Legal Persons).

Parameter Defined in Presence Format Description
version [RFC 5280] clause 4.1.2.1 REQUIRED [0] EXPLICIT INTEGER Indicates the version of the encoded certificate. For this profile, it SHALL be v3 (2).
serialNumber [RFC 5280] clause 4.1.2.2 REQUIRED INTEGER The serial number of the certificate.
signature [RFC 5280] clause 4.1.2.3 REQUIRED SEQUENCE Identifies the signature algorithm used by the CA to sign the certificate. The signature algorithm SHOULD be selected according to [ETSI TS 119 312], but MAY be superseded by national recommendations.
signature.algorithm [RFC 5280] clause 4.1.1.2 REQUIRED OBJECT IDENTIFIER The OID of the signature algorithm.
signature.parameters [RFC 5280] clause 4.1.1.2 OPTIONAL ANY Algorithm-specific parameters, dependent on the algorithm used.
subject [ETSI EN 319 412-2] clause 4.2.4 &
[ETSI EN 319 412-3] clause 4.2.1		 REQUIRED Name Identifies the entity associated with the public key stored in the subject public key field. If present, the size of organizationName, organizationalUnitName and commonName MAY be longer than the limit as stated in [RFC 5280].

If the subject is a natural person, the following attributes SHALL be present:
  • countryName indicating the general context in which other attributes are to be understood;
  • choice of (givenName and/or surname) or pseudonym;
  • commonName indicating a name of the subject;
  • conditionally, serialNumber if the above attributes are not sufficient to ensure subject name uniqueness.
When a natural person subject is associated with an organization, the attributes MAY also identify such organization using attributes like organizationName and organizationIdentifier.

If the subject is a legal person, the following attributes SHALL be present:
  • countryName indicating the country in which the subject is established;
  • organizationName indicating the full registered name of the subject;
  • organizationIdentifier indicating an identification of the subject organization different from the organization name;
  • commonName indicating a name commonly used by the subject to represent itself.
issuer [ETSI EN 319 412-2] clause 4.2.3 REQUIRED Name Identifies the entity that has signed and issued the certificate.

If the issuer is a legal person, the following attributes SHALL be present:
  • countryName indicating the country in which the issuer of the certificate is established;
  • organizationName indicating the full registered name of the certificate issuing organization;
  • commonName indicating a name commonly used by the subject to represent itself;
  • conditionally, an organizationIdentifier if an appropriate registration number is known to exist and it has a value different from the organization name.

If the issuer is a natural person, the following attributes SHALL be present:
  • countryName indicating a country that is consistent with the legal jurisdiction under which certificates are issued;
  • choice of (givenName and/or surname) or pseudonym; if the given name or surname of the issuer is known, the respective attribute SHALL be present;
  • commonName;
  • serialNumber.
validity [RFC 5280] clause 4.1.2.5 REQUIRED SEQUENCE Time interval during which the CA warrants that it will maintain information about the status of the certificate.
validity.notBefore [RFC 5280] clause 4.1.2.5 REQUIRED UTCTime or GeneralizedTime The date on which the certificate validity period begins. Dates through 2049 SHALL use UTCTime; dates in 2050 or later SHALL use GeneralizedTime.
validity.notAfter [RFC 5280] clause 4.1.2.5 REQUIRED UTCTime or GeneralizedTime The date on which the certificate validity period ends. Dates through 2049 SHALL use UTCTime; dates in 2050 or later SHALL use GeneralizedTime.
subjectPublicKeyInfo [RFC 5280] clause 4.1.2.7 REQUIRED SEQUENCE Carries the public key and identifies the algorithm with which the key is used. The subject public key SHOULD be selected according to ETSI TS 119 312 but MAY be superseded by national recommendations.
subjectPublicKeyInfo.algorithm [RFC 5280] clause 4.1.2.7 REQUIRED SEQUENCE The algorithm identifier for the public key.
subjectPublicKeyInfo.subjectPublicKey [RFC 5280] clause 4.1.2.7 REQUIRED BIT STRING The public key itself.
extensions [RFC 5280] clause 4.1.2.9 REQUIRED [3] EXPLICIT SEQUENCE A sequence of one or more certificate extensions.

The following table lists all the common extensions that are mandatory or conditional for end-certificates of all entities of EUDIW ecosystem described in this document. Details of those extensions are described in IETF RFC 5280 and further scoped in ETSI EN 319 412-2 (in case of Natural Persons) and ETSI EN 319 412-3 (in case of Legal Persons).

Parameter Defined in Presence Criticality Format Description
authorityKeyIdentifier [ETSI EN 319 412-2, clause 4.3.1] REQUIRED NC SEQUENCE Extension with the OID 2.5.29.35.

Key identifier for the issuing CA's public key.

Contains: keyIdentifier (OCTET STRING), authorityCertIssuer (GeneralNames), and authorityCertSerialNumber (INTEGER).
keyUsage [ETSI EN 319 412-2, clause 4.3.2] &
[ETSI EN 319 412-3, clause 4.3.1]		 REQUIRED C BIT STRING Extension with the OID 2.5.29.15.

It SHALL be one of the following:
  1. non-repudiation
  2. non-repudiation and digital signature
  3. digital signature
  4. digital signature and (key encipherment or key agreement)
  5. key encipherment or key agreement
  6. non-repudiation and digital signature and (key encipherment or key agreement)
Type A, C, or E should be used to avoid mixed usage of keys.

Certificates issued to natural persons and used to validate commitment to signed content (e.g., documents/agreements) SHALL be limited to type A, B, or F (type A should be used).

Certificates issued to legal persons and used to validate digital signatures over content SHALL be limited to type A, B, or F (type A should be used).

Certificate issuers are invited to take into account the security implications, particularly SC-1, when this parameter is set up.
cRLDistributionPoints [ETSI EN 319 412-2, clause 4.3.11] REQUIRED (C) NC SEQUENCE Extension with the OID 2.5.29.31.

Sequence of distributionPoint represented by a CHOICE of FullName (GeneralNames) or nameRelativeToCRLIssuer, reasons (BIT STRING), and cRLIssuer (GeneralNames).

Applicable condition: If the certificate does not include any access location of an OCSP responder or the validity assured extension as defined in [ETSI EN 319 412-1].

It contains at least one reference to a publicly available CRL.
authorityInfoAccess [ETSI EN 319 412-2, clause 4.4.1] REQUIRED NC SEQUENCE Extension with the OID 1.3.6.1.5.5.7.1.1.

Sequence of AccessDescription, containing an accessMethod (OID) and an accessLocation (GeneralName).

It SHALL at least include the id-ad-caIssuers OID specifying at least one access location of a valid CA certificate of the issuing CA.

If OCSP is supported, it SHALL include the id-ad-ocsp OID specifying at least one access location of an OCSP responder providing status information for the present certificate.

If the certificate does not include any CRL distribution point and does not include the validity assured extension, a reference to at least one OCSP responder SHALL be present.
certificatePolicies [RFC 3647, clause 3.3.1] &
[RFC 5280, clause 4.2.1.4]		 REQUIRED NC SEQUENCE Sequence of PolicyInformation elements, each being a SEQUENCE of policyIdentifier (OID) and policyQualifiers.

The extension is mandatory as stated in [ETSI EN 319 412-2], and it SHALL contain the identifier of at least one certificate policy which reflects the practices and procedures undertaken by the CA.
subjectAltName [RFC 5280, clause 4.2.1.6] REQUIRED NC SEQUENCE Extension with the OID 2.5.29.17.

Sequence of GeneralName elements, each representing a possible alternative name for the subject of the certificate.

Each GeneralName element contains contact information of the WRP and there SHALL be at least one element among the following:
  • uniformResourceIdentifier indicating a website where the WRP can be contacted for helpdesk/support matters.
  • otherName with type-id id-at-telephoneNumber indicating a phone number for WRP registration/usage matters.
  • rfc822Name indicating an email address for WRP registration/usage matters.
The extension is mandatory as stated in [ETSI TS 119 411-8] clause 6.6.1.
qcStatements (esi4-qcStatement-1) [RFC 3739, clause 3.2.6] &
[ETSI EN 319 412-5, clause 4.2.1]		 REQUIRED (C) NC SEQUENCE QCStatement with the OID 0.4.0.1862.1.1.

Applicable condition: For qualified certificates. It indicates that the certificate is qualified within the defined legal framework. For the eIDAS regulatory environment, the QcCClegislation SHALL be absent.
qcStatements (esi4-qcStatement-4) [RFC 3739, clause 3.2.6] &
[ETSI EN 319 412-5, clause 4.2.2]		 REQUIRED (C) NC SEQUENCE QCStatement with the OID 0.4.0.1862.1.4.

Applicable condition: For qualified certificates. It indicates that the private key related to the certified public key resides in a QSCD according to eIDAS regulation. The extension is mandatory as stated in ETSI EN 319 411-2, GEN-6.6.1-03.
qcStatements (esi4-qcStatement-6) [RFC 3739, clause 3.2.6] &
[ETSI EN 319 412-5, clause 4.2.3]		 REQUIRED (C) NC SEQUENCE QCStatement with the OID 0.4.0.1862.1.6.

Applicable condition: Mandatory for qualified certificates issued to legal persons for the purpose of electronic seal ([ETSI EN 319 412-5, clause 5]). MAY be present for certificates issued to natural persons for the purpose of electronic signatures.

Declares that a certificate is issued for one and only one of the purposes: electronic signature, electronic seal, or website authentication.

Note

In the APTITUDE profiles, Sign/Seal Certificates SHALL be long lived certificates. Thus the noRevAvail and ext-etsi-valassured-ST-certs SHALL NOT be used.

PID Provider Sign/Seal Certificate Content

The following table lists all new or modified parameters that are mandatory or conditional for PID Providers as further scoped in ETSI TS 119 412-6, clause 4.

Parameter Defined in Presence Format Description
issuer [ETSI TS 119 412-6, clause 4.2] REQUIRED Name The same as in General Content above, with an exception for a self-signed certificate. In that case, the content of issuer is the same as defined for the Subject parameter.

The following table lists all new or modified extensions that are mandatory or conditional for PID Providers as further scoped in ETSI TS 119 412-6, clause 4.4.

Parameter Defined in Presence Criticality Format Description
keyUsage [ETSI TS 119 412-6, clause 4.4.1] REQUIRED C BIT STRING It SHOULD contain one (and only one) of the key-usage settings Type A, Type B, Type C, or Type F, as defined in ETSI EN 319 412-2.
subjectKeyIdentifier [ETSI TS 119 412-6, clause 4.4.2] REQUIRED NC BIT STRING For end entity certificates, the subject key identifier extension provides a means of identifying certificates that contain the particular public key used in an application. The subject key identifier SHOULD be derived from the public key using the methods defined in RFC 5280, clause 4.2.1.2.
authorityInfoAccess [ETSI TS 119 412-6, clause 4.4.3] REQUIRED (C) NC SEQUENCE Description is the same as in the General Content above. Applicable condition: Mandatory for non-self-signed certificates.
qcStatements (id-etsi-qct-pid) [ETSI TS 119 412-6, clause 4.5] REQUIRED NC SEQUENCE QCStatement with the OID 0.4.0.194126.1.1 as defined in [ETSI TS 119 412-6, Annex A]
PID Provider Sign/Seal Certificate Example

The following is an example of a PID Provider's non-self-signed end-certificate for legal persons.

AccessCertificate cert = {

  tbsCertificate: {

    version: 2,                     // integer value 2 for v3
    serialNumber: "0x6F3A0B91D2...",
    signature: AlgorithmIdentifier {
      oid: "1.2.840.113549.1.1.11",  // sha256WithRSAEncryption
      params: NULL
    },

    issuer: DistinguishedName {      // issuer attributes for legal person
      countryName: "CZ",
      organizationName: "Example Trust Services CA",
      commonName: "Example CA",
      organizationIdentifier: "VATCZ-123456789"
    },

    validity: {
      notBefore: "2026-01-27T00:00:00Z",
      notAfter:  "2027-01-27T00:00:00Z"
    },

    subject: DistinguishedName {     // subject attributes for legal person
      countryName: "CZ",
      organizationName: "Example of PID Issuer",
      organizationIdentifier: "LEIXYZ-5493001KJTIIGC8Y1R12",
      commonName: "PID Issuer Example"
    },

    subjectPublicKeyInfo: {
      algorithm: AlgorithmIdentifier {
        oid: "1.2.840.113549.1.1.1",
        params: NULL
      },

      subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
    },


    extensions: [

      Extension {
        oid: "2.5.29.35",            // authorityKeyIdentifier
        critical: false,
        value: AuthorityKeyIdentifier {
          keyIdentifier: "HEX(20B_KEYID_OF_ISSUING_CA_PUBLIC_KEY)"
        }
      },

      Extension {
        oid: "2.5.29.15",            // keyUsage
        critical: true,
        value: KeyUsage {
          nonRepudiation: true        // Type A
          // all others false
        }
      },

      Extension {
        oid: "2.5.29.14",    // subject key identifier
        critical: false,
        value: SubjectKeyIdentifier [
          keyIdentifier: "SHA-1(SUBJECT_PUBLIC_KEY_VALUE)"
        ]
      },

      Extension {
        oid: "1.3.6.1.5.5.7.1.1",    // authority information access
        critical: false,
        value: AuthorityInfoAccess [
          AccessDescription {
            accessMethod: "1.3.6.1.5.5.7.48.2",            // id-ad-caIssuers
            accessLocation: URI("https://ca.example.test/caIssuers/issuing-ca.cer")
          },

          AccessDescription {
            accessMethod: "1.3.6.1.5.5.7.48.1",            // id-ad-ocsp
            accessLocation: URI("https://ocsp.example.test")
          }
        ]
      },

      Extension {
        oid: "2.5.29.32",            // certificatePolicies
        critical: false,
        value: CertificatePolicies [
          PolicyInformation {
            policyIdentifier: "0.4.0.194112.1.3",          // qcp-legal-qcsd
            policyQualifiers: [
              CPSuri("https://rpca.example.test/cps")
            ]
          }
        ]
      },

      Extension {
        oid: "1.3.6.1.5.5.7.0.35",   // qcStatements-2 container
        critical: false,
        value: QCStatements [
          QCStatement {
            statementId: "0.4.0.194126.1.1",   // id-etsi-qct-pid
          }
        ]
      },

      Extension {
        oid: "2.5.29.17",            // subjectAltName
        critical: false,
        value: SubjectAltName [
          GeneralName.uniformResourceIdentifier("https://pid.example.test/support"),
          GeneralName.rfc822Name("support@pid.example.test"),
          GeneralName.otherName(
            typeId: "2.5.4.20",       // id-at-telephoneNumber
            value: "+420-111-222-333"
          )
        ]
      },

      Extension {
        oid: "2.5.29.31",            // cRLDistributionPoints
        critical: false,
        value: CRLDistributionPoints [
          DistributionPoint {
            distributionPoint: URI("https://crl.example.test/issuing-ca.crl")
          }
        ]
      }
    ]
  },

  signatureAlgorithm: AlgorithmIdentifier {
    oid: "1.2.840.113549.1.1.11",    // must match/align with tbsCertificate.signature
    params: NULL
  },
  signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}

Wallet Provider Sign/Seal Certificate Content

The following table lists all new or modified parameters that are mandatory or conditional for Wallet Providers as further scoped in ETSI TS 119 412-6, clause 5.1.

Parameter Defined in Presence Format Description
issuer [ETSI TS 119 412-6, clause 5.1] REQUIRED Name The same as in the General Content above, with an exception for self-signed certificate. In that case, the content of issuer is the same as defined for the Subject parameter.

The following table lists all new or modified extensions that are mandatory or conditional for Wallet Providers as further scoped in ETSI TS 119 412-6, clause 5.1 and 5.2.

Parameter Defined in Presence Criticality Format Description
keyUsage [ETSI TS 119 412-6, clause 5.1] REQUIRED C BIT STRING It SHOULD contain one (and only one) of the key-usage settings Type A, Type B, Type C, or Type F, as defined in ETSI EN 319 412-2.
subjectKeyIdentifier [ETSI TS 119 412-6, clause 5.1] REQUIRED NC BIT STRING For end entity certificates, the subject key identifier extension provides a means of identifying certificates that contain the particular public key used in an application. The subject key identifier SHOULD be derived from the public key using the methods defined in RFC 5280, clause 4.2.1.2.
authorityInfoAccess [ETSI TS 119 412-6, clause 5.1] REQUIRED (C) NC SEQUENCE Description is the same as in the General Content above. Applicable condition: Mandatory for non-self-signed certificates.
qcStatements (id-etsi-qct-wal) [ETSI TS 119 412-6, clause 5.2] REQUIRED NC SEQUENCE QCStatement with the OID 0.4.0.194126.1.2 as defined in [ETSI TS 119 412-6, Annex A]
Wallet Provider Sign/Seal Certificate Example

The following is an example of a Wallet Provider's non-self-signed end-certificate for legal persons.

AccessCertificate cert = {

  tbsCertificate: {

    version: 2,                     // integer value 2 for v3
    serialNumber: "0x6F3A0B91D2...",
    signature: AlgorithmIdentifier {
      oid: "1.2.840.113549.1.1.11",  // sha256WithRSAEncryption
      params: NULL
    },

    issuer: DistinguishedName {      // issuer attributes for legal person
      countryName: "CZ",
      organizationName: "Example Trust Services CA",
      commonName: "Example CA",
      organizationIdentifier: "VATCZ-123456789"
    },

    validity: {
      notBefore: "2026-01-27T00:00:00Z",
      notAfter:  "2027-01-27T00:00:00Z"
    },

    subject: DistinguishedName {     // subject attributes for legal person
      countryName: "CZ",
      organizationName: "Example of Wallet Provider",
      organizationIdentifier: "LEIXYZ-5493001KJTIIGC8Y1R12",
      commonName: "Wallet Provider Example"
    },

    subjectPublicKeyInfo: {
      algorithm: AlgorithmIdentifier {
        oid: "1.2.840.113549.1.1.1",
        params: NULL
      },

      subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
    },


    extensions: [

      Extension {
        oid: "2.5.29.35",            // authorityKeyIdentifier
        critical: false,
        value: AuthorityKeyIdentifier {
          keyIdentifier: "HEX(20B_KEYID_OF_ISSUING_CA_PUBLIC_KEY)"
        }
      },

      Extension {
        oid: "2.5.29.15",            // keyUsage
        critical: true,
        value: KeyUsage {
          nonRepudiation: true        // Type A
          // all others false
        }
      },

      Extension {
        oid: "2.5.29.14",    // subject key identifier
        critical: false,
        value: SubjectKeyIdentifier [
          keyIdentifier: "SHA-1(SUBJECT_PUBLIC_KEY_VALUE)"
        ]
      },

      Extension {
        oid: "1.3.6.1.5.5.7.1.1",    // authority information access
        critical: false,
        value: AuthorityInfoAccess [
          AccessDescription {
            accessMethod: "1.3.6.1.5.5.7.48.2",            // id-ad-caIssuers
            accessLocation: URI("https://ca.example.test/caIssuers/issuing-ca.cer")
          },

          AccessDescription {
            accessMethod: "1.3.6.1.5.5.7.48.1",            // id-ad-ocsp
            accessLocation: URI("https://ocsp.example.test")
          }
        ]
      },

      Extension {
        oid: "2.5.29.32",            // certificatePolicies
        critical: false,
        value: CertificatePolicies [
          PolicyInformation {
            policyIdentifier: "0.4.0.194112.1.3",          // qcp-legal-qcsd
            policyQualifiers: [
              CPSuri("https://rpca.example.test/cps")
            ]
          }
        ]
      },

      Extension {
        oid: "1.3.6.1.5.5.7.0.35",   // qcStatements-2 container
        critical: false,
        value: QCStatements [
          QCStatement {
            statementId: "0.4.0.194126.1.2",   // id-etsi-qct-wal
          }
        ]
      },

      Extension {
        oid: "2.5.29.17",            // subjectAltName
        critical: false,
        value: SubjectAltName [
          GeneralName.uniformResourceIdentifier("https://wp.example.test/support"),
          GeneralName.rfc822Name("support@wp.example.test"),
          GeneralName.otherName(
            typeId: "2.5.4.20",       // id-at-telephoneNumber
            value: "+420-111-222-333"
          )
        ]
      },

      Extension {
        oid: "2.5.29.31",            // cRLDistributionPoints
        critical: false,
        value: CRLDistributionPoints [
          DistributionPoint {
            distributionPoint: URI("https://crl.example.test/issuing-ca.crl")
          }
        ]
      }
    ]
  },

  signatureAlgorithm: AlgorithmIdentifier {
    oid: "1.2.840.113549.1.1.11",    // must match/align with tbsCertificate.signature
    params: NULL
  },
  signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}

EAA/QEAA Provider Sign/Seal Certificate Content

EAA and QEAA providers are from the perspective of Sign/Seal end-certificates almost the same and for simplicity we will cover them together.

There are no new or modified parameters or extensions specific for EAA or QEAA Provider as described in ETSI TS 119 412-6, clause 6 and 7.

For EAA Provider there are other requirements that focus on signing of certificates connected to either OCSP Responder or CRL depending on used revocation policy. More information can be found in ETSI TS 119 412-6, clause 6.2.

For QEAA Provider there are regulatory requirements from Regulation (EU) No 910/2014 that have to be met, but they are out of scope of this documentation. More information can be found in ETSI TS 119 412-6, clause 7.1.

EAA/QEAA Provider Sign/Seal Certificate Example

The following is an example of a QEAA Provider attribute not self-signed end-certificate for legal persons.

AccessCertificate cert = {

  tbsCertificate: {

    version: 2,                     // integer value 2 for v3
    serialNumber: "0x6F3A0B91D2...",
    signature: AlgorithmIdentifier {
      oid: "1.2.840.113549.1.1.11",  // sha256WithRSAEncryption
      params: NULL
    },

    issuer: DistinguishedName {      // issuer attributes for legal person
      countryName: "CZ",
      organizationName: "Example Trust Services CA",
      commonName: "Example CA",
      organizationIdentifier: "VATCZ-123456789"
    },

    validity: {
      notBefore: "2026-01-27T00:00:00Z",
      notAfter:  "2027-01-27T00:00:00Z"
    },

    subject: DistinguishedName {     // subject attributes for legal person
      countryName: "CZ",
      organizationName: "Example of EAA/QEAA Provider",
      organizationIdentifier: "LEIXYZ-5493001KJTIIGC8Y1R12",
      commonName: "EAA/QEAA Provider Example"
    },

    subjectPublicKeyInfo: {
      algorithm: AlgorithmIdentifier {
        oid: "1.2.840.113549.1.1.1",
        params: NULL
      },

      subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
    },


    extensions: [

      Extension {
        oid: "2.5.29.35",            // authorityKeyIdentifier
        critical: false,
        value: AuthorityKeyIdentifier {
          keyIdentifier: "HEX(20B_KEYID_OF_ISSUING_CA_PUBLIC_KEY)"
        }
      },

      Extension {
        oid: "2.5.29.15",            // keyUsage
        critical: true,
        value: KeyUsage {
          nonRepudiation: true        // Type A
          // all others false
        }
      },

      Extension {
        oid: "1.3.6.1.5.5.7.1.1",    // authority information access
        critical: false,
        value: AuthorityInfoAccess [
          AccessDescription {
            accessMethod: "1.3.6.1.5.5.7.48.2",            // id-ad-caIssuers
            accessLocation: URI("https://ca.example.test/caIssuers/issuing-ca.cer")
          },

          AccessDescription {
            accessMethod: "1.3.6.1.5.5.7.48.1",            // id-ad-ocsp
            accessLocation: URI("https://ocsp.example.test")
          }
        ]
      },

      Extension {
        oid: "2.5.29.32",            // certificatePolicies
        critical: false,
        value: CertificatePolicies [
          PolicyInformation {
            policyIdentifier: "0.4.0.194112.1.3",          // qcp-legal-qcsd
            policyQualifiers: [
              CPSuri("https://rpca.example.test/cps")
            ]
          }
        ]
      },

      Extension {
        oid: "2.5.29.17",            // subjectAltName
        critical: false,
        value: SubjectAltName [
          GeneralName.uniformResourceIdentifier("https://eaa.example.test/support"),
          GeneralName.rfc822Name("support@eaa.example.test"),
          GeneralName.otherName(
            typeId: "2.5.4.20",       // id-at-telephoneNumber
            value: "+420-111-222-333"
          )
        ]
      },

      Extension {
        oid: "2.5.29.31",            // cRLDistributionPoints
        critical: false,
        value: CRLDistributionPoints [
          DistributionPoint {
            distributionPoint: URI("https://crl.example.test/issuing-ca.crl")
          }
        ]
      }
    ]
  },

  signatureAlgorithm: AlgorithmIdentifier {
    oid: "1.2.840.113549.1.1.11",    // must match/align with tbsCertificate.signature
    params: NULL
  },
  signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}

PuB-EAA Provider Sign/Seal Certificate Content

There are no new or modified parameters specific for PuB-EAA Provider as described in ETSI TS 119 412-6, clause 8.

The following table lists all new or modified extensions that are mandatory or conditional for PuB-EAA Provider as further scoped in ETSI TS 119 412-6, clause 8.2 and 8.3.

Parameter Defined in Presence Criticality Format Description
authorityInfoAccess [ETSI TS 119 412-6, clause 8.1] REQUIRED NC SEQUENCE Description is the same as in the General Content above. It is mandatory for PuB-EAA Provider.
qcStatements (id-etsi-qcs-QcPSB) [ETSI TS 119 412-6, clause 8.3] REQUIRED NC SEQUENCE QCStatement with the OID 0.4.0.194126.1.3 as defined in [ETSI TS 119 412-6, Annex A].
qcStatements (esi4-qcStatement-10) [ETSI TS 119 412-6, clause 8.3] REQUIRED NC SEQUENCE QCStatement with the OID 0.4.0.1862.1.10. Requirements:
  • The QCStatement SHALL contain the identification for the law under which the PuB-EAA Provider is established responsible for the authentic source.
  • Aplicable condition: If there is a well-defined Uniform Resource Identifier (URI) according to IETF RFC 3986 [8] for the unique identification of the legal basis upon which the PuB-EAA Provider is established as authentic source, it should be used here.
  • The QCStatement SHALL contain an unambiguous identification for the authentic source.
  • The QCStatement SHALL contain either the ISO 3166 [7] alpha-2 country codes for applicable law, or in the case of European Union law 'EU'.

For PuB-EAA Provider there are other requirements that focus on signing of certificates connected to either OCSP Responder or CRL depending on used revocation policy. More information can be found in ETSI TS 119 412-6, clause 8.4.

Pub-EAA Provider Sign/Seal Certificate Example

The following is an example of a PuB-EAA Provider's not self-signed end-certificate for legal persons.

AccessCertificate cert = {

  tbsCertificate: {

    version: 2,                     // integer value 2 for v3
    serialNumber: "0x6F3A0B91D2...",
    signature: AlgorithmIdentifier {
      oid: "1.2.840.113549.1.1.11",  // sha256WithRSAEncryption
      params: NULL
    },

    issuer: DistinguishedName {      // issuer attributes for legal person
      countryName: "CZ",
      organizationName: "Example Trust Services CA",
      commonName: "Example CA",
      organizationIdentifier: "VATCZ-123456789"
    },

    validity: {
      notBefore: "2026-01-27T00:00:00Z",
      notAfter:  "2027-01-27T00:00:00Z"
    },

    subject: DistinguishedName {     // subject attributes for legal person
      countryName: "CZ",
      organizationName: "Example of PuB-EAA Provider",
      organizationIdentifier: "LEIXYZ-5493001KJTIIGC8Y1R12",
      commonName: "PuB-EAA Provider Example"
    },

    subjectPublicKeyInfo: {
      algorithm: AlgorithmIdentifier {
        oid: "1.2.840.113549.1.1.1",
        params: NULL
      },

      subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
    },


    extensions: [

      Extension {
        oid: "2.5.29.35",            // authorityKeyIdentifier
        critical: false,
        value: AuthorityKeyIdentifier {
          keyIdentifier: "HEX(20B_KEYID_OF_ISSUING_CA_PUBLIC_KEY)"
        }
      },

      Extension {
        oid: "2.5.29.15",            // keyUsage
        critical: true,
        value: KeyUsage {
          nonRepudiation: true        // Type A
          // all others false
        }
      },

      Extension {
        oid: "2.5.29.14",    // subject key identifier
        critical: false,
        value: SubjectKeyIdentifier [
          keyIdentifier: "SHA-1(SUBJECT_PUBLIC_KEY_VALUE)"
        ]
      },

      Extension {
        oid: "1.3.6.1.5.5.7.1.1",    // authority information access
        critical: false,
        value: AuthorityInfoAccess [
          AccessDescription {
            accessMethod: "1.3.6.1.5.5.7.48.2",            // id-ad-caIssuers
            accessLocation: URI("https://ca.example.test/caIssuers/issuing-ca.cer")
          },

          AccessDescription {
            accessMethod: "1.3.6.1.5.5.7.48.1",            // id-ad-ocsp
            accessLocation: URI("https://ocsp.example.test")
          }
        ]
      },

      Extension {
        oid: "2.5.29.32",            // certificatePolicies
        critical: false,
        value: CertificatePolicies [
          PolicyInformation {
            policyIdentifier: "0.4.0.194112.1.3",          // qcp-legal-qcsd
            policyQualifiers: [
              CPSuri("https://rpca.example.test/cps")
            ]
          }
        ]
      },

      Extension {
        oid: "1.3.6.1.5.5.7.0.35",   // qcStatements-2 container
        critical: false,
        value: QCStatements [
          QCStatement {
            statementId: "0.4.0.194126.1.3",   // id-etsi-qcs-QcPSB
            statementInfo: {
              countryOfLegislation: "CZ",
              authSourceIdentification: "https://authsource.gov.cz/cz/registry/rob",
              legislationIdentification: "https://legislation.gov.cz/eli/cz/sb/2000/365"
            }
          }
        ]
      },

      Extension {
        oid: "2.5.29.17",            // subjectAltName
        critical: false,
        value: SubjectAltName [
          GeneralName.uniformResourceIdentifier("https://pubeaa.example.test/support"),
          GeneralName.rfc822Name("support@pubeaa.example.test"),
          GeneralName.otherName(
            typeId: "2.5.4.20",       // id-at-telephoneNumber
            value: "+420-111-222-333"
          )
        ]
      },

      Extension {
        oid: "2.5.29.31",            // cRLDistributionPoints
        critical: false,
        value: CRLDistributionPoints [
          DistributionPoint {
            distributionPoint: URI("https://crl.example.test/issuing-ca.crl")
          }
        ]
      }
    ]
  },

  signatureAlgorithm: AlgorithmIdentifier {
    oid: "1.2.840.113549.1.1.11",    // must match/align with tbsCertificate.signature
    params: NULL
  },
  signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}

Sign/Seal Certificate Path Validation

When instantiating the Certificate Path Validation algorithm for Sign/Seal Certificate chains, the initialization parameters are defined as follows:

  • The Trust Anchor is the trusted certificate obtained from the ServiceDigitalIdentity component in relevant LoTE (See the table below).
  • The Certification Path is the sequence of \(n\) certificates (\(C_1 \dots C_n\)) provided by the WRP, where:
    • \(C_1\) is the certificate issued by the root Certificate Authority.
    • \(C_n\) is the Sign/Seal Certificate (the target certificate).
    • For any \(i\) in \(1 \dots n-1\), \(C_i\) is the issuer of \(C_{i+1}\).

Note

Regarding Sign/Seal Certificates within APTITUDE, \(n=1\). The Sign/Seal Certificate SHALL be referenced in the x5c claim of the Attestation, while the Trust Anchor referenced in the LoTE SHALL be a self-signed certificate of the entity issuing Sign/Seal Certificates as described in Trust Anchor Certificate.

The following table maps the Sign/Seal Certificate subject to the location of the respective Trust Anchor.

Sign/Seal Certificate subject Attestation signed Trust Anchor location
PID Provider signing PID PID Providers LoTE
Wallet Provider WIA, KA Wallet Providers LoTE
EAA Provider signing EAA MS decision
QEAA Provider signing QEAA TL
Pub-EAA Provider signing PuB-EAA Pub-EAA Providers LoTE