5. Infrastructure of Trust¶
This chapter specifies Trust Artifacts, certificate profiles, and their lifecycle. The trust decision that uses those artifacts is specified in Trust Evaluation Process. Registration and publication of entities are specified in Onboarding System and Lifecycle Management.
The IT-Wallet ecosystem operates within a federated trust infrastructure where participating entities establish cryptographic trust relationships and maintain compliance with common security standards. This infrastructure provides the foundation for secure Digital Credential operations across the ecosystem participants.
Two Trust Frameworks coexist in IT-Wallet. The Trust Framework of each interaction is selected as specified in Trust Framework Selection.
The EUDIW Trust Framework is defined by the eIDAS2 Regulation (EU_2024_1183), its Implementing Regulations and the ARF (EIDAS-ARF). A Wallet Unit that implements only the EUDIW procedures MUST be able to request, present and verify a PID, a (Q)EAA or a PuB-EAA issued by a Provider of any Member State. That Wallet Unit MUST be able to authenticate a Wallet-Relying Party of any Member State that requests those Credentials. PID Providers, QEAA Providers and PuB-EAA Providers MUST support the EUDIW Trust Framework.
The National Trust Framework is a national overlay based on OpenID Federation (OID-FED) combined with an X.509 PKI for Digital Credentials anchored to that framework. It is out of the ARF. It provides registration, onboarding and discovery for entities that operate within the national boundary. Discovery through the National Trust Framework MAY include entities anchored to the EUDIW Trust Framework. That discovery doesn't replace EUDIW registration, notification or the EUDIW trust path.
This section provides first an overview of the entities and processes involved in the trust infrastructure (Overview). Then, it defines the general X.509 Certificate Profile and the Common Trust Artifacts shared by both frameworks, followed by the framework-specific artifacts (EUDIW Trust Artifacts and National Trust Artifacts). Finally, it describes the related lifecycle (Trust Management and Lifecycle).
5.1. Overview¶
To perform a trust evaluation, entities first onboard in the ecosystem (see Onboarding System and Lifecycle Management). A Non-Qualified EAA Provider and a Relying Party declare the Trust Framework of each role there, as specified in Registration Profiles.
Onboarding and, where applicable, European notification release or update the trust artifacts (see Common Trust Artifacts, EUDIW Trust Artifacts and National Trust Artifacts). Trust evaluation then uses those artifacts (see Trust Evaluation Process).
5.2. PKI Architecture¶
The Trust Artifacts of both Trust Frameworks are signed with keys whose public part is certified by a Certification Authority. This section provides the architectural view of these Certification Authorities. It defines which of them are operated within IT-Wallet, which certificates each one issues, and which Trust Anchor is derived from each one and through which channel that Trust Anchor is distributed.
The content of the certificates is not defined here. The common requirements are defined in X.509 Certificate Profile and the specific requirements of each certificate are defined together with the artifact that uses it. The issuance of the certificates is part of the onboarding (see Onboarding Processes). The use of the Trust Anchors at runtime is defined in EUDIW Trust Anchor Validation for the EUDIW Trust Framework and in Signing Trust Anchor Distribution, Wallet Trust Anchor Distribution and Authentication Trust Anchor Distribution for the National Trust Framework.
5.2.1. Certification Hierarchies¶
Within IT-Wallet a single national Root Certification Authority is operated. It issues the certificates of the subordinate Certification Authorities and it is not used for any other purpose. Each subordinate Certification Authority serves one service, and its certificate is the Trust Anchor published for that service.
The following table lists the Certification Authorities, the certificates that are issued by each of them, and the channel through which the derived Trust Anchor is distributed. The Lists of Trusted Entities and the Trusted Lists named in the table are defined in Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities.
Certification Authority |
Issued Certificates |
Trust Anchor Distribution |
|---|---|---|
PID Provider Sign/Seal CA |
PID Providers LoTE. |
|
Wallet Provider Sign/Seal CA |
Wallet Providers LoTE in the EUDIW Trust Framework, and the Federation Trust Anchor Entity Configuration as the distribution channel for the National Wallet Trust Anchor in the National Trust Framework (see Wallet Trust Anchor Distribution). |
|
WRPAC CA |
Access certificates following the Wallet-Relying Party Access Certificate (WRPAC) Profile, issued to the Wallet-Relying Parties. |
Providers of WRPAC LoTE. The same Trust Anchor is also published in the PID Providers LoTE, because the trust anchors of the Access Certification Authorities for PID Providers are notified within the PID Provider notification, separately from the ones for the Wallet-Relying Parties (see [EIDAS-ARF], Topic 31). |
National Authentication CA |
Relying Party authentication certificates used in the Proximity Flow. They follow the same profile as the Wallet-Relying Party Access Certificate. |
Entity Configuration of the Federation Trust Anchor, as Authentication Trust Anchor (see Authentication Trust Anchor Distribution). |
WRPRC Sign/Seal CA |
The Sign/Seal Certificate of the Provider of WRPRC (see Wallet-Relying Party Registration Certificate (WRPRC) Profile). |
Providers of WRPRC LoTE. |
Registrar Sign/Seal CA |
Registrar LoTE. |
|
National EAA Sign/Seal CA |
(Q)EAA Provider Sign/Seal Certificate, for the Digital Credentials anchored to the National Trust Framework. |
Entity Configuration of the Federation Trust Anchor, as Signing Trust Anchor (see Signing Trust Anchor Distribution). For an EAA issued in the EUDIW Trust Framework the Trust Anchor is referenced in the Attestation Rulebook, as described in Trust Anchor Certificate Profile. |
Qualified CA of the QEAA Provider |
(Q)EAA Provider Sign/Seal Certificate, for the QEAA. |
Member State Trusted List, published in accordance with Article 22 of [EIDAS]. |
Qualified CA of the PuB-EAA Provider |
PuB-EAA Provider Sign/Seal Certificate, the qualified certificate supporting the qualified electronic seal of the public sector body (Article 45f(1)(b) of [EIDAS]). |
Member State Trusted List, published in accordance with Article 22 of [EIDAS]. |
The Qualified CA of the QEAA Provider and the PuB-EAA Provider Sign/Seal CA are not subordinate to the national Root Certification Authority. Both belong to the perimeter of a Qualified Trust Service Provider and follow its own supervision and publication regime. The Sign/Seal Certificate of a PuB-EAA Provider is a qualified electronic seal issued by a Qualified Trust Service Provider (Article 45f of [EIDAS]).
5.2.1.1. Revocation Trust Anchors¶
Within these specifications, the following additional conditions apply regarding revocation Trust Anchors:
Within the EUDIW Trust Framework, the Trust Anchors used to validate the revocation mechanisms for WRPRC, PID and PuB-EAA certificate chains are the notified Trust Anchors of the corresponding signing PKIs.
Within the National Trust Framework, the Signing Trust Anchors of EAA Providers are also the Trust Anchors used to validate the revocation status of EAA signing certificate chains.
For Wallet Instance Attestations and Key Attestations, the Wallet Provider MUST use the same Trust Anchor for signature validation and for validation of the applicable status or revocation information. In the EUDIW Trust Framework, this Trust Anchor is published in the Wallet Providers LoTE. In the National Trust Framework, the same key material is distributed as the National Wallet Trust Anchor through the Federation Trust Anchor Entity Configuration (see Wallet Trust Anchor Distribution).
When a Wallet Provider operates in both Trust Frameworks, its National Wallet Trust Anchor MUST be the same certificate as the Trust Anchor notified to the European Commission. That Trust Anchor is published in the Wallet Providers LoTE under the Wallet Provider's
ServiceDigitalIdentity. The national Entity Configuration is an additional distribution channel. The national Entity Configuration MUST NOT introduce a second Trust Anchor.
Note
The Certification Authority that issues the Wallet-Relying Party Access Certificates and the Certification Authority that issues the Relying Party authentication certificates of the National Trust Framework use the same certificate profile.
Note
The Federation Entity Keys are not certified by the Certification Authorities described in this section. The binding between a Federation Entity and its keys is provided by the Entity Configuration and by the Subordinate Statement issued by its superior, which are validated through the Federation Trust Chain and not with a certificate chain (see National Trust Artifacts). The Entity Configuration of the Federation Trust Anchor is used as a distribution channel for the Trust Anchors of the X.509 hierarchies.
5.2.2. Design Principles¶
The hierarchies described above follow the principles listed below.
One Sign/Seal Certification Authority per notified role. Each role that signs or seals an artifact has a distinct Sign/Seal Certification Authority.
A single WRPAC Certification Authority. Within IT-Wallet the access certificates are issued by a single Certification Authority. That Certification Authority issues them both to the Wallet-Relying Parties and to the PID Providers. Those certificates follow the same profile and certificate policy. The Relying Party authentication certificates of the National Trust Framework are issued by a distinct Certification Authority.
No Trust Anchor without a consumer. Within IT-Wallet a Trust Anchor is published in a distribution channel only when a trust evaluation procedure defined in this specification obtains it from that channel.
The Root Certification Authority is outside the certificate chain. The Trust Anchor certificate is the trust termination point of the path validation (see Trust Anchor Certificate Profile). The Root Certification Authority is never evaluated at runtime. Its certificate is not published in any List. The Root Certification Authority provides a common governance to the subordinate Certification Authorities and no trust relationship by itself. A compromise of the Root Certification Authority is not detected by the ordinary path validation, and within IT-Wallet it is managed by re-issuing and re-notifying the affected Trust Anchors.
Only end entities below a published Trust Anchor. Within IT-Wallet the published Trust Anchor is the subordinate Certification Authority of the service. No further Certification Authority layer is issued below that Trust Anchor. This is consistent with the
pathLenConstraintrecommendation of Trust Anchor Certificate Profile.Separation of the keys by purpose. A Trust Anchor published for one purpose is not used to certify the artifacts of another purpose. A verifying entity has to be able to distinguish which Trust Anchors are usable for which category of Attestation, as required by [EIDAS-ARF].
5.3. X.509 Certificate Profile¶
This section defines a general X.509 Certificate Profile, which is further specialized for the following artifacts:
Entity Sign/Seal Certificate Profile (EUDIW and National Trust Framework).
Trust Anchor Certificate Profile (EUDIW and National Trust Framework).
Wallet-Relying Party Access Certificate (WRPAC) Profile (EUDIW Trust Framework).
Registrar Sign/Seal Certificate Profile (EUDIW Trust Framework).
This profile establishes the syntax, semantics and encoding requirements for X.509 certificates based on RFC 5280 and ETSI EN 319 412. Each X.509 certificate profile defined by this specification MUST conform to the requirements of this section unless explicitly stated otherwise.
Field |
Description |
Reference |
|---|---|---|
|
REQUIRED. |
Section 4.1.1.1 |
|
REQUIRED. |
Section 4.1.1.2 |
|
REQUIRED. |
Section 4.1.1.3 |
Note
The rest of the section details the content of the tbsCertificate field only. For additional information on the signatureAlgorithm and signatureValue fields, refer to RFC 5280.
The tbsCertificate field MUST contain a TBSCertificate structure. The TBSCertificate fields MUST conform to RFC 5280#section-4.1.2.
The following table defines the certificate fields applicable to the certificate profile specified in this document. For each field, the table defines its presence requirement, type, description, and corresponding reference in RFC 5280. Individual certificate profiles MAY provide additional contextual notes for these fields. Individual certificate profiles MUST NOT alter the presence requirements specified herein.
Field |
Description |
Reference |
|---|---|---|
|
REQUIRED. It MUST be version 3 (value |
Section 4.1.2.1 |
|
REQUIRED. |
Section 4.1.2.2 |
|
REQUIRED. The referenced algorithm MUST be among those defined in Cryptographic Algorithms. |
Section 4.1.2.3, Section 4.1.1.2 |
|
REQUIRED. It MUST comply with the applicable requirements of [ETSI EN 319 412-2] (Clause 4.2.3.1 for legal persons, Clause 4.2.3.2 for natural persons), as specified by the corresponding certificate profile. |
Section 4.1.2.4 |
|
REQUIRED. |
Section 4.1.2.5 |
|
REQUIRED. It MUST comply with the applicable requirements of [ETSI EN 319 412-2] (Clause 4.2.4) for natural persons and [ETSI EN 319 412-3] (Clause 4.2.1) for legal persons, as specified by the corresponding certificate profile. |
Section 4.1.2.6 |
|
REQUIRED. The referenced algorithm MUST be among those defined in Cryptographic Algorithms. |
Section 4.1.2.7 |
|
OPTIONAL. It SHOULD NOT be present. |
Section 4.1.2.8 |
|
OPTIONAL. It SHOULD NOT be present. |
Section 4.1.2.8 |
|
REQUIRED. It MUST conform to the structure defined in RFC 5280#section-4.2. The applicable extensions and their profile-specific constraints are defined below and in the corresponding certificate profile. |
Section 4.1.2.9 |
The following table specifies the X.509 certificate extensions supported by this specification, including their Object Identifiers (OIDs), type, criticality, description, and normative references. Individual certificate profiles MUST define the presence requirement for each extension. The presence value REQUIRED applies when the extension is mandatory. The presence value OPTIONAL applies when the extension may be omitted. Prohibited applies when the extension is forbidden. Individual certificate profiles MAY further constrain the syntax and contents of each extension.
The criticality values used in this specification have the following meaning:
C: the extension MUST be marked critical.
NC: the extension MUST be marked non-critical.
Extension |
OID |
Criticality |
Reference |
|---|---|---|---|
|
|
NC |
RFC 5280#section-4.2.1.1, Clause 4.3.1 of [ETSI EN 319 412-2] |
|
|
NC |
|
|
|
C |
RFC 5280#section-4.2.1.3, Clause 4.3.2 of [ETSI EN 319 412-2], Clause 4.3.1 of [ETSI EN 319 412-3] |
|
|
NC |
RFC 5280#section-4.2.1.4, Clause 4.3.3 of [ETSI EN 319 412-2] |
|
|
NC |
RFC 5280#section-4.2.1.6, Clause 4.3.5 of [ETSI EN 319 412-2], Clause 6.6.1, GEN-6.6.1-07 of [ETSI TS 119 411-8] |
|
|
NC |
|
|
|
C |
|
|
|
NC |
RFC 5280#section-4.2.1.13, Clause 4.3.11 of [ETSI EN 319 412-2] |
|
|
NC |
RFC 5280#section-4.2.2.1, Clause 4.4.1 of [ETSI EN 319 412-2] |
|
|
NC |
Clause 5.2.2 of [ETSI EN 319 412-1] |
|
|
NC |
|
|
|
NC |
RFC 3739#section-3.2.6, Clause 4.2 of [ETSI EN 319 412-5] |
Warning
Preventing Circular Dependencies in URIs
To prevent circular validation dependencies during TLS handshakes, URIs defined in the cRLDistributionPoints and authorityInfoAccess extensions MUST use the http:// scheme instead of https:// as suggested by RFC 5280#section-8.
5.4. Common Trust Artifacts¶
This section details the common artifacts involved in both the EUDIW and National Trust Frameworks, including:
5.4.1. Entity Sign/Seal Certificate Profile¶
This section extends the general X.509 Certificate Profile and specifies a Certificate Profile for Entity Sign/Seal Certificates, which are used for signing and sealing various Attestations. This profile is originally defined in ETSI TS 119 412-6.
Warning
The Entity Sign/Seal Certificate Profiles defined in this specification assume that Entity Sign/Seal Certificates are issued by a CA and are not self-signed. A self-signed certificate intended to act as a Trust Anchor MAY be used in interoperability. National Sign/Seal Certificates MUST comply with the requirements defined in Trust Anchor Certificate Profile and Certification Hierarchies, which require National Trust Anchors to be bound to a common root.
5.4.1.1. PID Provider Sign/Seal Certificate¶
The specific requirements for PID Provider Sign/Seal Certificates are specified in Clause 4 of [ETSI TS 119 412-6].
The following table defines the complete set of extensions applicable to the certificate profile. Extensions not listed in the table MUST NOT be present.
Extension |
Description |
|---|---|
|
REQUIRED. The value of the |
|
REQUIRED. Its value SHOULD be derived from the subject public key using the methods defined in RFC 5280#section-4.2.1.2. |
|
REQUIRED. It MUST contain one (and only one) of the key-usage settings Type A, Type B, Type C or Type F. For additional details, see Clause 4.4.1 [ETSI TS 119 412-6], Clause 4.3.2 [ETSI EN 319 412-2] and Clause 4.3.1 [ETSI EN 319 412-3]. |
|
REQUIRED. It MUST include a |
|
REQUIRED. |
|
REQUIRED 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. If present, it MUST contain at least one reference to a publicly available CRL. |
|
REQUIRED. It MUST include an If OCSP is supported by the issuing CA, the extension MUST include an |
|
REQUIRED. It MUST contain a It MAY contain additional |
The following is a non-normative example of a PID Provider Sign/Seal 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: "IT",
organizationName: "Example Trust Services CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-123456789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("270127000000Z")
},
subject: DistinguishedName { // Subject attributes for legal person
countryName: "IT",
organizationName: "Example of PID Provider",
commonName: "PID Provider Example",
organizationIdentifier: "LEIXG-5493021KJTIIGC8Y1R12"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
params: NULL
},
subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
},
extensions: [
Extension {
oid: "2.5.29.35", // authorityKeyIdentifier
critical: false,
value: AuthorityKeyIdentifier {
keyIdentifier: "SHA-1(ISSUER_PUBLIC_KEY_VALUE)"
}
},
Extension {
oid: "2.5.29.14", // subjectKeyIdentifier
critical: false,
value: SubjectKeyIdentifier("SHA-1(SUBJECT_PUBLIC_KEY_VALUE)")
},
Extension {
oid: "2.5.29.15", // keyUsage
critical: true,
value: KeyUsage {
nonRepudiation: true // Type A
// All other bits set to false
}
},
Extension {
oid: "2.5.29.32", // certificatePolicies
critical: false,
value: CertificatePolicies [
PolicyInformation {
policyIdentifier: "0.4.0.2042.1.2", // ncpplus
policyQualifiers: [
CPSuri("https://rpca.example.test/cps")
]
}
]
},
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(
type-id: "2.5.4.20", // id-at-telephoneNumber
value: "+420111222333"
)
]
},
Extension {
oid: "2.5.29.31", // cRLDistributionPoints
critical: false,
value: CRLDistributionPoints [
DistributionPoint {
distributionPoint: DistributionPointName.fullName([
GeneralName.uniformResourceIdentifier("http://crl.example.test/issuing-ca.crl")
])
}
]
},
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: GeneralName.uniformResourceIdentifier("http://ca.example.test/caIssuers/issuing-ca.cer")
},
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.1", // id-ad-ocsp
accessLocation: GeneralName.uniformResourceIdentifier("http://ocsp.example.test")
}
]
},
Extension {
oid: "1.3.6.1.5.5.7.1.3", // qcStatements
critical: false,
value: QCStatements [
QCStatement {
statementId: "0.4.0.1862.1.6", // id-etsi-qcs-QcType
statementInfo: QcType [
"0.4.0.194126.1.1" // id-etsi-qct-pid
]
}
]
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // MUST match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.4.1.2. Wallet Provider Sign/Seal Certificate¶
The specific requirements for Wallet Provider Sign/Seal Certificates are specified in Clause 5 of [ETSI TS 119 412-6].
The following table defines the complete set of extensions applicable to the certificate profile. Extensions not listed in the table MUST NOT be present.
Extension |
Description |
|---|---|
|
REQUIRED. The value of the |
|
REQUIRED. Its value SHOULD be derived from the subject public key using the methods defined in RFC 5280#section-4.2.1.2. |
|
REQUIRED. It MUST contain one (and only one) of the key-usage settings Type A, Type B, Type C or Type F. For additional details, see Clause 4.4.1 [ETSI TS 119 412-6], Clause 4.3.2 [ETSI EN 319 412-2] and Clause 4.3.1 [ETSI EN 319 412-3]. |
|
REQUIRED. It MUST include a
|
|
REQUIRED. |
|
REQUIRED 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. If present, it MUST contain at least one reference to a publicly available CRL. |
|
REQUIRED. It MUST include an If OCSP is supported by the issuing CA, the extension MUST include an |
|
REQUIRED. It MUST contain a It MAY contain additional |
The following is a non-normative example of a Wallet Provider Sign/Seal Certificate for legal persons.
AccessCertificate cert = {
tbsCertificate: {
version: 2, // Integer value 2 for v3
serialNumber: "0x8D73F82C13...",
signature: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // sha256WithRSAEncryption
params: NULL
},
issuer: DistinguishedName {
countryName: "CZ",
organizationName: "Example Trust Services CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-123456789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("270127000000Z")
},
subject: DistinguishedName { // Subject attributes for legal person
countryName: "IT",
organizationName: "Example of Wallet Provider",
commonName: "Wallet Provider Example",
organizationIdentifier: "LEIXG-5823001KJTIIGC8Y1R12"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
params: NULL
},
subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
},
extensions: [
Extension {
oid: "2.5.29.35", // authorityKeyIdentifier
critical: false,
value: AuthorityKeyIdentifier {
keyIdentifier: "SHA-1(ISSUER_PUBLIC_KEY_VALUE)"
}
},
Extension {
oid: "2.5.29.14", // subjectKeyIdentifier
critical: false,
value: SubjectKeyIdentifier("SHA-1(SUBJECT_PUBLIC_KEY_VALUE)")
},
Extension {
oid: "2.5.29.15", // keyUsage
critical: true,
value: KeyUsage {
nonRepudiation: true // Type A
// All other bits set to false
}
},
Extension {
oid: "2.5.29.32", // certificatePolicies
critical: false,
value: CertificatePolicies [
PolicyInformation {
policyIdentifier: "0.4.0.2042.1.2", // ncpplus
policyQualifiers: [
CPSuri("https://rpca.example.test/cps")
]
}
]
},
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(
type-id: "2.5.4.20", // id-at-telephoneNumber
value: "+420111222444"
)
]
},
Extension {
oid: "2.5.29.31", // cRLDistributionPoints
critical: false,
value: CRLDistributionPoints [
DistributionPoint {
distributionPoint: DistributionPointName.fullName([
GeneralName.uniformResourceIdentifier("http://crl.example.test/issuing-ca.crl")
])
}
]
},
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: GeneralName.uniformResourceIdentifier("http://ca.example.test/caIssuers/issuing-ca.cer")
},
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.1", // id-ad-ocsp
accessLocation: GeneralName.uniformResourceIdentifier("http://ocsp.example.test")
}
]
},
Extension {
oid: "1.3.6.1.5.5.7.1.3", // qcStatements
critical: false,
value: QCStatements [
QCStatement {
statementId: "0.4.0.1862.1.6", // id-etsi-qcs-QcType
statementInfo: QcType [
"0.4.0.194126.1.2" // id-etsi-qct-wal
]
}
]
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // MUST match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.4.1.3. (Q)EAA Provider Sign/Seal Certificate¶
The specific requirements for EAA Provider and QEAA Provider Sign/Seal Certificates are specified in Clauses 6 and 7 of [ETSI TS 119 412-6], respectively.
The following table defines the complete set of extensions applicable to the certificate profile. Extensions not listed in the table MUST NOT be present.
Extension |
Description |
|---|---|
|
REQUIRED. The value of the |
|
OPTIONAL. If present, its value SHOULD be derived from the subject public key using the methods defined in RFC 5280#section-4.2.1.2. |
|
REQUIRED. It MUST contain one (and only one) of the key-usage settings Type A, Type B, Type C, or Type F. For additional details, see Clause 4.3.2 [ETSI EN 319 412-2] and Clause 4.3.1 [ETSI EN 319 412-3]. |
|
REQUIRED (only for QEAA). As described in Clause 6.6.1 of [ETSI EN 319 411-2]. |
|
REQUIRED. |
|
REQUIRED 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. If present, it MUST contain at least one reference to a publicly available CRL. |
|
REQUIRED (only for QEAA). It MUST include an If OCSP is supported by the issuing CA, the extension MUST include an |
|
REQUIRED (QEAA), OPTIONAL (EAA). For QEAA: It MUST contain a For both:
|
For both QEAA and EAA Providers, if they manage the lifecycle of the Digital Credentials they issue and they use signed revocation lists such as Token Status List, they MUST use the same Sign/Seal Certificate to sign/seal the revocation list.
The following is a non-normative example of a QEAA Provider Sign/Seal Certificate for legal persons.
AccessCertificate cert = {
tbsCertificate: {
version: 2, // Integer value 2 for v3
serialNumber: "0x7364DE67A6...",
signature: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // sha256WithRSAEncryption
params: NULL
},
issuer: DistinguishedName { // Issuer attributes for legal person
countryName: "IT",
organizationName: "Example Trust Services CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-123456789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("270127000000Z")
},
subject: DistinguishedName { // Subject attributes for legal person
countryName: "IT",
organizationName: "Example of QEAA Provider",
commonName: "QEAA Provider Example",
organizationIdentifier: "LEIXG-5494001KJTIIGC8Y1R56"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
params: NULL
},
subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
},
extensions: [
Extension {
oid: "2.5.29.35", // authorityKeyIdentifier
critical: false,
value: AuthorityKeyIdentifier {
keyIdentifier: "SHA-1(ISSUER_PUBLIC_KEY_VALUE)"
}
},
Extension {
oid: "2.5.29.15", // keyUsage
critical: true,
value: KeyUsage {
nonRepudiation: true // Type A
// All other bits set to false
}
},
Extension {
oid: "2.5.29.32", // certificatePolicies
critical: false,
value: CertificatePolicies [
PolicyInformation {
policyIdentifier: "0.4.0.194112.1.3", // qcp-legal-qscd
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(
type-id: "2.5.4.20", // id-at-telephoneNumber
value: "+420111222555"
)
]
},
Extension {
oid: "2.5.29.31", // cRLDistributionPoints
critical: false,
value: CRLDistributionPoints [
DistributionPoint {
distributionPoint: DistributionPointName.fullName([
GeneralName.uniformResourceIdentifier("http://crl.example.test/issuing-ca.crl")
])
}
]
},
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: GeneralName.uniformResourceIdentifier("http://ca.example.test/caIssuers/issuing-ca.cer")
},
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.1", // id-ad-ocsp
accessLocation: GeneralName.uniformResourceIdentifier("http://ocsp.example.test")
}
]
},
Extension {
oid: "1.3.6.1.5.5.7.1.3", // qcStatements
critical: false,
value: QCStatements [
QCStatement { // esi4-qcStatement-1
statementId: "0.4.0.1862.1.1", // id-etsi-qcs-QcCompliance
},
QCStatement { // esi4-qcStatement-4
statementId: "0.4.0.1862.1.4", // id-etsi-qcs-QcSSCD
},
QCStatement {
statementId: "0.4.0.1862.1.6", // id-etsi-qcs-QcType
statementInfo: QcType [
"0.4.0.1862.1.6.1" // id-etsi-qct-esign
]
}
]
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // MUST match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.4.1.4. PuB-EAA Provider Sign/Seal Certificate¶
Warning
While the specific requirements for PuB-EAA Provider Sign/Seal Certificates that are specified in Clause 8 of [ETSI TS 119 412-6] do not require this profile to be qualified, Art. 45f(1)(b) of [EU_2024_1183] requires PuB-EAA type Attestations to be signed with a qualified certificate. To satisfy both requirements, although not stated either the [EIDAS-ARF] or [ETSI TS 119 412-6], this profile merges the QEAA and PuB-EAA Provider Sign/Seal Certificate profiles specified in Clauses 7 and 8 of [ETSI TS 119 412-6].
The following table defines the complete set of extensions applicable to the certificate profile. Extensions not listed in the table MUST NOT be present.
Extension |
Description |
|---|---|
|
REQUIRED. The value of the |
|
OPTIONAL. If present, its value SHOULD be derived from the subject public key using the methods defined in RFC 5280#section-4.2.1.2. |
|
REQUIRED. |
|
REQUIRED. As described in Clause 6.6.1 of [ETSI EN 319 411-2]. |
|
REQUIRED. |
|
REQUIRED 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. If present, it MUST contain at least one reference to a publicly available CRL. |
|
REQUIRED. It MUST include an If OCSP is supported by the issuing CA, the extension MUST include an |
|
REQUIRED. It MUST contain:
It MAY contain additional |
Warning
Annex A of [ETSI TS 119 412-6] does not define the specific OID of the id-etsi-qcs-QcPSB statement identifier.
The following is a non-normative example of a PuB-EAA Provider Sign/Seal Certificate for legal persons.
AccessCertificate cert = {
tbsCertificate: {
version: 2, // Integer value 2 for v3
serialNumber: "0x6354A56B5D...",
signature: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // sha256WithRSAEncryption
params: NULL
},
issuer: DistinguishedName { // Issuer attributes for legal person
countryName: "IT",
organizationName: "Example Trust Services CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-123456789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("270127000000Z")
},
subject: DistinguishedName { // Subject attributes for legal person
countryName: "IT",
organizationName: "Example of PuB-EAA Provider",
commonName: "PuB-EAA Provider Example",
organizationIdentifier: "LEIXG-5494201KJTIIGC8Y1R12"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
params: NULL
},
subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
},
extensions: [
Extension {
oid: "2.5.29.35", // authorityKeyIdentifier
critical: false,
value: AuthorityKeyIdentifier {
keyIdentifier: "SHA-1(ISSUER_PUBLIC_KEY_VALUE)"
}
},
Extension {
oid: "2.5.29.14", // subjectKeyIdentifier
critical: false,
value: SubjectKeyIdentifier("SHA-1(SUBJECT_PUBLIC_KEY_VALUE)")
},
Extension {
oid: "2.5.29.15", // keyUsage
critical: true,
value: KeyUsage {
nonRepudiation: true // Type A
// All other bits set to false
}
},
Extension {
oid: "2.5.29.32", // certificatePolicies
critical: false,
value: CertificatePolicies [
PolicyInformation {
policyIdentifier: "0.4.0.194112.1.3", // qcp-legal-qscd
policyQualifiers: [
CPSuri("https://rpca.example.test/cps")
]
}
]
},
Extension {
oid: "2.5.29.17", // subjectAltName
critical: false,
value: SubjectAltName [
GeneralName.uniformResourceIdentifier("https://pub-eaa.example.test/support"),
GeneralName.rfc822Name("support@pub-eaa.example.test"),
GeneralName.otherName(
type-id: "2.5.4.20", // id-at-telephoneNumber
value: "+420111222777"
)
]
},
Extension {
oid: "2.5.29.31", // cRLDistributionPoints
critical: false,
value: CRLDistributionPoints [
DistributionPoint {
distributionPoint: DistributionPointName.fullName([
GeneralName.uniformResourceIdentifier("http://crl.example.test/issuing-ca.crl")
])
}
]
},
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: GeneralName.uniformResourceIdentifier("http://ca.example.test/caIssuers/issuing-ca.cer")
},
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.1", // id-ad-ocsp
accessLocation: GeneralName.uniformResourceIdentifier("http://ocsp.example.test")
}
]
},
Extension {
oid: "1.3.6.1.5.5.7.1.3", // qcStatements
critical: false,
value: QCStatements [
QCStatement { // esi4-qcStatement-1
statementId: "0.4.0.1862.1.1", // id-etsi-qcs-QcCompliance
},
QCStatement { // esi4-qcStatement-4
statementId: "0.4.0.1862.1.4", // id-etsi-qcs-QcSSCD
},
QCStatement {
statementId: "TBD", // id-etsi-qcs-QcPSB (OID not yet defined)
statementInfo: QcPSB {
countryOfLegislation: "IT",
authSourceIdentification: "https://www.anpr.interno.it",
legislationIdentification: "https://www.normattiva.it/eli/id/2005/05/16/005G0106/sg"
}
}
]
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // MUST match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.4.2. Trust Anchor Certificate Profile¶
This section extends the general X.509 Certificate Profile and specifies a Certificate Profile for Trust Anchors. A Trust Anchor is a trusted public key (and associated data) used as an input to the X509 Certificate Chain Validation Algorithm. In this profile, the Trust Anchor MUST be represented and distributed as an X.509 certificate. That certificate MAY be self-signed.
Relying Parties, Credential Issuers and Wallet Units validate a presented Access, Registration or Sign/Seal Certificate by building a certificate chain. The certificate chain MUST start with the presented end-entity certificate. The certificate chain MUST end with a certificate signed by the subject of a Trust Anchor certificate.
The Trust Anchor certificate is used as the trust termination point for the path validation process (i.e., it is the value of the trust_anchor variable in X509 Certificate Chain Validation Algorithm).
Implementations MUST support validating both self-signed and non-self-signed Trust Anchor certificates.
Note
Trust Anchor Location
The location of the Trust Anchor Certificate is determined by the specific Trust Framework selected (see EUDIW Trust Anchor Validation and Federation Trust Anchor Validation).
The following table defines the profile-specific requirements for the certificate fields. Fields not listed in the table remain subject to the requirements defined in the common X.509 Certificate Profile.
Field |
Additional Requirements |
|---|---|
|
If the certificate is self-signed, the issuer's distinguished name MUST be identical to the subject's distinguished name. Otherwise, the issuer's distinguished name MUST identify the entity that signed and issued the certificate and MAY differ from the subject's distinguished name. |
|
The distinguished name MUST contain an |
Extension |
Description |
|---|---|
|
REQUIRED IF: the certificate is not self-signed.
For self-signed certificates, it is RECOMMENDED.
If the extension is present, the value of the |
|
REQUIRED. Provides a key identifier for the Trust Anchor public key. Its value SHOULD be derived from the subject public key using the methods defined in RFC 5280#section-4.2.1.2. This extension SHOULD support reliable certificate chain construction and certificate matching in LoTE- or TL-based deployments. |
|
REQUIRED. It MUST assert the |
|
OPTIONAL. It MAY include a |
|
REQUIRED. The |
|
OPTIONAL. It MAY include CRL distribution point URIs, when CRL-based revocation is used. |
|
REQUIRED. It MUST include an It MAY also include an |
|
OPTIONAL. It MAY contain In any case, it MUST NOT contain a |
Note
Trust Anchor Signature
A Trust Anchor certificate MAY be self-signed (representing a root CA) or non-self-signed (representing an intermediate CA designated as a Trust Anchor by policy). Relying Parties MUST NOT require an additional issuer above a Trust Anchor retrieved as specified by the applicable Trust Framework, even if it is not self-signed, because the Trust Anchor is an authoritative input to the path validation algorithm designated by policy.
Note
As described in Section 4.3.1 of [EUDI-TS 12], the Trust Anchor of an EAA Sign/Seal Certificate is referenced in the trustedAuthority attribute of the machine-readable Attestation Rulebook for the specific EAA.
The following is a non-normative example of a Trust Anchor Certificate.
AccessCertificate cert = {
tbsCertificate: {
version: 2, // Integer value 2 for v3
serialNumber: "0x9D846F726A8..",
signature: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // sha256WithRSAEncryption
params: NULL
},
issuer: DistinguishedName { // Issuer attributes
countryName: "IT",
organizationName: "Example Root CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-127263789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("460127000000Z")
},
subject: DistinguishedName { // Subject attributes
countryName: "IT",
organizationName: "Example Root CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-127263789"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
params: NULL
},
subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
},
extensions: [
Extension {
oid: "2.5.29.35", // authorityKeyIdentifier
critical: false,
value: AuthorityKeyIdentifier {
keyIdentifier: "SHA-1(ISSUER_PUBLIC_KEY_VALUE)"
}
},
Extension {
oid: "2.5.29.14", // subjectKeyIdentifier
critical: false,
value: SubjectKeyIdentifier("SHA-1(SUBJECT_PUBLIC_KEY_VALUE)")
},
Extension {
oid: "2.5.29.15", // keyUsage
critical: true,
value: KeyUsage {
keyCertSign: true,
cRLSign: true
// All other bits set to false
}
},
Extension {
oid: "2.5.29.19", // basicConstraints
critical: true,
value: BasicConstraints {
cA: true,
pathLenConstraint: 0
}
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // MUST match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.5. EUDIW Trust Artifacts¶
This section defines the required trust artifacts and their conceptual roles in the EUDIW ecosystem as per EIDAS-ARF, including:
Wallet-Relying Party Registration Certificate (WRPRC) Profile.
Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities.
The data model of these Trust Artifacts profiles the following external specifications.
ETSI TS 119 602, which defines the data model of the Lists of Trusted Entities and the profiles of the EUDIW lists.
ETSI TS 119 411-8, which defines the Wallet-Relying Party Access Certificate.
ETSI TS 119 475, which defines the Wallet-Relying Party Registration Certificate together with its entitlements.
ETSI EN 319 412-1, which defines the subject attributes of the certificates.
ETSI TS 119 182-1, which defines the JAdES format of the signature of a List of Trusted Entities.
ETSI EN 319 132-1, which defines the XAdES format of the signature of Trusted List and List of Trusted List.
5.5.1. Register of WRPs¶
The national Register of WRPs is the publicly accessible system (dataset + API) that provides signed/sealed registration statements about WRPs, their Services, and their authorisations/declared usage.
The Register dataset and read API are EUDI-TS 5, objects WalletRelyingParty and WalletRelyingPartyService, and satisfy Annex II of CIR2025/848 as amended by [CIR2026/1730].
Note
Profile deviation. The Relying Party Service identifier, and the issuance of more than one Wallet-Relying Party Access Certificate or Wallet-Relying Party Registration Certificate per Wallet-Relying Party ([EIDAS-ARF] Reg_10a, Reg_10d, Reg_33, Reg_34a and RPRC_07a), are not requirements of this specification until ETSI and the ARF Technical Specifications define the implementation.
EUDI-TS 5 marks serviceIdentifier as [0..1].
ETSI TS 119 411-8 does not yet define an attribute for that identifier, and ETSI TS 119 475 does not yet define srv_id.
Until then, this specification does not require serviceIdentifier, an entity obtains one WRPAC, and the Provider of WRPRC issues one WRPRC for that entity.
5.5.1.1. Register Dataset¶
The data format for the information available through the open API provided by the national Register of WRPs MUST comply with the data schemas described in Tables 1-11 of Annex VI of [CIR2025/848] as amended by [CIR2026/1730], encoded as the WalletRelyingParty JSON Schema of EUDI-TS 5.
Below some non-normative examples of WalletRelyingParty objects stored in the Register.
A bank registered as a Relying Party requesting PID for know-your-customer procedures, with one Relying Party Service.
{
"legalPerson": {
"legalName": ["ExampleBank S.p.A."]
},
"identifier": [
{
"type": "http://data.europa.eu/eudi/id/EUID",
"identifier": "IT-EUID-123456789"
},
{
"type": "http://data.europa.eu/eudi/id/VATIN",
"identifier": "IT98765432101"
}
],
"postalAddress": [
"Via dei Mille, Roma, IT"
],
"country": "IT",
"email": [
"wallet-rp-registration@examplebank.eu"
],
"phone": [
"+39100000000"
],
"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",
"isPSB": false,
"supervisoryAuthority": {
"name": "Garante per la protezione dei dati personali",
"country": "IT",
"email": ["contact@supervisor.example.it"],
"formURI": ["https://supervisor.example.it"]
},
"registryURI": "https://registry.example.it/api",
"services": [
{
"serviceTradeName": "ExampleBank Mobile",
"supportURI": "https://examplebank.eu/support",
"email": "wallet-rp-registration@examplebank.eu",
"phone": "+39100000000",
"srvDescription": [
[
{
"lang": "en",
"content": "Retail banking services for individuals."
},
{
"lang": "it",
"content": "Servizi bancari per privati."
}
]
],
"entitlements": [
"https://uri.etsi.org/19475/Entitlement/Service_Provider"
],
"isIntermediary": false,
"intendedUses": [
{
"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"
}
],
"credentials": [
{
"format": "dc+sd-jwt",
"meta": {
"vct_values": ["https://example.eu/schema/pid"]
},
"claims": [
{ "path": ["family_name"] },
{ "path": ["given_name"] },
{ "path": ["birth_date"] }
]
}
],
"createdAt": "2026-01-01"
}
]
}
]
}
A bank registered as both a Relying Party requesting PID and a QEAA Provider (issuing bank account attestations to Wallet).
It registers two Services: one Service with intendedUses and one Service with providesAttestations.
{
"legalPerson": {
"legalName": ["ExampleBank S.p.A."]
},
"identifier": [
{
"type": "http://data.europa.eu/eudi/id/EUID",
"identifier": "IT-EUID-123456789"
},
{
"type": "http://data.europa.eu/eudi/id/VATIN",
"identifier": "IT98765432101"
}
],
"postalAddress": [
"Via dei Mille, Roma, IT"
],
"country": "IT",
"email": [
"wallet-rp-registration@examplebank.eu"
],
"phone": [
"+39100000000"
],
"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",
"isPSB": false,
"supervisoryAuthority": {
"name": "Garante per la protezione dei dati personali",
"country": "IT",
"email": ["contact@supervisor.example.it"],
"formURI": ["https://supervisor.example.it"]
},
"registryURI": "https://registry.example.it/api",
"services": [
{
"serviceTradeName": "ExampleBank Mobile",
"supportURI": "https://examplebank.eu/support",
"srvDescription": [
[
{
"lang": "en",
"content": "Retail banking services for individuals."
},
{
"lang": "it",
"content": "Servizi bancari per privati."
}
]
],
"entitlements": [
"https://uri.etsi.org/19475/Entitlement/Service_Provider"
],
"isIntermediary": false,
"intendedUses": [
{
"intendedUseIdentifier": "iu-account-opening",
"purpose": [
{
"lang": "en",
"content": "Open a bank account remotely."
},
{
"lang": "it",
"content": "Aprire un conto corrente da remoto."
}
],
"privacyPolicy": [
{
"type": "http://data.europa.eu/eudi/policy/privacy-statement",
"policyURI": "https://examplebank.eu/privacy/wallet/account-opening"
}
],
"credentials": [
{
"format": "dc+sd-jwt",
"meta": { "vct_values": ["https://example.eu/schema/pid"] },
"claims": [
{ "path": ["family_name"] },
{ "path": ["given_name"] },
{ "path": ["birth_date"] },
{ "path": ["nationalities"] }
]
}
],
"createdAt": "2026-01-01"
}
]
},
{
"serviceTradeName": "ExampleBank Account Attestations",
"supportURI": "https://examplebank.eu/support",
"srvDescription": [
[
{
"lang": "en",
"content": "Issuance of qualified bank account attestations."
},
{
"lang": "it",
"content": "Rilascio di attestati qualificati relativi a conti bancari."
}
]
],
"entitlements": [
"https://uri.etsi.org/19475/Entitlement/QEAA_Provider"
],
"isIntermediary": false,
"providesAttestations": [
{
"format": "dc+sd-jwt",
"type": "https://examplebank.eu/schema/bank-account"
}
],
"intendedUses": [
{
"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"
}
],
"credentials": [
{
"format": "dc+sd-jwt",
"meta": { "vct_values": ["https://example.eu/schema/pid"] },
"claims": [
{ "path": ["family_name"] },
{ "path": ["given_name"] },
{ "path": ["birth_date"] }
]
}
],
"createdAt": "2026-01-01"
}
]
}
]
}
An entity registered as a designated Intermediary that acts on behalf of WRPs during Wallet interactions.
Each of its services[] elements has isIntermediary: true, does not declare intendedUses or entitlements, and lists the served Services in servedWRPServices.
{
"legalPerson": {
"legalName": ["TrustBridge Services B.V."]
},
"identifier": [
{
"type": "http://data.europa.eu/eudi/id/EUID",
"identifier": "IT-EUID-112233445"
},
{
"type": "http://data.europa.eu/eudi/id/VATIN",
"identifier": "IT112233445B01"
}
],
"postalAddress": [
"Corso Venezia, Milano, IT"
],
"country": "IT",
"email": ["wallet-intermediary@trustbridge.example"],
"phone": ["+39200000000"],
"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",
"isPSB": false,
"supervisoryAuthority": {
"name": "Garante per la protezione dei dati personali",
"country": "IT",
"email": ["contact@supervisor.example.it"],
"formURI": ["https://supervisor.example.it"]
},
"registryURI": "https://registry.example.it/api",
"services": [
{
"serviceTradeName": "TrustBridge Wallet Intermediation",
"supportURI": "https://trustbridge.example/support",
"email": "wallet-intermediary@trustbridge.example",
"phone": "+39200000000",
"srvDescription": [
[
{
"lang": "en",
"content": "Intermediary for wallet-relying parties operating in Italy."
},
{
"lang": "it",
"content": "Intermediario per WRP che operano in Italia."
}
]
],
"isIntermediary": true,
"servedWRPServices": []
}
]
}
5.5.1.2. Register Open APIs¶
The read methods are described in Section 3 of EUDI-TS 5.
Methods, filter parameters, response codes and the slicing of services when serviceidentifier is used are defined there.
Note
The published API view excludes only postalAddress ([CIR2025/848] as amended by [CIR2026/1730], Annex I, point 4).
All other fields, including intended-use Credential claims, are published as registered.
The Register Open APIs remain for publication and transparency ([EIDAS-ARF] Reg_03, Reg_06).
The Wallet Unit MUST NOT use them as a substitute for a missing or invalid Wallet-Relying Party Registration Certificate during Credential Presentation or Credential Issuance, as specified in EUDIW Authorization.
The YAML file of the OpenAPI specification described in Section 3 of EUDI-TS 5 is available as EUDI-TS 5 OpenAPI.
The JSON Schema of the WalletRelyingParty object, including the services array of WalletRelyingPartyService, is available as EUDI-TS 5 JSON Schema.
The national Register API provides only the read methods of EUDI-TS 5 OpenAPI.
5.5.2. Wallet-Relying Party Access Certificate (WRPAC) Profile¶
This section extends the general X.509 Certificate Profile and specifies a Certificate Profile for Wallet-Relying Party Access Certificates (WRPACs).
The WRPAC is the certificate defined in Article 2 and Annex IV of [CIR2025/848]. Its profile is ETSI TS 119 411-8. Extensions not specified by that document MUST NOT be present. Subject attributes are [EIDAS-ARF] Reg_31, Reg_32 and Reg_34, and ETSI TS 119 411-8. Authentication is specified in EUDIW Authentication. Revocation on suspension or cancellation of the WRP services is specified in Trust Management and Lifecycle.
Note
The WRPAC attributes MUST be derived from the Register as specified in clause 5.1.2 of ETSI TS 119 475.
Profile deviation. Certificate Transparency ([EIDAS-ARF] CT_01 to CT_06) is not a requirement of this specification until the ARF Technical Specifications make it fully available and clear for implementations. The WRPAC profile does not include a Signed Certificate Timestamp, the Provider of WRPAC is not required to log issued WRPACs, and the Wallet Unit is not required to verify Certificate Transparency during Authentication.
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: "IT",
organizationName: "Example Trust Services CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-123456789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("270127000000Z")
},
subject: DistinguishedName { // Subject attributes for legal person
countryName: "IT",
organizationName: "Example of Relying Party",
commonName: "ExampleBank Mobile", // serviceTradeName (Reg_34)
organizationIdentifier: "LEIXG-5493001KJTIIGC8Y1R12"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
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 other bits set to false
}
},
Extension {
oid: "2.5.29.32", // certificatePolicies
critical: false,
value: CertificatePolicies [
PolicyInformation {
policyIdentifier: "0.4.0.194118.1.2", // NCP-l-eudiwrp
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("support@rp.example.test"),
GeneralName.otherName(
type-id: "2.5.4.20", // id-at-telephoneNumber
value: "+420111222333"
)
]
},
Extension {
oid: "2.5.29.31", // cRLDistributionPoints
critical: false,
value: CRLDistributionPoints [
DistributionPoint {
distributionPoint: DistributionPointName.fullName([
GeneralName.uniformResourceIdentifier("http://crl.example.test/issuing-ca.crl")
])
}
]
},
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: GeneralName.uniformResourceIdentifier("http://ca.example.test/caIssuers/issuing-ca.cer")
},
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.1", // id-ad-ocsp
accessLocation: GeneralName.uniformResourceIdentifier("http://ocsp.example.test")
}
]
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // MUST match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.5.3. Registrar Sign/Seal Certificate Profile¶
This section extends the general X.509 Certificate Profile and specifies a Certificate Profile for Registrar Sign/Seal Certificates.
The following table defines the complete set of extensions applicable to the certificate profile. Extensions not listed in the table MUST NOT be present.
Extension |
Description |
|---|---|
|
REQUIRED. The value SHOULD be derived from the public key using the methods defined in RFC 5280#section-4.2.1.1. |
|
OPTIONAL. If present, the |
|
REQUIRED. It MUST contain one (and only one) of the key-usage settings Type A, Type B, or Type F. Type A SHOULD be used as per LEG-4.3.1-4 in Clause 4.3.1 [ETSI EN 319 412-3]. For additional details, see Clause 4.3.2 [ETSI EN 319 412-2] and Clause 4.3.1 [ETSI EN 319 412-3]. |
|
REQUIRED. It MUST include a |
|
REQUIRED. |
|
REQUIRED 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. |
|
REQUIRED. It MUST include an If OCSP is supported by the issuing CA, the extension MUST include an |
The following is a non-normative example of a Registrar Sign/Seal Certificate for legal persons (non-self-signed).
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: "IT",
organizationName: "Example Trust Services CA",
commonName: "Example CA",
organizationIdentifier: "VATIT-123456789"
},
validity: {
notBefore: Time.utcTime("260127000000Z"),
notAfter: Time.utcTime("270127000000Z")
},
subject: DistinguishedName { // Subject attributes for legal person
countryName: "IT",
organizationName: "Example of PID Provider",
commonName: "PID Provider Example",
organizationIdentifier: "LEIXG-5493001KJAWIGC8Y1R12"
},
subjectPublicKeyInfo: {
algorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.1", // rsaEncryption
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.14", // subjectKeyIdentifier
critical: false,
value: SubjectKeyIdentifier("SHA-1(SUBJECT_PUBLIC_KEY_VALUE)")
},
Extension {
oid: "2.5.29.15", // keyUsage
critical: true,
value: KeyUsage {
nonRepudiation: true // Type A
// All other bits set to false
}
},
Extension {
oid: "2.5.29.32", // certificatePolicies
critical: false,
value: CertificatePolicies [
PolicyInformation {
policyIdentifier: "0.4.0.194112.1.3", // qcp-legal-qscd
policyQualifiers: [
CPSuri("https://rpca.example.test/cps")
]
}
]
},
Extension {
oid: "2.5.29.17", // subjectAltName
critical: false,
value: SubjectAltName [
GeneralName.uniformResourceIdentifier("https://registrar.example.test/support"),
GeneralName.rfc822Name("support@registrar.example.test"),
GeneralName.otherName(
typeId: "2.5.4.20", // id-at-telephoneNumber
value: "+420111222333"
)
]
},
Extension {
oid: "2.5.29.31", // cRLDistributionPoints
critical: false,
value: CRLDistributionPoints [
DistributionPoint {
distributionPoint: DistributionPointName.fullName([
GeneralName.uniformResourceIdentifier("http://crl.example.test/issuing-ca.crl")
])
}
]
}
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: GeneralName.uniformResourceIdentifier("http://ca.example.test/caIssuers/issuing-ca.cer")
},
AccessDescription {
accessMethod: "1.3.6.1.5.5.7.48.1", // id-ad-ocsp
accessLocation: GeneralName.uniformResourceIdentifier("http://ocsp.example.test")
}
]
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // Must match/align with tbsCertificate.signature
params: NULL
},
signatureValue: "BASE64(SIGN(issuerPrivateKey, DER(tbsCertificate)))"
}
5.5.4. Wallet-Relying Party Registration Certificate (WRPRC) Profile¶
This section profiles the Wallet-Relying Party Registration Certificate (WRPRC) defined in EIDAS-ARF and ETSI TS 119 475. Its contents are clause 5.1, clause 5.2.4 and Annex A.2 of ETSI TS 119 475, and Annex V paragraph 3 of [CIR2025/848]. It is a signed JWT or a CWT (RFC 8392), signed with the private key of the Provider of Wallet-Relying Party Registration Certificates. The JWT signature is a JAdES signature with the B-B profile (ETSI TS 119 182-1). The CWT signature follows RFC 9052 and RFC 9360.
The Provider of WRPRC issues one WRPRC for the entity, automatically, as defined in Wallet-Relying Party Registration Certificate Issuance. Binding that certificate to a Relying Party Service identifier, and issuing more than one WRPRC per entity, are deferred as specified in Register of WRPs.
The intermediary object is clause 5.2.4 of ETSI TS 119 475 and [EIDAS-ARF] RPRC_04.
The Wallet Unit evaluates intermediated presentation as specified in EUDIW Authorization.
Below a non-normative example of WRPRC header and payload for a Relying Party.
{
"typ": "rc-wrp+jwt",
"alg": "ES256",
"x5c": ["<base64-encoded-certificate-chain>"]
}
{
"name": "Online Shop",
"sub_ln": "Online Shop",
"sub": "LEIXG-529900T8BM49AURSDO55",
"country": "IT",
"registry_uri": "https://wrp-register.it/api/v1/relying-parties/IT-WRP-00789",
"srv_description": [
{ "lang": "it", "value": "Servizio di shopping online" },
{ "lang": "en", "value": "Online shopping platform" }
],
"entitlements": ["https://uri.etsi.org/19475/Entitlement/Service_Provider"],
"purpose": [
{ "lang": "it", "value": "Verifica dell'età per i prodotti soggetti a restrizioni di età" },
{ "lang": "en", "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.it/privacy",
"info_uri": "https://shop.example.it",
"support_uri": "https://shop.example.it/support",
"supervisory_authority": {
"uri": "https://www.dpa.example.it/report",
"email": "reports@dpa.example.it",
"phone": "+390612345678"
},
"public_body": false,
"policy_id": ["0.4.0.19475.3.1"],
"certificate_policy": "https://wrp-register.it/policies/service-provider",
"iat": 1704067200,
"exp": 1735689600,
"status": { "status_list": { "idx": 156, "uri": "https://status.wrp-register.it/statuslist/1" } }
}
Below a non-normative example of WRPRC payload for an intermediated Relying Party.
{
"name": "Small Business Verification",
"sub_ln": "Small Business S.p.A.",
"sub": "IT123456789",
"country": "IT",
"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",
"sname": "Verification Service"
}
},
"policy_id": ["0.4.0.19475.3.1"],
"iat": 1704067200,
"status": { "status_list": { "idx": 567, "uri": "https://status.wrp-register.it/statuslist/2" } }
}
Warning
ETSI TS 119 475, Table 10 defines the intermediary name subfield as sname.
The example in Annex C of the same standard uses name instead.
This specification follows the normative Table 10 and uses sname.
5.5.5. Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities¶
This section describes the format and contents of three types of Trust Artifacts: Trusted List (TL), Lists of Trusted Lists (LOTL), and Lists of Trusted Entities (LoTE), each of which conveys a list of current and historical Trust Anchors (containers of cryptographic materials and identifiers belonging to trusted Entities).
Ecosystem Entities utilize these lists to:
Validate runtime trustworthiness: Verify a Trust Anchor (see Trust Anchor Certificate Profile) to authenticate, authorize, or validate an entity or artifact during live operations.
Perform historical validation: Validate information contained within the list for historical audit purposes.
The table below maps each list to its legal basis, governing standard, format and publication.
The XML schema of Trusted Lists and of the List of Trusted Lists is published at https://forge.etsi.org/rep/esi/x19_612_trusted_lists/-/raw/v2.4.1/19612_xsd.xsd.
The machine-readable List of Trusted Lists and the National Trusted Lists are published at EUMS-LOTL.
The normative JSON and XML schemas of the Lists of Trusted Entities are published at ETSI-LOTE-SCHEMAS.
List Type |
Legal Basis |
Governing Standard & Format |
Signature Profile |
Scope & Signer |
Publication & Update Mechanism |
|---|---|---|---|---|---|
Trusted Lists (TL) |
CID2015/1505 (Annex I, Chapter II), amended by CID2025/2164. |
ETSI TS 119 612; |
XAdES digital signature, baseline B (ETSI EN 319 132-1). |
Member State scope; one list per Member State, signed by that Member State. |
Machine-readable endpoint specified within the LOTL. |
List of Trusted Lists (LOTL) |
CID2015/1505 (Annex I, Chapter II), amended by CID2025/2164. |
ETSI TS 119 612; |
XAdES digital signature, baseline B (ETSI EN 319 132-1). |
European Union scope; a single global list signed by the European Commission (EC) that anchors the National Trusted Lists. |
Machine-readable endpoint specified within the OJEU. Implements a pivoting mechanism to handle continuous updates. |
LoTE: PID Provider Lists |
Articles 4 and 5 of CIR2024/2980. |
ETSI TS 119 602 Annex D; |
AdES digital signature, baseline B (ETSI TS 119 182-1). |
European Union scope; one list per specific ecosystem entity type. |
Machine-readable endpoint specified within the OJEU. Implements a pivoting mechanism to handle continuous updates. |
LoTE: Wallet Provider (WP) Lists |
Articles 4 and 5 of CIR2024/2980. |
ETSI TS 119 602 Annex E; |
AdES digital signature, baseline B (ETSI TS 119 182-1). |
European Union scope; one list per specific ecosystem entity type. |
Machine-readable endpoint specified within the OJEU. Implements a pivoting mechanism to handle continuous updates. |
LoTE: Provider of WRPAC Lists |
Articles 4 and 5 of CIR2024/2980. |
ETSI TS 119 602 Annex F; |
AdES digital signature, baseline B (ETSI TS 119 182-1). |
European Union scope; one list per specific ecosystem entity type (Wallet Relying Party Access Certificate). |
Machine-readable endpoint specified within the OJEU. Implements a pivoting mechanism to handle continuous updates. |
LoTE: Provider of WRPRC Lists |
Articles 4 and 5 of CIR2024/2980. |
ETSI TS 119 602 Annex G; |
AdES digital signature, baseline B (ETSI TS 119 182-1). |
European Union scope; one list per specific ecosystem entity type (Wallet Relying Party Registration Certificate). |
Machine-readable endpoint specified within the OJEU. Implements a pivoting mechanism to handle continuous updates. |
LoTE: PuB-EAA Provider Lists |
Articles 4 and 5 of CIR2024/2980. |
ETSI TS 119 602 Annex H; |
AdES digital signature, baseline B (ETSI TS 119 182-1). |
European Union scope; lists notified PuB-EAA Providers and their Sign/Seal Trust Anchors. |
Machine-readable endpoint specified within the OJEU. Implements a pivoting mechanism to handle continuous updates. |
LoTE: Registrar and Register Provider Lists |
Articles 4 and 5 of CIR2024/2980. |
ETSI TS 119 602 Annex I; |
AdES digital signature, baseline B (ETSI TS 119 182-1). |
European Union scope; one list per specific ecosystem entity type. |
Machine-readable endpoint specified within the OJEU. Implements a pivoting mechanism to handle continuous updates. |
Note
As suggested in the EIDAS-ARF, for efficiency, implementations MAY routinely check Trust Anchors in Lists of Trusted Entities or Trusted Lists and store them locally. This allows, for example, Relying Party Instances running on mobile apps to facilitate offline presentations.
The example below shows a non-normative example of payload of a List of Trusted Entities for PID Providers.
{
"ListAndSchemeInformation": {
"LoTEVersionIdentifier": 1,
"LoTESequenceNumber": 1,
"LoTEType": "http://uri.etsi.org/19602/LoTEType/EUPIDProvidersList",
"SchemeOperatorName": [
{
"lang": "it",
"value": "Agenzia per l'Italia Digitale"
},
{
"lang": "en",
"value": "Agency for Digital Italy"
}
],
"SchemeOperatorAddress": {
"SchemeOperatorPostalAddress": [
{
"lang": "it",
"StreetAddress": "Via Liszt 21",
"Locality": "Roma",
"StateOrProvince": "RM",
"PostalCode": "00144",
"Country": "IT"
}
],
"SchemeOperatorElectronicAddress": [
{
"lang": "it",
"uriValue": "mailto:protocollo@pec.agid.gov.it"
}
]
},
"SchemeName": [
{
"lang": "it",
"value": "Elenco di Fiducia Italiano dei Fornitori di PID"
},
{
"lang": "en",
"value": "Italian Trusted List of PID Providers"
}
],
"SchemeInformationURI": [
{
"lang": "it",
"uriValue": "https://www.agid.gov.it/it/piattaforme/eidas-wallet/pid-providers-list"
},
{
"lang": "it",
"uriValue": "https://www.agid.gov.it/it/piattaforme/eidas-wallet/pid-providers-list/history"
}
],
"StatusDeterminationApproach": "http://uri.etsi.org/19602/PIDProvidersList/StatusDetn/EU",
"SchemeTypeCommunityRules": [
{
"lang": "en",
"uriValue": "http://uri.etsi.org/19602/PIDProvidersList/schemerules/EU"
}
],
"SchemeTerritory": "EU",
"PolicyOrLegalNotice": [
{
"LoTEPolicy": {
"lang": "en",
"uriValue": "https://www.agid.gov.it/legal-notice"
}
}
],
"PointersToOtherLoTE": [
{
"LoTELocation": "https://www.agid.gov.it/lote/pid-providers.json",
"ServiceDigitalIdentities": [
{
"X509SubjectNames": [
"CN=Italian Wallet LoTE Signer, O=AgID, C=IT"
]
}
],
"LoTEQualifiers": [
{
"LoTEType": "http://uri.etsi.org/19602/LoTEType/EUPIDProvidersList",
"SchemeOperatorName": [
{
"lang": "it",
"value": "Agenzia per l'Italia Digitale"
}
],
"SchemeTypeCommunityRules": [
{
"lang": "en",
"uriValue": "http://uri.etsi.org/19602/PIDProvidersList/schemerules/EU"
}
],
"SchemeTerritory": "EU",
"MimeType": "application/json"
}
]
}
],
"ListIssueDateTime": "2026-06-27T12:00:00Z",
"NextUpdate": "2026-12-27T12:00:00Z",
"DistributionPoints": [
"https://www.agid.gov.it/lote/pid-providers.json"
],
"SchemeExtensions": [
{
"extensionMetadata": "exampleValue"
}
]
},
"TrustedEntitiesList": [
{
"TrustedEntityInformation": {
"TEName": [
{
"lang": "it",
"value": "Fornitore Nazionale di Identità Digitale S.p.A."
},
{
"lang": "en",
"value": "National Digital Identity Provider S.p.A."
}
],
"TETradeName": [
{
"lang": "it",
"value": "NTRIT-12345678901"
}
],
"TEAddress": {
"TEPostalAddress": [
{
"lang": "it",
"StreetAddress": "Corso Vittorio Emanuele II, 101",
"Locality": "Torino",
"StateOrProvince": "TO",
"PostalCode": "10121",
"Country": "IT"
}
],
"TEElectronicAddress": [
{
"lang": "it",
"uriValue": "mailto:compliance@fornitorepid.it"
},
{
"lang": "it",
"uriValue": "tel:+39011555555"
}
]
},
"TEInformationURI": [
{
"lang": "it",
"uriValue": "https://www.fornitorepid.it/policies"
},
{
"lang": "it",
"uriValue": "https://www.fornitorepid.it/info"
},
{
"lang": "en",
"uriValue": "http://uri.etsi.org/19602/ListOfTrustedEntities/PIDProvider/IT"
}
],
"TEInformationExtensions": [
{
"providerStatus": "fully-compliant"
}
]
},
"TrustedEntityServices": [
{
"ServiceInformation": {
"ServiceName": [
{
"lang": "it",
"value": "Servizio di Rilascio e Gestione del Person Identification Data (PID)"
},
{
"lang": "en",
"value": "Person Identification Data (PID) Issuance and Management Service"
}
],
"ServiceDigitalIdentity": {
"X509Certificates": [
{
"encoding": "http://uri.etsi.org/19602/pkiOb/der",
"specRef": "RFC 5280",
"val": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0y...[BASE64_CERTIFICATE_DATA]..."
}
],
"X509SubjectNames": [
"CN=National PID Provider Issuing CA, O=National Digital Identity Provider S.p.A., C=IT"
]
},
"ServiceTypeIdentifier": "http://uri.etsi.org/19602/SvcType/PID/Issuance",
"SchemeServiceDefinitionURI": [
{
"lang": "en",
"uriValue": "https://www.agid.gov.it/schemes/pid-service-definition"
}
],
"ServiceSupplyPoints": [
{
"ServiceType": "http://uri.etsi.org/19602/SupplyPoint/API",
"uriValue": "https://api.fornitorepid.it/v1/pid"
}
],
"ServiceDefinitionURI": [
{
"lang": "it",
"uriValue": "https://www.fornitorepid.it/pid-service-documentation"
}
],
"ServiceInformationExtensions": [
{
"supportedAlgorithms": [
"ES256",
"Ed25519"
]
}
]
}
}
]
}
]
}
5.5.6. Embedded Disclosure Policy (EDP)¶
An Embedded Disclosure Policy (EDP) is defined in Article 2(9) of [CIR2024/2979]. Applicability and the three common policy types are Article 10 and Annex III of [CIR2024/2979], encoded in Section 4.2.5.2 of ETSI TS 119 472-3 (ISS-MDATA-EBD-4.2.5.2-06, ISS-MDATA-EBD-4.2.5.2-07, ISS-MDATA-EBD-4.2.5.2-08 and ISS-MDATA-EBD-4.2.5.2-09). An EDP MUST NOT be applied to a PID. The Wallet Unit evaluates the common types as specified in EUDIW Authorization. Non-disclosure towards the Relying Party is Section 4.2.5.1 of ETSI TS 119 472-3.
The Attestation Provider MUST include the EDP, if any, as the embedded_disclosure_policy member of credential_metadata within credential_configurations_supported, in compliance with OpenID4VCI or the extension thereof specified in ETSI TS 119 472-3.
The member MUST contain a policy_uri.
The member MAY contain the complete policy data in policy_data.
The Wallet Unit MAY receive only policy_uri when the exact policy identified by that URI is already preloaded.
Otherwise the URI and the policy data MUST be provided together.
An unresolved URI MUST cause the association and the affected disclosure to fail.
The Wallet Unit MUST NOT retrieve policy content from policy_uri.
Note
EIDAS-ARF HLR EDP_02 requires an identifier duplet taken from the WRPRC in the request (sub and a Service identifier), not from the WRPAC, including in a direct presentation.
The Service identifier is deferred as specified in Register of WRPs.
Until then, the Wallet Unit matches the EU-wide unique identifier (sub) and, where present, the entitlement URI.
ETSI TS 119 472-3 (ISS-MDATA-EBD-4.2.5.2-07) also encodes authorized parties by subject DN or by entitlement URI.
The subject_dn parameter is that ETSI encoding. The subject_dn parameter is not an evaluation input against the WRPAC.
The entitlement_uri parameter is matched against entitlements held in the WRPRC.
Annex A.3 of ETSI TS 119 475 defines sub-entitlements for Service Providers, currently for Payment Service Providers (e.g. https://uri.etsi.org/19475/SubEntitlement/psp/psp-ai).
For an intermediated presentation the WRPRC in the request is that of the intermediated Relying Party ([EIDAS-ARF] RPRC_19).
5.5.6.1. Embedded Disclosure Policy Data Model¶
The following table provides a comprehensive overview of the Embedded Disclosure Policy data model, including parameter names, data types, descriptions, and the specific clauses in ETSI TS 119 472-3 where each parameter is defined.
Warning
The parameter names are defined in this section and are not based on a normative ETSI specification. Section 4.2.5.2 of ETSI TS 119 472-3 defines the high level requirements for data model, but the final JSON schema will be published separately by ETSI. 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 |
Description |
Reference |
|---|---|---|
|
REQUIRED. string (URI). Unique identifier of the Embedded Disclosure Policy (EDP). The association of the EDP with an EAA MUST be established by including this unique URI. Resolution of the URI, including the prohibition on retrieving policy content from it, is specified above in Embedded Disclosure Policy (EDP). |
Clause 4.2.5.2 of [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-01, ISS-MDATA-EBD-4.2.5.2-02, ISS-MDATA-EBD-4.2.5.2-03) |
|
REQUIRED. string. Policy type classification. Valid values:
|
Clause 4.2.5.2 of [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-06, ISS-MDATA-EBD-4.2.5.2-07, ISS-MDATA-EBD-4.2.5.2-08) |
|
OPTIONAL. string. Description of the applicability of the policy to a particular community and/or class of application sharing common security requirements. |
Clause 4.2.5.2 of [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-04) |
|
OPTIONAL. string. Identifier of the authority or entity responsible for the policy. |
Clause 4.2.5.2 of [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-05) |
|
OPTIONAL. string (URL). Link to a website of the Attestation Provider (AP) explaining the disclosure policy guidelines in layman's terms. |
Clause 4.2.5.2 of [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-13, EDP_05) |
|
REQUIRED. array of objects. if |
Clause 4.2.5.2 of [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-07) |
|
REQUIRED. string.
EU-wide unique identifier of the authorized Relying Party, as specified in [EIDAS-ARF] Reg_32.
It MUST match the |
[EIDAS-ARF] EDP_02 |
|
OPTIONAL. string. Subject Distinguished Name (DN) of the Relying Party, formatted as an LDAP string compliant with RFC 4514. This is the ETSI encoding of ISS-MDATA-EBD-4.2.5.2-07. It is not an evaluation input: the Wallet Unit MUST NOT match it against the WRPAC, and EDP_02 evaluation uses the EU-wide unique identifier from the WRPRC, as specified in EUDIW Authorization. |
Clause 4.2.5.2 of [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-07) |
|
|
Clause 4.2.5.2 of [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-07) |
|
|
Clause 4.2.5.2 of [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-08) |
|
REQUIRED. string. Issuer Distinguished Name (DN) in LDAP string form compliant with RFC 4514. |
Clause 4.2.5.2 of [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-09) |
|
REQUIRED. string. Certificate serial number corresponding to the defined issuer. |
Clause 4.2.5.2 of [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-09) |
|
OPTIONAL. array of objects. Container for supplementary EDP extension structures. These structures MAY be ignored by the Wallet Unit.
The Wallet Unit MUST successfully process recognized rules even if unrecognized extensions are present.
The IT-Wallet extension is an object with an extension identifier, a Credential-format claim |
Clause 4.2.5.2 of [ETSI TS 119 472-3] (ISS-MDATA-EBD-4.2.5.2-10, ISS-MDATA-EBD-4.2.5.2-11, ISS-MDATA-EBD-4.2.5.2-12) |
The following are non-normative examples of EDPs with Authorized Relying Parties Only and Specific Root of Trust policy types.
{
"policy_uri": "https://example-ap.eu/policies/edp/v1/medical-records-access",
"policy_type": "authorized_rp_only",
"description": "Access is strictly restricted to authorized healthcare institutions and designated medical service providers.",
"policy_authority": "National Health and e-ID Authority",
"policy_info_url": "https://example-ap.eu/policies/edp/medical-laymans.html",
"authorized_parties": [
{
"subject_dn": "CN=Central University Hospital Pharmacy,O=Central Hospital Group,ORGID=VATES-12345678,C=FI"
},
{
"entitlement_uri": "https://uri.etsi.org/19475/SubEntitlement/psp/psp-ai"
}
],
"extensions": [
{
"id": "it-wallet-attribute-rule",
"path": ["medical_record_number"],
"rule": {
"policy_type": "authorized_rp_only",
"authorized_parties": [
{
"entitlement_uri": "https://uri.etsi.org/19475/SubEntitlement/healthcare/clinical"
}
]
}
}
]
}
{
"policy_uri": "https://example-ap.eu/policies/edp/v1/financial-sector-trust",
"policy_type": "specific_root_of_trust",
"description": "Access is restricted to Relying Parties whose WRPAC path contains an approved banking oversight root or intermediate certificate.",
"policy_authority": "European Banking Coordination Committee",
"policy_info_url": "https://example-ap.eu/policies/edp/finance-roots-laymans.html",
"trusted_roots": [
{
"issuer_dn": "CN=EU Financial Sector WRPAC Root CA G3,O=European Banking Authority,C=BE",
"serial_number": "550e8400e29b41d4a716446655440000"
},
{
"issuer_dn": "CN=National WRPAC Intermediate CA,O=Ministry of Finance,C=DE",
"serial_number": "109384729384729384"
}
]
}
5.5.6.2. Embedded Disclosure Policy Lifecycle¶
The locally stored EDP MUST remain valid as long as the Attestation it is associated with is valid and not revoked. The EDP MUST NOT have an independent validity status or revocation mechanism separate from the Attestation.
If an Attestation Provider adds, changes, or deletes an EDP for a Digital Credential it issues, the Attestation Provider MUST revoke that Digital Credential. The Wallet Unit detects the EDP change indirectly through the normal Attestation status checking mechanism (Status List), which will report that the Digital Credential as revoked. The locally stored EDP is then implicitly invalidated together with the Digital Credential. The User needs to request a new issuance to obtain the Digital Credential with the updated EDP.
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 Wallet Unit checks the Digital Credential status: if the Wallet Unit checks only at presentation time, a policy change will not be detected until the next presentation attempt.
Warning
Proactive refresh.
This specification does not use proactive refresh of an Embedded Disclosure Policy.
The prohibition on retrieving policy content from policy_uri, and the revocation of the Digital Credential when an EDP changes, are specified above in this section.
Proactive refresh is excluded because it would allow an Attestation Provider to change an EDP unilaterally, with the privacy and management consequences described in Discussion Topic D, and because its technical details are not defined in the ETSI standard.
5.6. National Trust Artifacts¶
This section defines the National Trust Framework that is based on OpenID Federation (OID-FED) combined with an X.509 PKI dedicated to the signature of Digital Credentials that requires X.509. The X.509 profile is detailed in the Common Trust Artifacts, while the following sections define the required Trust Artifacts and their conceptual roles defined in the following specifications of the OpenID Federation family, each within its own scope:
OpenID Federation 1.0 (OID-FED), the core framework. It defines the main artifacts including the Entity Statements, the federation endpoints and the Trust Marks.
OpenID Federation for Wallet Architectures (OID-FED-WALLET) the Wallet implementation profile for OpenID Federation 1.0. It defines the Entity Type Identifiers of the Entities used in this section.
OpenID Federation Subordinate Events (OID-FED-SUBORDINATE-EVENTS), that defines the Subordinate Events endpoint, used to obtain the registration history of an Immediate Subordinate.
Figure OID-FED Roles maps each wallet ecosystem entity onto the OpenID Federation role it plays. Wallet-Relying Parties and Wallet Providers are Federation Entities that MUST be registered by a Federation Authority, that is a Federation TA or Intermediate.
Fig. 5.2 OID-FED Roles¶
Note
Wallet Units are not Federation Entities, they are the End-User personal devices authenticated by their Wallet Provider.
5.6.1. Federation API Endpoints¶
OpenID Federation 1.0 uses RESTful web services secured over HTTPS.
All Federation Entities MUST publish their own Entity Configuration at the .well-known/openid-federation endpoint according to OID-FED Section 9.
Federation TA and Intermediates additionally expose the federation endpoints used to build and validate the Trust Chains and to support the Trust Marks.
The Federation Entity properties supported in the IT-Wallet specification profile are defined in OID-FED Section 5.1.1. The table below lists the federation endpoints and the Entity Types that MUST expose each of them. For each endpoint the table gives the request parameters used within IT-Wallet and whether each parameter is required. The table also gives the response returned by each endpoint. The request parameters follow OID-FED Section 8: they are sent as query parameters for GET requests and in the body for POST requests. The responses follow the OID-FED response formats referenced in the table.
Endpoint |
Request parameters |
Response |
|---|---|---|
fetch ( |
GET.
|
The requested Subordinate Statement, as a signed JWT ( |
list ( |
GET.
|
A JSON array of the Entity Identifiers of the Immediate Subordinates ( |
resolve ( |
GET.
|
The Resolve Response with the Resolved Metadata, the Trust Chain and the verified Trust Marks, as a signed JWT ( |
trust mark status ( |
POST.
|
The Trust Mark Status Response, that is the validity of the Trust Mark, as a signed JWT ( |
trust mark list ( |
GET.
|
A JSON array of the Entity Identifiers for which the Trust Mark is issued and still valid ( |
trust mark ( |
GET.
|
The requested Trust Mark, as a signed JWT ( |
historical keys ( |
GET. No request parameters. |
A signed JWK Set with the historical keys, as a signed JWT ( |
subordinate events ( |
GET.
|
A signed JWT with the history of the registration events. See the Subordinate Events specification Section 2.3. |
The Subordinate Events (/subordinate_events) endpoint is defined in OID-FED-SUBORDINATE-EVENTS.
Its purpose is to give a verifiable, historical track of the registration events concerning an Immediate Subordinate, such as its registration, the update of its Federation Entity Keys and its revocation.
For the request format, the response format and the event types refer to Section 2.2 and 2.3 of [OID-FED-SUBORDINATE-EVENTS].
Note
Within IT-Wallet the resolve (/resolve) endpoint MUST respond to unauthenticated requests only with cached information about Entities, if available, and the collection and assessment of a Trust Chain MUST NOT be the default action of the resolve endpoint, as described in OID-FED Section 18.1.
5.6.2. Entity Statements¶
A Entity Statement is a signed JWT issued by an entity (either itself or a superior) to share federation metadata. It contains the keys, policies, and configuration details required for the subject entity to participate in the federation.
The Entity Configuration is the Entity Statement that each Federation Entity issues about itself and publishes at the .well-known/openid-federation path (OID-FED Section 3).
Its iss and sub are the Federation Entity Identifier of the Entity itself, and it is signed with a Federation Entity Key.
The HTTP response sets the media type to application/entity-statement+jwt.
The Entity Configuration MAY also contain one or more Trust Marks.
A Subordinate Statement is the Entity Statement that a Trust Anchor or a Federation Intermediate issues about its Immediate Subordinate (OID-FED Section 3).
Its iss is the issuer, its sub is the Subordinate, and it carries the Federation Entity Keys of the Subordinate, so it is the statement that binds the Subordinate keys under its superior.
It MAY also carry a metadata policy and the Trust Marks about the Subordinate.
5.6.2.1. Entity Configuration¶
In the IT-Wallet ecosystem the Entity Configuration is published during the onboarding of the Entity (see Onboarding Processes) and is retrieved and validated during the trust evaluation, as defined in Federation Entity Authentication and Metadata Retrieval and Validation.
Technical details about the Entity Configuration of Wallet Provider, Credential Issuer and Relying Party are given in Section Wallet Provider Entity Configuration, Credential Issuer Entity Configuration and Relying Party Entity Configuration respectively.
Note
All the signature checks on the Entity Configurations, the Subordinate Statements and the Trust Marks are carried out with the Federation Entity Keys. For the supported algorithms refer to Section Cryptographic Algorithms.
5.6.2.2. Subordinate Statements¶
Trust Anchors and Federation Intermediates serve their Subordinate Statements through the fetch (/fetch) endpoint (OID-FED Section 8.1), where a Trust Evaluator retrieves them to validate the Entity Configuration signature of the Subordinate and to build the Trust Chain.
The metadata policy, when present, changes the final metadata of the Leaf.
The final metadata is derived from the whole Trust Chain, from the Entity Configuration up to the Subordinate Statement issued by the Trust Anchor, as defined in Metadata Retrieval and Validation.
The revocation of a Subordinate is expressed by the absence of a valid Subordinate Statement about it, as defined in Federation Trust Chain.
Within IT-Wallet the Subordinate Statements are issued during the onboarding of the Subordinate (see Onboarding Processes).
5.6.2.3. Entity Statement Parameters¶
In addition to the REQUIRED common parameters iss, sub, iat, exp and jwks as defined in OID-FED Section 3.1.1, within IT-Wallet specification profile the following parameters apply.
In Entity Configuration (OID-FED Section 3.1.2):
metadata (
metadata): REQUIRED JSON Object where each key is a metadata type identifier and its value is the metadata of that type (see OID-FED Section 3.1.1). All Entities MUST include at least one metadata forfederation_entityin their Entity Configurations. An Entity MAY include more than one metadata statement, with only one statement for each metadata type. The metadata types are defined in Entity Type Identifiers and Metadata.trust_marks (
trust_marks): REQUIRED for Leaves and Federation Intermediates. JSON Array of the Trust Marks of the subject. The registration Trust Mark is defined in Trust Mark registration-entity.trust_mark_issuers (
trust_mark_issuers): REQUIRED for the Federation TA. JSON Object that declares, for each Trust Mark type, the Federation Authorities that are trusted to issue it, given by their Federation Entity Identifiers. Within IT-Wallet the registration Trust Mark is issued only by the Federation Trust Anchor, so the Federation TA Entity Configuration MUST contain at least the Federation TA identifier.
In Subordinate Statement (OID-FED Section 3.1.3):
metadata_policy (
metadata_policy): OPTIONAL in OID-FED. Metadata policy bound to a specific metadata type and applied to the subtree, resolved by combining themetadata_policyClaims along the Trust Chain, as defined in OID-FED Section 6.1.4. Within IT-Wallet the Subordinate Statement about a Leaf MUST carry ametadata_policythat binds the protocol metadata of the Leaf to the values approved at onboarding. The Subordinate Statement MUST fix theorganization_nameof thefederation_entitymetadata and the protocol signature keys (jwks). The Subordinate Statement uses the metadata policy operators of OID-FED Section 6.1.3. When those parameters are present in the metadata type, the Subordinate Statement MUST also fix the service endpoints and the request, response and redirect URIs. Examples are therequest_uris,response_urisandredirect_urisof theopenid_credential_verifier. This Subordinate Statement is issued by the immediate superior that registered the Leaf, that is the Federation TA for the Leaves it registers directly and a Federation Intermediate for its affiliated Relying Parties. The Subordinate Statement about a Federation Intermediate does not carry ametadata_policy, because the Intermediate has no protocol metadata and its affiliated Relying Parties are bound by the Intermediate itself. A superior MAY further restrict the metadata policy set by its own superiors. A superior MUST NOT relax that metadata policy, as defined in OID-FED Section 6.1.1.constraints (
constraints): REQUIRED only for Federation TA. It carries the constraints applied to the subtree below the issuer. It MUST containallowed_entity_types, that restricts the metadata Entity Types the Subordinates in the subtree are allowed to publish, andmax_path_length, that limits the number of Intermediates between the issuer and the Trust Chain subject. Thefederation_entityEntity Type is always allowed and MUST NOT be listed inallowed_entity_types. See OID-FED Section 6.2.
All other optional parameters defined in OID-FED Section 3 that are not recognized within IT-Wallet specification profile MUST be ignored during the evaluation of an Entity Statement.
Note
Within IT-Wallet the Federation Entity Keys carried in the jwks of an Entity Configuration or of a Subordinate Statement are used to sign the federation statements and are validated through the Federation Trust Chain, not through X.509.
The X.509 signing PKI, whose certificates are used to sign the Attestations, is a separate trust relationship.
The Signing Trust Anchors of this PKI are distributed in the Entity Configuration of the Federation Trust Anchor.
Each one is provided in the x5c parameter (RFC 7517 Section 4.7) of a dedicated JWK within the jwks, distinct from the Federation Entity Keys, which do not carry x5c, as defined in Signing Trust Anchor Distribution.
The Document Signer certificates of the Credential Issuers are not carried in the jwks of the Entity Statements: they are included in the signed Attestations, in the x5chain header for the mdoc format and in the x5c header for the JOSE format, and are validated as defined in X.509 Certificate Chain Validation.
The issuance of these X.509 Certificates and the operation of the signing PKI are defined in the onboarding (see Onboarding Processes).
5.6.2.4. Entity Type Identifiers and Metadata¶
The Entity Type Identifiers of the ecosystem roles are defined in OpenID Federation for Wallet Architectures, section Wallet Architecture Entity Types, which is the wallet profile of OpenID Federation. Each role declares in its Entity Configuration one or more metadata types, whose parameters follow the protocol specification of that metadata type. The table below maps the roles of the ecosystem to their Entity Type Identifiers and gives the reference of the metadata protocol for each of them.
The Wallet Provider metadata type MUST be openid_wallet_provider, the Entity Type Identifier defined by OpenID Federation for Wallet Architectures (OID-FED-WALLET).
Entity |
Metadata Type |
|---|---|
Trust Anchor |
|
Wallet Provider |
|
Credential Issuer |
|
Relying Party |
|
Relying Party Intermediary |
|
Note
A Relying Party Intermediary is a Federation Intermediate.
As an intermediary it is not involved in the protocol flows, so it does not publish a protocol metadata of its own, only the federation_entity metadata.
It publishes the Subordinate Statements of its affiliated Relying Parties, and each affiliated Relying Party sets its authority_hints to the Intermediary.
Its registration Trust Mark uses the intermediate Entity Type Identifier in the Trust Mark type, as defined in Trust Mark Types and Schema.
Note
When a PID or EAA Provider implements both the Credential Issuer and the Authorization Server within the same Entity, it MUST include both openid_credential_issuer and oauth_authorization_server in its metadata types.
When the Authorization Server is a separate Entity, the Credential Issuer metadata MUST contain the authorization_servers parameter with the identifier of the Authorization Server.
According to OPENID4VCI the Authorization Server MAY be external to the Entity that implements the Credential Endpoint, therefore the use of oauth_authorization_server is OPTIONAL.
Furthermore, should there be a necessity for User Authentication by the Credential Issuer, it could be necessary to include the relevant metadata type openid_credential_verifier.
The federation_entity metadata carries the informational parameters below together with the federation endpoint parameters.
The federation endpoint parameters (federation_fetch_endpoint, federation_list_endpoint, federation_resolve_endpoint and the others) are published only by the Federation TA and the Intermediates, according to their obligations defined in the Federation API Endpoints section above, and a Leaf does not expose them.
The informational parameters below are OPTIONAL in OID-FED. IT-Wallet specification profile supports the claims in the following table.
Claim |
Description |
|---|---|
organization_name |
REQUIRED. See OID-FED Section 5.2.2 |
organization_uri |
REQUIRED. URL of a Web page for the organization owning this Entity. See OID-FED Section 5.2.2 |
policy_uri |
REQUIRED. See OID-FED Section 5.2.2 |
logo_uri |
REQUIRED. URL of the entity logo, in SVG format. See OID-FED Section 5.2.2 |
contacts |
REQUIRED. Within IT-Wallet it is the institutional verified email address (PEC) of the entity. See OID-FED Section 5.2.2 |
tos_uri |
OPTIONAL. URL of the terms of service of the entity. See OID-FED Section 5.2.2 |
Metadata about Wallet Provider, Credential Issuer and Relying Party are given in Section Wallet Solution Metadata, Credential Issuer Metadata and Relying Party Metadata respectively.
5.6.3. Entity Statement Examples¶
The following sections provide non-normative examples of Entity Statements, both for the direct onboarding under the Federation TA and for the intermediated onboarding under a Federation Intermediate.
All the statements are signed JWTs with the JOSE header alg, kid and typ set to entity-statement+jwt, and only the payloads are shown.
The protocol metadata and the pinned key sets are truncated ({ ... }) as their full definition is given in the metadata sections referenced above.
5.6.3.1. Entity Configuration of a Federation TA¶
The Federation TA is the root of the Trust Chain.
Its Entity Configuration has no authority_hints, and its jwks provides, in addition to the Federation Entity Keys, the Signing Trust Anchors of the X.509 signing PKI and the Authentication Trust Anchors of the X.509 authentication PKI, as dedicated JWKs with x5c.
A Signing Trust Anchor is the root of the PKI that issues the Document Signer certificates. An Authentication Trust Anchor is the root of the PKI that issues the Relying Party authentication certificates used for the mdoc reader authentication in the Proximity Flow.
Each such JWK is identified by its kid and by the properties of the certificate provided in its x5c.
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://trust-anchor.eid-wallet.example.it",
"iat": 1718207217,
"exp": 1749743216,
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "yRnq6oEvrxcZ1zYStADzTLX-qSw3Pb7E6mqJGNqnygA",
"x": "xrk5H1nEWrNYRb7FBamuSRHHf-XWjv1k-uZCSVCSAnc",
"y": "FM5YI7GvkTB8xxTiMTTSycDL0nguRowbibgfyqKjB0k"
},
{
"kty": "EC",
"crv": "P-256",
"use": "sig",
"kid": "signing-trust-anchor-01",
"x": "B0sj_kZRT4A-oP9Y57dinEiDFTG-tjuPu7MiiQHHQ_g",
"y": "iMDCuatE53HiX2VTDJ_q7LbQ-A7fgjXZpJsW-eZzge0",
"x5c": [
"<Signing Trust Anchor X.509 certificate>"
]
},
{
"kty": "EC",
"crv": "P-256",
"use": "sig",
"kid": "authentication-trust-anchor-01",
"x": "Zm3kQp9rB1xYtA5nF2wEsRHHf-XWjv1k-uZCSVCSAn8",
"y": "Km9ZI7GvkTB8xxTiMTTSycDL0nguRowbibgfyqKjB2m",
"x5c": [
"<Authentication Trust Anchor X.509 certificate>"
]
}
]
},
"metadata": {
"federation_entity": {
"organization_name": "IT-Wallet Federation Trust Anchor",
"organization_uri": "https://trust-anchor.eid-wallet.example.it",
"policy_uri": "https://trust-anchor.eid-wallet.example.it/policy",
"logo_uri": "https://trust-anchor.eid-wallet.example.it/logo.svg",
"contacts": [
"trust-anchor@pec.example.it"
],
"federation_fetch_endpoint": "https://trust-anchor.eid-wallet.example.it/fetch",
"federation_list_endpoint": "https://trust-anchor.eid-wallet.example.it/list",
"federation_resolve_endpoint": "https://trust-anchor.eid-wallet.example.it/resolve",
"federation_trust_mark_status_endpoint": "https://trust-anchor.eid-wallet.example.it/trust_mark_status",
"federation_trust_mark_list_endpoint": "https://trust-anchor.eid-wallet.example.it/trust_marked_list",
"federation_trust_mark_endpoint": "https://trust-anchor.eid-wallet.example.it/trust_mark",
"federation_historical_keys_endpoint": "https://trust-anchor.eid-wallet.example.it/historical_keys",
"federation_subordinate_events_endpoint": "https://trust-anchor.eid-wallet.example.it/subordinate_events"
}
},
"trust_mark_issuers": {
"https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_wallet_provider": [
"https://trust-anchor.eid-wallet.example.it"
],
"https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_credential_issuer": [
"https://trust-anchor.eid-wallet.example.it"
],
"https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_credential_verifier": [
"https://trust-anchor.eid-wallet.example.it"
],
"https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/intermediate": [
"https://trust-anchor.eid-wallet.example.it"
]
}
}
5.6.3.2. Subordinate Statement of Leaf issued by the Federation TA¶
The Federation TA issues a Subordinate Statement about each Leaf it registers directly.
The statement carries the Federation Entity Keys of the Leaf, the metadata_policy that fixes the protocol keys and, when present, the service endpoints and the URIs of the Leaf to the values approved at onboarding, and the constraints of the subtree.
The following non-normative example is the Subordinate Statement that the Federation TA issues about a Wallet Provider Leaf.
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://wallet-provider.example.it",
"iat": 1718207217,
"exp": 1749743216,
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "LqZSJoAEybT9V3jUQfZYUjVV-U5jV34sgbhIsIXltSY",
"x": "38k73K5mw7Ev34lMwJhMBy5L2PnP9ayGfnMMtk4UZAw",
"y": "4ohTh7joeKLhRfPRSXQvnu-OMqUIn9lzoJAp_ztuv1A"
}
]
},
"metadata_policy": {
"openid_wallet_provider": {
"jwks": {
"value": { "... the Wallet Provider protocol keys registered at onboarding ..." }
}
}
},
"constraints": {
"allowed_entity_types": [
"openid_wallet_provider"
],
"max_path_length": 0
}
}
The following non-normative example is the Subordinate Statement that the Federation TA issues about a Relying Party Leaf.
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://access.privatecompany.example.com",
"iat": 1718207217,
"exp": 1749743216,
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "cwdtstHkIOqwWD8UeXjY_NdKfB-d1bzIx7XKBQNVbsg",
"x": "y8ahuTA-G4oLpTFYp7YrTd99kLPSlNoLPmwGJcXvWY8",
"y": "HNRLc-1ennbeBtF3LbtBdq_0c7EX4samlHnwXilH_i0"
}
]
},
"metadata_policy": {
"openid_credential_verifier": {
"jwks": {
"value": { "... the Relying Party protocol keys registered at onboarding ..." }
},
"request_uris": {
"value": [
"https://access.privatecompany.example.com/openid4vp/request"
]
},
"response_uris": {
"value": [
"https://access.privatecompany.example.com/openid4vp/response"
]
},
"redirect_uris": {
"value": [
"https://access.privatecompany.example.com/openid4vp/callback"
]
}
}
},
"constraints": {
"allowed_entity_types": [
"openid_credential_verifier"
],
"max_path_length": 0
}
}
The following non-normative example is the Subordinate Statement that the Federation TA issues about a Credential Issuer Leaf.
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://badge-issuer.example.it",
"iat": 1718207217,
"exp": 1749743216,
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "r6KG1Jbgcv0iNW1y0ERO_X2Jw926V2UHRJH8d-GcDEI",
"x": "26w7G_Myczl2-S8n0m1lMIjo3IzgZky-yNVdwaKOmhQ",
"y": "2WMnoyCXqS4FUdv9e4JEAJKyhRIODi5xGfFdnA6cnVM"
}
]
},
"metadata_policy": {
"openid_credential_issuer": {
"jwks": {
"value": { "... the Credential Issuer protocol keys registered at onboarding ..." }
},
"credential_endpoint": {
"value": "https://badge-issuer.example.it/credential"
}
}
},
"constraints": {
"allowed_entity_types": [
"openid_credential_issuer",
"oauth_authorization_server"
],
"max_path_length": 0
}
}
5.6.3.3. Subordinate Statement of an Intermediate¶
The Federation TA issues a Subordinate Statement about the Federation Intermediate.
The constraints restrict the subtree of the Intermediate to the Relying Parties it can intermediate, and max_path_length is set to 1 to allow the single level of intermediation between the Federation TA and the affiliated Relying Parties.
It carries no metadata_policy: the affiliated Relying Parties are bound by the Intermediate in the Subordinate Statements it issues about them.
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://intermediary.example.com",
"iat": 1718207217,
"exp": 1749743216,
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "EycKTxHbR_s_aZB46j_1ObHG3n2QEQ0sU0-gRGdBWv0",
"x": "4sAmMPyNl21DjQ_i6C4y0erHz3IVsVETYpH4kOoKFb8",
"y": "B5nPVnBVBss55KGCJG8_EyT72PJKU8n_k8SMZdPUIaE"
}
]
},
"constraints": {
"allowed_entity_types": [
"openid_credential_verifier"
],
"max_path_length": 1
}
}
5.6.3.4. Subordinate Statement about a Leaf issued by a Federation Intermediate¶
The Federation Intermediate issues a Subordinate Statement about each affiliated Relying Party.
It carries the metadata_policy that binds the protocol metadata of the affiliated Relying Party to the values approved at onboarding, exactly as the Federation TA does for the Leaves it registers directly.
The constraints of the subtree are set by the Federation TA in the statement about the Intermediate.
In the National Trust Framework an Intermediary intermediates only Relying Parties.
{
"iss": "https://intermediary.example.com",
"sub": "https://rp.affiliated.example.com",
"iat": 1718207217,
"exp": 1749743216,
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "n47zfejmk3V14aKUQCEcA7sTKi-SXMw7E1MFnpQCL-0",
"x": "H3_bMVOWJoDSBenUzelAbAj4vanmXNJ3KT2Vk_OaehI",
"y": "aMoXkKSssBtMHwSCR-hY8mmFQFs3Hf5iQ0zFWMHAQfc"
}
]
},
"metadata_policy": {
"openid_credential_verifier": {
"jwks": {
"value": { "... the affiliated Relying Party protocol keys registered at onboarding ..." }
},
"request_uris": {
"value": [
"https://rp.affiliated.example.com/openid4vp/request"
]
},
"response_uris": {
"value": [
"https://rp.affiliated.example.com/openid4vp/response"
]
},
"redirect_uris": {
"value": [
"https://rp.affiliated.example.com/openid4vp/callback"
]
}
}
}
}
5.6.3.5. Entity Configuration of a Federation Intermediate¶
The Federation Intermediate is a federation_entity only.
Its Entity Configuration points to the Federation TA through authority_hints and carries its registration Trust Mark with the intermediate Entity Type Identifier.
It exposes the fetch and list endpoints used to serve the Subordinate Statements of its affiliated Relying Parties.
{
"iss": "https://intermediary.example.com",
"sub": "https://intermediary.example.com",
"iat": 1718207217,
"exp": 1749743216,
"authority_hints": [
"https://trust-anchor.eid-wallet.example.it"
],
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "EycKTxHbR_s_aZB46j_1ObHG3n2QEQ0sU0-gRGdBWv0",
"x": "4sAmMPyNl21DjQ_i6C4y0erHz3IVsVETYpH4kOoKFb8",
"y": "B5nPVnBVBss55KGCJG8_EyT72PJKU8n_k8SMZdPUIaE"
}
]
},
"metadata": {
"federation_entity": {
"organization_name": "Intermediary S.r.l.",
"organization_uri": "https://intermediary.example.com",
"policy_uri": "https://intermediary.example.com/policy",
"logo_uri": "https://intermediary.example.com/logo.svg",
"contacts": [
"intermediary@pec.example.com"
],
"federation_fetch_endpoint": "https://intermediary.example.com/fetch",
"federation_list_endpoint": "https://intermediary.example.com/list"
}
},
"trust_marks": [
{
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/intermediate",
"trust_mark": "<signed Trust Mark JWT>"
}
]
}
5.6.3.6. Entity Configuration of a Leaf¶
Each Leaf publishes its own Entity Configuration, pointing to its immediate superior through authority_hints and carrying its registration Trust Mark.
The examples below report the main claims, the protocol metadata is referenced to its metadata section.
The following non-normative example is the Entity Configuration of a Wallet Provider Leaf.
{
"iss": "https://wallet-provider.example.it",
"sub": "https://wallet-provider.example.it",
"iat": 1718207217,
"exp": 1749743216,
"authority_hints": [
"https://trust-anchor.eid-wallet.example.it"
],
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "LqZSJoAEybT9V3jUQfZYUjVV-U5jV34sgbhIsIXltSY",
"x": "38k73K5mw7Ev34lMwJhMBy5L2PnP9ayGfnMMtk4UZAw",
"y": "4ohTh7joeKLhRfPRSXQvnu-OMqUIn9lzoJAp_ztuv1A"
}
]
},
"metadata": {
"federation_entity": {
"organization_name": "Example Wallet Provider",
"organization_uri": "https://wallet-provider.example.it",
"policy_uri": "https://wallet-provider.example.it/policy",
"logo_uri": "https://wallet-provider.example.it/logo.svg",
"contacts": [
"wallet-provider@pec.example.it"
]
},
"openid_wallet_provider": { ".. as defined in the Wallet Solution Metadata section ..." }
},
"trust_marks": [
{
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_wallet_provider",
"trust_mark": "<signed Trust Mark JWT>"
}
]
}
The following non-normative example is the Entity Configuration of a Relying Party Leaf.
{
"iss": "https://access.privatecompany.example.com",
"sub": "https://access.privatecompany.example.com",
"iat": 1718207217,
"exp": 1749743216,
"authority_hints": [
"https://trust-anchor.eid-wallet.example.it"
],
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "cwdtstHkIOqwWD8UeXjY_NdKfB-d1bzIx7XKBQNVbsg",
"x": "y8ahuTA-G4oLpTFYp7YrTd99kLPSlNoLPmwGJcXvWY8",
"y": "HNRLc-1ennbeBtF3LbtBdq_0c7EX4samlHnwXilH_i0"
}
]
},
"metadata": {
"federation_entity": {
"organization_name": "Private Company S.p.A.",
"organization_uri": "https://access.privatecompany.example.com",
"policy_uri": "https://access.privatecompany.example.com/policy",
"logo_uri": "https://access.privatecompany.example.com/logo.svg",
"contacts": [
"compliance@pec.privatecompany.example.com"
]
},
"openid_credential_verifier": { "... as defined in the Relying Party Metadata section ..." }
},
"trust_marks": [
{
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_credential_verifier",
"trust_mark": "<signed Trust Mark JWT>"
}
]
}
The following non-normative example is the Entity Configuration of a Credential Issuer Leaf.
{
"iss": "https://badge-issuer.example.it",
"sub": "https://badge-issuer.example.it",
"iat": 1718207217,
"exp": 1749743216,
"authority_hints": [
"https://trust-anchor.eid-wallet.example.it"
],
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"kid": "r6KG1Jbgcv0iNW1y0ERO_X2Jw926V2UHRJH8d-GcDEI",
"x": "26w7G_Myczl2-S8n0m1lMIjo3IzgZky-yNVdwaKOmhQ",
"y": "2WMnoyCXqS4FUdv9e4JEAJKyhRIODi5xGfFdnA6cnVM"
}
]
},
"metadata": {
"federation_entity": {
"organization_name": "Comune di Example",
"organization_uri": "https://badge-issuer.example.it",
"policy_uri": "https://badge-issuer.example.it/policy",
"logo_uri": "https://badge-issuer.example.it/logo.svg",
"contacts": [
"protocollo@pec.comune.example.it"
]
},
"openid_credential_issuer": { "... as defined in the Credential Issuer Metadata section ..." }
},
"trust_marks": [
{
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_credential_issuer",
"trust_mark": "<signed Trust Mark JWT>"
}
]
}
5.6.4. Trust Marks¶
As a result of a successful onboarding completion, entities receive IT-Wallet Federation Trust Marks. Trust Marks are issued by the Federation Authority through the Federation Trust Mark Endpoint. For direct onboarding the issuer is the Trust Anchor. For mediated onboarding the issuer is the Intermediate. A Trust Mark attests compliance with IT-Wallet technical profiles, authorization policies, or both.
5.6.4.1. Trust Mark Types and Schema¶
Trust Mark identifiers MUST follow a hierarchical schema that reflects the authorization scope:
https://<federation_authority_domain>/trust_marks/<purpose>/<entity_type>
Where:
<federation_authority_domain>: The domain of the issuing Federation Authority.
<purpose>: The Trust Mark purpose. Theregistration-entitypurpose is REQUIRED for all entities as a result of the onboarding process. Additional Trust Mark purposes MAY be defined for future needs, but they are not required for the authorization processes defined in Authorization.
<entity_type>: The Entity Type Identifier of the subject, among those defined in Entity Type Identifiers and Metadata (for exampleopenid_credential_issueroropenid_credential_verifier), andintermediatefor a Relying Party Intermediary.
Note
The national Federation TA is the Trust Mark issuer recognized within the federation.
Additional Trust Mark purposes, when defined, MAY therefore be issued by other Entities authorized through trust_mark_issuers.
5.6.4.2. Trust Mark registration-entity¶
Within IT-Wallet the registration-entity Trust Mark is the registration Trust Mark of an entity.
The only Trust Mark issuer for the registration Trust Mark MUST be the Federation TA.
It attests the registration and carries the authorization data of the entity, that is its entitlements and, where applicable, the Credentials and the attributes it is authorized to issue or to request.
This registration Trust Mark is the functional analogue of the Wallet-Relying Party Registration Certificate (WRPRC) of the EUDIW Trust Framework.
For National proximity presentation, the euWrprc member of requestInfo is a CBOR byte string containing the UTF-8 bytes of this Trust Mark's compact signed JWT. This serialization is National-only. The authenticated reader-certificate path controls decoding and the Trust Mark cannot select or change the path.
An entity receives one registration Trust Mark for each role it holds, with the <entity_type> component of the identifier set accordingly.
A Relying Party Intermediary receives its registration Trust Mark with the intermediate <entity_type> in the identifier.
In the EUDIW Trust Framework the intermediary relationship is expressed in the registration data of the intermediated Relying Party.
In the National Trust Framework, instead, it is expressed through the federation hierarchy: the Intermediary is a Federation Intermediate that publishes the Subordinate Statements of its affiliated Relying Parties, and each affiliated Relying Party sets its authority_hints to the Intermediary.
The registration Trust Mark of each affiliated Relying Party is also issued by the Federation Trust Anchor.
For this reason no dedicated intermediary field is present in the Trust Mark.
The onboarding of the Intermediary is defined in Relying Party Intermediary.
5.6.4.2.1. Trust Mark Types and Schema: Trust Mark Structure¶
Trust Marks in Entity Configuration MUST be represented as JSON objects containing the following claims:
Claim |
Description |
|---|---|
trust_mark_type |
REQUIRED.
Identifier for the type of Trust Mark following the schema: |
trust_mark |
REQUIRED. A signed JSON Web Token representing the Trust Mark issued by the Federation Authority. |
The Trust Mark JWT (contained in the trust_mark claim above) MUST be a signed JWT that includes both a JOSE header and a payload, as defined in OID-FED Section 7.
5.6.4.2.2. Trust Mark Types and Schema: Trust Mark JWT Header¶
The JOSE header of the Trust Mark JWT MUST include the following parameters:
Parameter |
Description |
|---|---|
alg |
REQUIRED. The cryptographic algorithm used to sign the Trust Mark JWT. It MUST be one of the algorithms supported for Federation Entity Keys (see Cryptographic Algorithms). |
kid |
REQUIRED. Key ID of the Federation Entity Key used to sign the Trust Mark, as defined in OID-FED Section 7. |
typ |
REQUIRED.
Media type of the Trust Mark JWT.
It MUST be set to |
A non-normative example of a Trust Mark JWT header:
{
"alg": "ES256",
"kid": "ta-federation-key-1",
"typ": "trust-mark+jwt"
}
5.6.4.2.3. Trust Mark Types and Schema: Trust Mark JWT Payload¶
The Trust Mark JWT payload includes the following claims:
Claim |
Description |
|---|---|
iss |
REQUIRED. The Federation Trust Anchor that issues the Trust Mark. |
sub |
REQUIRED. Federation Entity Identifier of the subject. |
trust_mark_type |
REQUIRED.
Unique Trust Mark identifier.
It MUST match the |
iat |
REQUIRED. Trust Mark issuance timestamp. |
exp |
REQUIRED. Trust Mark expiration timestamp. |
public_body |
REQUIRED. Boolean indicating whether the entity is a public sector body. |
vat_number |
REQUIRED when |
legal_identifier |
RECOMMENDED. Legal registration number or identifier of the entity (e.g., business registration number, tax code). |
ipa_code |
REQUIRED when |
organization_name |
REQUIRED. Full name of the Organizational Entity. |
REQUIRED. Institutional or PEC email of the organization. |
|
support_uri |
REQUIRED. Support contact of the entity. A data deletion request uses this value, as specified in EUDI-TS 7, for the erasure of personal data previously provided through the Wallet Instance. The value MUST be an HTTPS URL, an email address, or a telephone number. |
srv_description |
REQUIRED.
Multilingual description of the service provided by the entity.
Each entry contains |
entitlements |
REQUIRED.
Array of entitlement URIs identifying the role of the subject, as defined in ETSI TS 119 475 Annex A.2 (e.g. |
provides_attestations |
REQUIRED for a Credential Issuer, MUST NOT be present otherwise.
Array of the Credential types the subject is authorized to issue.
Each entry contains |
credentials |
REQUIRED for a Relying Party that requests Credentials, MUST NOT be present otherwise.
Array of the Credential queries the subject is authorized to request, used for the Overasking Check.
Each entry contains |
purpose |
REQUIRED for a Relying Party that requests Credentials, MUST NOT be present otherwise.
Multilingual list describing the data processing associated with the intended use.
Each entry contains |
privacy_policy |
REQUIRED for a Relying Party that requests Credentials, MUST NOT be present otherwise. URL of the subject privacy policy. |
supervisory_authority |
REQUIRED.
Data Protection Authority information, with |
logo_uri |
REQUIRED. URL pointing to the Trust Mark for UI/UX purposes. |
ref |
OPTIONAL. URL with additional web information about the Trust Mark. |
Note
The claims that carry the authorization data (entitlements, provides_attestations, credentials, purpose, privacy_policy, supervisory_authority) and the identity and transparency claims aligned with the WRPRC (public_body, support_uri, srv_description) are defined in analogy with the EUDIW Wallet-Relying Party Registration Certificate (ETSI TS 119 475), so that a Trust Evaluator can reuse the same authorization logic for both artifacts.
Note
The revocation status of a Trust Mark is verified through the trust mark status (/trust_mark_status) endpoint (OID-FED Section 8.4), not through a status list carried in the token.
This is the difference with the WRPRC, whose status claim points to a status list: the Trust Mark relies on the federation native revocation mechanism.
The consumption of these claims by the Trust Evaluator is defined in Authorization.
The following non-normative examples illustrate the registration Trust Mark JWT content for a Credential Issuer, a public non-qualified EAA Provider issuing an Employee Badge, for a Relying Party requesting that Employee Badge, and for a Relying Party Intermediary.
Credential Issuer, a public non-qualified EAA Provider issuing the Employee Badge:
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://badge-issuer.example.it",
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_credential_issuer",
"iat": 1718207217,
"exp": 1749743216,
"public_body": true,
"ipa_code": "c_h501",
"legal_identifier": "80012345678",
"organization_name": "Comune di Example",
"email": "protocollo@comune.example.it",
"support_uri": "https://badge-issuer.example.it/support",
"srv_description": [
{"lang": "it", "value": "Servizio di emissione del badge dipendente"},
{"lang": "en", "value": "Employee Badge issuance service"}
],
"entitlements": ["Non_Q_EAA_Provider"],
"provides_attestations": [
{
"format": "dc+sd-jwt",
"meta": {
"vct_values": ["urn:it-wallet:badge:1"]
},
"claim": [
{"path": ["document_number"]},
{"path": ["works_for"]},
{"path": ["given_name"]},
{"path": ["family_name"]},
{"path": ["job_title"]}
]
}
],
"supervisory_authority": {
"uri": "https://www.dpa.example.it/report",
"email": "reports@dpa.example.it",
"phone": "+390612345678"
},
"logo_uri": "https://badge-issuer.example.it/logo.svg"
}
Relying Party, a private organization requesting the Employee Badge for physical access control:
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://access.privatecompany.example.com",
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/openid_credential_verifier",
"iat": 1718207217,
"exp": 1749743216,
"public_body": false,
"vat_number": "IT12345678901",
"legal_identifier": "12345678901",
"organization_name": "Private Company S.p.A.",
"email": "compliance@privatecompany.example.com",
"support_uri": "https://access.privatecompany.example.com/support",
"srv_description": [
{"lang": "it", "value": "Servizio di controllo dell'accesso fisico"},
{"lang": "en", "value": "Physical access control service"}
],
"entitlements": ["Service_Provider"],
"credentials": [
{
"format": "dc+sd-jwt",
"meta": {
"vct_values": ["urn:it-wallet:badge:1"]
},
"claim": [
{"path": ["given_name"]},
{"path": ["family_name"]},
{"path": ["works_for"]},
{"path": ["job_title"]}
]
}
],
"purpose": [
{"lang": "en", "value": "Employee verification for physical access control"},
{"lang": "it", "value": "Verifica del dipendente per il controllo dell'accesso fisico"}
],
"privacy_policy": "https://access.privatecompany.example.com/privacy",
"supervisory_authority": {
"uri": "https://www.dpa.example.it/report",
"email": "reports@dpa.example.it",
"phone": "+390612345678"
},
"logo_uri": "https://access.privatecompany.example.com/logo.svg"
}
Relying Party Intermediary.
It declares no intended use of its own, so its registration Trust Mark carries no credentials and no purpose.
It is a Federation Intermediate, and its affiliated Relying Parties set their authority_hints to it.
{
"iss": "https://trust-anchor.eid-wallet.example.it",
"sub": "https://intermediary.example.com",
"trust_mark_type": "https://trust-anchor.eid-wallet.example.it/trust_marks/registration-entity/intermediate",
"iat": 1718207217,
"exp": 1749743216,
"public_body": false,
"vat_number": "IT98765432109",
"legal_identifier": "98765432109",
"organization_name": "Intermediary S.r.l.",
"email": "info@intermediary.example.com",
"support_uri": "https://intermediary.example.com/support",
"srv_description": [
{"lang": "it", "value": "Servizio di intermediazione per Relying Party"},
{"lang": "en", "value": "Intermediation service for Relying Parties"}
],
"entitlements": ["Service_Provider"],
"supervisory_authority": {
"uri": "https://www.dpa.example.it/report",
"email": "reports@dpa.example.it",
"phone": "+390612345678"
},
"logo_uri": "https://intermediary.example.com/logo.svg"
}
5.7. Trust Management and Lifecycle¶
This section describes the lifecycle of the Trust Artifacts (Trust Artifacts Lifecycle State Machine) and the mechanisms used to manage their status (Revocation Mechanisms). The lifecycle of the Entities, the events that change their registration and the effects that those events produce on the Trust Artifacts are described in Lifecycle Management.
5.7.1. Trust Artifacts Lifecycle State Machine¶
State Machines for Trust Artifacts are described below:
For WRPAC, WRPRC and Sign/Seal Certificates, the lifecycle states are
VALIDandREVOKED. The transition fromVALIDtoREVOKEDis triggered by the revocation of the Trust Artifact, which can be initiated by the corresponding Trust Artifact provider due to various reasons such as key compromise, organizational changes, or non-compliance with framework policies. Once a Trust Artifact is in theREVOKEDstate, that Trust Artifact MUST NOT be trusted for any operational use within the ecosystem. Any Entity relying on that Trust Artifact MUST reject it for authentication, authorization, or any other trust-related operations.A WRPAC in the
VALIDstate MUST NOT be present in the designated CRL. Alternatively, a WRPAC in theVALIDstate MUST return agoodstatus in the OCSP response. A WRPAC in theREVOKEDstate MUST be present in the designated CRL. Alternatively, a WRPAC in theREVOKEDstate MUST return arevokedstatus in the OCSP response.A WRPRC in
VALIDstate MUST return a0x00status in the corresponding Status List Token. A WRPRC inREVOKEDstate MUST have status value0x01within the corresponding Status List Token.
For Trust Lists (LoTE, LOTL, EUMS TL), the lifecycle states are
CURRENTandHISTORICAL. The transition fromCURRENTtoHISTORICALis triggered by the publication of a new version of the Trust List that replaces the previous version. Once a Trust List is in theHISTORICALstate, it MUST NOT be used for any operational use within the ecosystem. Two exceptions apply: the validation of Trust List trustworthiness via the pivoting mechanism, and the validation of historical operations via theServiceHistorycomponent of the Trust List.Trust Marks: the status of a Trust Mark are
ACTIVE,EXPIRED,REVOKED. The status can be checked using the Trust Mark Status endpoint (see Section 8.4 of OID-FED).
Note
Register, Entity Configurations and Subordinate Statements are simply published or unpublished. During their publication they can be updated.
The diagram Fig. 5.3 highlights the state machine of the aforementioned Trust Artifacts:
Fig. 5.3 Trust Artifacts States.¶
5.7.2. Federation Entity Key Rotation¶
The Federation Entity Key of an Entity is attested by the Subordinate Statement that its immediate superior publishes about it, and the Entity Configuration of the Entity MUST be signed with a key that the Subordinate Statement attests. A new Federation Entity Key becomes trusted only when the superior attests it in the Subordinate Statement.
The Federation Entity key rotation MUST be performed as defined in the following steps.
The Entity adds the new key to the
jwksof its Entity Configuration. The Entity MUST keep signing the Entity Configuration with the previous key, which is still attested.In the Entity Update process (see Entity Update) the superior MUST read the
jwksfrom the Entity Configuration. The superior MUST check that the Entity Configuration is signed with an attested key. The superior MUST re-issue the Subordinate Statement attesting the new key.The previous key and the new key then coexist until the Trust Chains built with the previous Subordinate Statement have expired. During the coexistence the Entity keeps signing with the previous key, so that both the previous and the new Subordinate Statement validate its Entity Configuration.
Once the validity window of the Trust Chain has passed, the Entity MAY sign its Entity Configuration with the new key.
When the Entity wants to remove the previous key, the Entity MAY remove it from the
jwksand notify this change to the superior through the Entity Update process (see Entity Update). The superior MUST remove that key from the Subordinate Statement.The superior MUST register the event as a
jwks_updatepublished on the Federation Subordinate Events Endpoint.
5.7.3. Revocation Mechanisms¶
This section describes the artifacts that are employed in Trust Artifacts Lifecycle State Machine to manage the status of certificates and entities by detailing respective formats and parameters. The main distinction is the following:
To manage Wallet-Relying Party Access Certificates and Sign/Seal Certificates, the entities acting as Trust Anchors for these certificates MUST:
make available at least one revocation mechanism among Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP).
issue WRPACs and Sign/Seal Certificates with at least an extension corresponding to the provided revocation mechanism.
To manage Wallet-Relying Party Registration Certificates, each Provider of Wallet Relying Party Registration Certificates MUST:
make available an endpoint to request Token Status List (WRPRC Profile).
issue WRPRCs with the appropriate parameter
statusas described in Wallet-Relying Party Registration Certificate (WRPRC) Profile.
Note
ETSI EN 319 411-1 recommends the support of OCSP, see clause CSS-6.3.10-06 and Note 2.
5.7.3.1. Certificate Revocation List (CRL)¶
Certificate Revocation Lists (CRLs) are used to check the revocation status of an X509 certificate. A CRL is a digitally signed list of revoked certificates that have been issued by a CA. The CRL is published and made available to any entity via a publicly accessible URI. The CRL MUST be digitally signed by the CRL issuer.
CRLs MAY be used for the following types of certificates:
Wallet Relying Party Access Certificates by including the
cRLDistributionPointsextension in the certificate, as described in Wallet-Relying Party Access Certificate (WRPAC) Profile.Sign/Seal Certificates by including the
cRLDistributionPointsextension in the certificate, as described in Entity Sign/Seal Certificate Profile.
If a CRL is used to manage the status of the certificates, the CRL issuer MUST be the entity referenced in the Trust Anchor certificate subject field.
The CRL issuer MAY also generate delta CRLs. A delta CRL only lists those certificates, within its scope, whose revocation status has changed since the issuance of a referenced complete CRL. The referenced complete CRL is referred to as a base CRL. The scope of a delta CRL MUST be the same as the base CRL that it references.
If supported by the CA, the CRL MUST be available at the URI specified in the cRLDistributionPoints.distributionPoint [0] CHOICE structure within the Wallet Relying Party Access Certificate (WRPAC).
An X.509 v2 CRL is represented as the ASN.1 DER encoding of the CertificateList SEQUENCE.
The ASN.1 DER encoding is a strictly defined tag, length, and value encoding system for each element.
The final bytes transmitted represent the DER encoding of the top-level SEQUENCE containing the fields in the following table:
Parameter |
Description |
Reference |
|---|---|---|
|
REQUIRED. SEQUENCE. Contains the core CRL information including the name of the issuer, issue date, next update date, the optional list of revoked certificates, and optional CRL extensions. |
RFC 5280, clause 5.1.1.1 |
|
REQUIRED. SEQUENCE. Contains the algorithm identifier for the algorithm used by the CRL issuer to sign the |
RFC 5280, clause 5.1.1.2 |
|
REQUIRED. OBJECT IDENTIFIER. The OID of the signature algorithm. |
[RFC 5280, clause 4.1.1.2] |
|
OPTIONAL. ANY. Algorithm-specific parameters, dependent on the signature algorithm used. |
[RFC 5280, clause 4.1.1.2] |
|
REQUIRED. BIT STRING. Contains the digital signature computed upon the ASN.1 DER encoded |
[RFC 5280, clause 5.1.1.3] |
5.7.3.1.1. Certificate List Content¶
The tbsCertList (To Be Signed Certificate List) is an ASN.1 SEQUENCE containing several fields and extensions.
The following table lists all such fields and extensions that are required in a CRL or conditionally required.
Parameter |
Description |
Reference |
|---|---|---|
|
OPTIONAL. INTEGER. Describes the version of the encoded CRL.
When extensions are used (as is standard practice), this field MUST be present and MUST specify version 2 (the integer value is |
[RFC 5280, clause 5.1.2.1] |
|
REQUIRED. SEQUENCE. The algorithm identifier for the algorithm used to sign the CRL. |
[RFC 5280, clause 5.1.2.2] |
|
REQUIRED. OBJECT IDENTIFIER. The OID of the signature algorithm.
MUST match the |
[RFC 5280, clause 4.1.1.2] |
|
OPTIONAL. ANY. Algorithm-specific parameters, dependent on the algorithm used. |
[RFC 5280, clause 4.1.1.2] |
|
REQUIRED. Name. Identifies the entity that has signed and issued the CRL.
It MUST contain a non-empty X.500 distinguished name (DN) composed of |
[RFC 5280, clause 5.1.2.3] |
|
REQUIRED. UTCTime or GeneralizedTime. Indicates the issue date of this CRL.
Dates through 2049 MUST use |
[RFC 5280, clause 5.1.2.4] |
|
REQUIRED. UTCTime or GeneralizedTime. Indicates the date by which the next CRL will be issued.
Dates through 2049 MUST use |
[RFC 5280, clause 5.1.2.5] |
|
OPTIONAL. SEQUENCE OF. A sequence of revoked certificates. When there are no revoked certificates, this field MUST be absent. |
[RFC 5280, clause 5.1.2.6] |
|
REQUIRED. INTEGER. The |
[RFC 5280, clause 5.1.2.6] |
|
REQUIRED. UTCTime or GeneralizedTime. The date on which the revocation occurred. |
[RFC 5280, clause 5.1.2.6] |
|
OPTIONAL. SEQUENCE OF. Extensions specific to this revoked certificate entry.
If present, the CRL |
[RFC 5280, clause 5.1.2.6] |
|
OPTIONAL. [0] EXPLICIT SEQUENCE OF. A sequence of one or more CRL extensions.
If present, the CRL |
[RFC 5280, clause 5.1.2.7] |
The crlExtensions field MAY contain various extensions.
Notable standard extensions include:
Parameter |
Description |
Reference |
|---|---|---|
|
REQUIRED. SEQUENCE. Provides a means of identifying the public key corresponding to the private key used to sign the CRL.
Contains |
RFC 5280, clause 5.2.1 |
|
REQUIRED. INTEGER. A non-critical extension conveying a monotonically increasing sequence number for a given CRL scope and issuer. Both base CRLs and delta CRLs share the same monotonically increasing sequence. The delta CRL's number MUST be greater than the base CRL's number it references. |
RFC 5280, clause 5.2.3 |
|
REQUIRED for delta CRLs.
It MUST NOT appear in base CRLs.
INTEGER ( |
RFC 5280, clause 5.2.4 |
|
OPTIONAL; RECOMMENDED on base CRLs in deployments that issue delta CRLs. SEQUENCE OF DistributionPointName. A non-critical extension indicating where the most recently issued delta CRL for the same scope can be retrieved.
Each |
RFC 5280, clause 5.2.6 |
|
OPTIONAL; REQUIRED when the CRL scope is restricted (e.g., only-CA, only-end-entity, only-some-reasons) or when the CRL is indirect. SEQUENCE ( |
RFC 5280, clause 5.2.5 |
5.7.3.2. Online Certificate Status Protocol (OCSP)¶
The Online Certificate Status Protocol (OCSP) (RFC 6960) enables applications to determine the exact revocation state of identified certificates. It provides more timely revocation information than is typically possible with CRLs and MAY also be used to obtain additional status information.
An OCSP client issues a status request to an OCSP responder and MUST suspend the acceptance of the certificates in question until the responder provides a valid response.
If supported by the Certificate Authority, the URI to which the OCSP Responder can be invoked MUST be present in the authorityInfoAccess.accessLocation extension of the Wallet Relying Party Access Certificate (WRPAC).
This protocol specifies the data that MUST be exchanged between the OCSP client (which checks the status of one or more certificates) and the OCSP server (which provides the corresponding status).
The following table sums up the roles of the OCSP client and server in the EUDIW ecosystem.
OCSP Client |
OCSP Server |
Use case |
|---|---|---|
Wallet Unit |
WRPAC Provider |
WRPAC Status Check |
Wallet Unit or Relying Party |
PID Provider Trust Anchor |
PID Sign/Seal Certificate Status Check |
Wallet Unit or Relying Party |
PuB-EAA Provider Trust Anchor |
PuB-EAA Sign/Seal Certificate Status Check |
Wallet Unit or Relying Party |
(Q)EAA Provider Trust Anchor |
(Q)EAA Sign/Seal Certificate Status Check |
Note
The Status check on Sign/Seal Certificates is needed only in case the Sign/Seal Certificate is not referenced directly as a Trust Anchor Certificate, in which case it is trusted a priori and does not need a separate status check.
5.7.3.2.1. Online Certificate Status Protocol Request Format¶
The OCSP request MUST be the ASN.1 DER encoding of the OCSPRequest SEQUENCE, which contains the tbsRequest (To-Be-Signed Request) and an optional signature.
The following table lists the parameters found within the tbsRequest structure.
Parameter |
Description |
Reference |
|---|---|---|
|
OPTIONAL. [0] EXPLICIT INTEGER. Indicates the version of the protocol.
If omitted, the default value is |
[RFC 6960, clause 4.1.1] |
|
REQUIRED. SEQUENCE OF. Contains one or more single certificate status requests. |
[RFC 6960, clause 4.1.1] |
|
REQUIRED. SEQUENCE. The |
[RFC 6960, clause 4.1.1] |
|
OPTIONAL. [0] EXPLICIT SEQUENCE. Includes extensions applicable to this single certificate status request. |
[RFC 6960, clause 4.1.1] |
|
OPTIONAL. [2] EXPLICIT SEQUENCE. Includes extensions applicable to the overall requests found within the |
[RFC 6960, clause 4.1.1] |
The reqCert parameter utilizes the CertID structure, MUST be an ASN.1 SEQUENCE containing the following parameters:
Parameter |
Description |
Reference |
|---|---|---|
|
REQUIRED. SEQUENCE. Identifies the hash algorithm used to generate the issuer name and key hashes. |
[RFC 6960, clause 4.1.1] |
|
REQUIRED. OBJECT IDENTIFIER. The OID of the hash function (e.g., SHA-256, depending on the profile). |
[RFC 6960, clause 4.1.1] |
|
OPTIONAL. ANY. Algorithm-specific parameters, dependent on the hash algorithm used. |
[RFC 6960, clause 4.1.1] |
|
REQUIRED. OCTET STRING. The hash of the issuer's distinguished name (DN), calculated over the DER encoding of the issuer's name field. |
[RFC 6960, clause 4.1.1] |
|
REQUIRED. OCTET STRING. The hash of the issuer's public key, calculated over the value (excluding tag and length) of the subject public key field. |
[RFC 6960, clause 4.1.1] |
|
REQUIRED. INTEGER. The serial number of the target certificate for which the status is being requested. |
[RFC 6960, clause 4.1.1] |
The requestExtensions and singleRequestExtensions structures MAY contain various extensions.
The following table lists the requested ones:
Parameter |
Description |
Reference |
|---|---|---|
|
REQUIRED. OCTET STRING. Cryptographically fresh value used to bind a request and a response to prevent replay attacks.
Identifier OID is |
[RFC 6960, clause 4.4.1] |
When sent over HTTP using POST, the body of this request MUST contain the raw DER encoding of this OCSPRequest SEQUENCE. The body of this request MUST have MIME type application/ocsp-request.
Below is a non-normative example of an OCSP request:
OCSPRequest request = {
tbsRequest: {
version: 0, // integer value 0 for v1 (RFC 6960 default)
requestList: [
Request {
reqCert: CertID {
hashAlgorithm: AlgorithmIdentifier {
oid: "2.16.840.1.101.3.4.2.1", // sha256
params: NULL
},
issuerNameHash: "HEX(SHA256(DER(IssuerName)))",
issuerKeyHash: "HEX(SHA256(Issuer SubjectPublicKey BIT STRING))",
serialNumber: "0x01A2B3C4D5"
}
}
],
requestExtensions: [
Extension {
oid: "1.3.6.1.5.5.7.48.1.2", // id-pkix-ocsp-nonce
critical: false,
value: OCTET STRING("BASE64(RANDOM_NONCE_BYTES)")
}
]
}
}
5.7.3.2.2. Online Certificate Status Protocol Response Format¶
An OCSP response MUST be the ASN.1 DER encoding of the OCSPResponse SEQUENCE.
When transported over HTTP, the body of the HTTP response MUST contain the raw DER encoding of this OCSPResponse, with the MIME type application/ocsp-response.
The OCSPResponse SEQUENCE contains the following parameters:
Parameter |
Description |
Reference |
|---|---|---|
|
REQUIRED. ENUMERATED. Indicates the processing status of the prior request.
Supported values are: |
[RFC 6960, clause 4.2.1] |
|
OPTIONAL. [0] EXPLICIT SEQUENCE. Present only when the |
[RFC 6960, clause 4.2.1] |
|
REQUIRED. OBJECT IDENTIFIER. Identifier for the response type.
For a basic OCSP responder, this value MUST be |
[RFC 6960, clause 4.2.1] |
|
REQUIRED. OCTET STRING. Contains the DER encoding of the response syntax identified by |
[RFC 6960, clause 4.2.1] |
Note
OCSP responders MUST be capable of producing responses of the id-pkix-ocsp-basic response type.
Correspondingly, OCSP clients MUST be capable of receiving and processing responses of the id-pkix-ocsp-basic response type.
BasicOCSPResponse is an ASN.1 SEQUENCE containing the following parameters:
Parameter |
Description |
Reference |
|---|---|---|
|
REQUIRED. SEQUENCE. Contains the core response data to be signed by the responder. |
[RFC 6960, clause 4.2.1] |
|
OPTIONAL. [0] EXPLICIT INTEGER. The version of the response syntax.
If omitted, the default value is |
[RFC 6960, clause 4.2.1] |
|
REQUIRED. CHOICE. Identifies the OCSP responder.
It MUST contain either |
[RFC 6960, clause 4.2.1] |
|
OPTIONAL. [1] EXPLICIT Name. The |
[RFC 6960, clause 4.2.1] |
|
OPTIONAL. [2] EXPLICIT OCTET STRING. The SHA-1 hash of the responder’s |
[RFC 6960, clause 4.2.1] |
|
REQUIRED. GeneralizedTime. The time at which the OCSP response was generated. |
[RFC 6960, clause 4.2.1] |
|
REQUIRED. SEQUENCE OF. A sequence of |
[RFC 6960, clause 4.2.1] |
|
OPTIONAL. [1] EXPLICIT SEQUENCE OF. Contains extensions applicable to the overall OCSP response. |
[RFC 6960, clause 4.2.1] |
|
REQUIRED. SEQUENCE. Identifies the cryptographic algorithm used to sign the response. |
[RFC 5280, clause 4.1.1.2] |
|
REQUIRED. OBJECT IDENTIFIER. The OID of the signature algorithm. Selection SHOULD align with relevant standards (e.g., [ETSI TS 119 312]). |
[RFC 5280, clause 4.1.1.2] |
|
OPTIONAL. ANY. Algorithm-specific parameters, dependent on the OID defined in |
[RFC 5280, clause 4.1.1.2] |
|
REQUIRED. BIT STRING. The digital signature computed over the hash of the DER-encoded |
[RFC 6960, clause 4.2.1] |
|
OPTIONAL. [0] EXPLICIT SEQUENCE OF. Certificate chain to help the client verify the responder's signature. If no certificates are included, this field SHOULD be absent. |
[RFC 6960, clause 4.2.1] |
The responseExtensions structure MAY contain various extensions.
The following table lists the requested ones:
Parameter |
Description |
Reference |
|---|---|---|
|
REQUIRED. OCTET STRING. Cryptographically fresh value used to bind a request and a response to prevent replay attacks.
If included in the request, responders SHOULD include it in the response.
Identifier OID is |
[RFC 6960, clause 4.4.1] |
In the OCSP Response there MUST be at least a SingleResponse for each CertID in the request.
Each SingleResponse is an ASN.1 SEQUENCE that carries the following parameters:
Parameter |
Description |
Reference |
|---|---|---|
|
REQUIRED. SEQUENCE. Identifier of the certificate whose status is determined in |
[RFC 6960, clause 4.2.1] |
|
REQUIRED. CHOICE. The value of the certificate's status.
It MUST be exactly one of: |
[RFC 6960, clause 4.2.1] |
|
OPTIONAL. [0] IMPLICIT NULL. Indicates the certificate is valid. |
[RFC 6960, clause 4.2.1] |
|
OPTIONAL. [1] IMPLICIT SEQUENCE. Indicates the certificate has been revoked.
Contains the |
[RFC 6960, clause 4.2.1] |
|
REQUIRED. GeneralizedTime. The time at which the certificate was revoked. |
[RFC 6960, clause 4.2.1] |
|
OPTIONAL. [0] EXPLICIT ENUMERATED. Contains the |
[RFC 6960, clause 4.2.1] |
|
OPTIONAL. [2] IMPLICIT NULL. Indicates the responder does not know the status of the certificate. |
[RFC 6960, clause 4.2.1] |
|
REQUIRED. GeneralizedTime. Indicates the issue date and time of this OCSP Response. |
[RFC 6960, clause 4.2.1] |
|
OPTIONAL. [0] EXPLICIT GeneralizedTime. Indicates the date and time by which the next update to the OCSP Responder database will be in place. |
[RFC 6960, clause 4.2.1] |
|
OPTIONAL. [1] EXPLICIT SEQUENCE. Includes extensions applicable to this single certificate status response. |
[RFC 6960, clause 4.2.1] |
Below is a non-normative example of an OCSP response with a single good status.
OCSPResponse response = {
responseStatus: "successful", // 0 = successful
responseBytes: ResponseBytes {
responseType: "1.3.6.1.5.5.7.48.1.1", // id-pkix-ocsp-basic
response: BasicOCSPResponse {
tbsResponseData: ResponseData {
version: 0, // integer value 0 for v1 (RFC 6960 default)
responderID: ResponderID {
byName: DistinguishedName {
commonName: "Example OCSP Responder",
organizationName: "Example CA",
countryName: "IT"
}
},
producedAt: "2025-01-01T00:00:00Z",
responses: [
SingleResponse {
certID: CertID {
hashAlgorithm: AlgorithmIdentifier {
oid: "1.3.14.3.2.26", // sha1
params: NULL
},
issuerNameHash: "HEX(SHA256(DER(IssuerName)))",
issuerKeyHash: "HEX(SHA256(Issuer SubjectPublicKey BIT STRING))",
serialNumber: "0x01A2B3C4D5"
},
certStatus: "good",
thisUpdate: "2025-01-01T00:00:00Z",
nextUpdate: "2025-01-02T00:00:00Z",
singleExtensions: [] // absent
}
],
responseExtensions: [
Extension {
oid: "1.3.6.1.5.5.7.48.1.2", // id-pkix-ocsp-nonce
critical: false,
value: OCTET STRING("BASE64(RANDOM_NONCE_BYTES)")
}
]
},
signatureAlgorithm: AlgorithmIdentifier {
oid: "1.2.840.113549.1.1.11", // sha256WithRSAEncryption
params: NULL
},
signatureValue: "BASE64(SIGN(responderPrivateKey, DER(tbsResponseData)))",
certs: [
"BASE64(RESPONDER_CERT_DER)",
"BASE64(RESPONDER_ISSUING_CA_CERT_DER)"
]
}
}
}
5.7.3.3. Token Status List (WRPRC Profile)¶
This section profiles the Token Status List (TSL) mechanism of TOKEN-STATUS-LIST for Wallet-Relying Party Registration Certificates (WRPRCs). A TSL conveys the current status of many WRPRCs in a compact, signed Status List Token (SLT).
The SLT Provider MAY be the Provider of WRPRC or a designated entity.
5.7.3.3.1. Token Status List (WRPRC Profile): Status List¶
A Status List contains a compressed byte array whose entries represent the statuses of many WRPRCs. The Provider of WRPRC MUST allocate a distinct, non-negative idx value to each issued WRPRC and include it, together with the SLT uri, in the WRPRC's status.status_list member. For a JWT-encoded WRPRC, idx is a JSON integer and uri is a JSON string.
For a CWT-encoded WRPRC, idx is a CBOR unsigned integer and uri is a CBOR text string. In both cases, uri MUST be a URI conforming to RFC 3986.
According to the ARF and [ETSI TS 119 475], the WRPRC status is either VALID or INVALID.
The Provider of WRPRC MUST set the bits parameter in the SLT's status_list object to 1. The value 0x00 represents VALID, and 0x01 represents INVALID.
Packing of entries, DEFLATE compression, the ZLIB data format, and publication of the Status List are specified in Token Status List (Digital Credentials Profile).
5.7.3.3.2. Token Status List (WRPRC Profile): Status List Token¶
The SLT Provider MUST act as both the Status Issuer and the Status Provider.
The SLT Provider MUST publish each SLT by HTTP GET at the URI in the WRPRC member status.status_list.uri.
Media types, the JWT or CWT format, and signature protection are specified in Token Status List (Digital Credentials Profile).
Regardless of the format, the SLT Provider for WRPRCs MUST sign each SLT using a valid X.509 certificate whose trust chain terminates at the Trust Anchor published in the Providers of WRPRC LoTE.
For a JWT SLT, the signing certificate chain MUST be carried in the x5c JOSE header.
For a CWT SLT, it MUST be carried in the x5chain COSE header (label 33).