title: "European Digital Identity Wallet" subtitle: "ARF Annex 3.01 - PID Rulebook" ...

Attestation Rulebook for attestations of type Personal Identification Data (PID)

• Authors

  • Jonas Toennis , Brønnøysund Registry Center

• Previous authors

  • David Bakker, On behalf of the ARF working group

Feedback and contact

Main feedback channel: GitHub issues Alternative: Contact Work Package 4 in WE BUILD.

1 Introduction

1.1 Document scope and purpose

This document is the natural person identification data (PID) Rulebook and is part of the Architecture Reference Framework (ARF). It specifies how the mandatory and optional person identification data for the natural person, as defined in Tables 1 and 2 in the Annex of the Commission Implementing Regulation on PID and EAA [CIR 2024/2977], as well as the metadata specified in Table 5 of that CIR, will be encoded within the EUDI Wallet ecosystem. Additionally, this document specifies further optional PID attributes that are not included in the CIR.

This document also specifies how a PID and all attributes in it are encoded if the PID complies with [ISO/IEC 18013-5] and if it complies with [SD-JWT VC].

This PID Rulebook should be read in conjunction with the high-level requirements for PIDs in Topic 3 in Annex 2 of the Architecture Reference Framework. In particular, the values to be used for the namespace and document type for [ISO/IEC 18013-5]-compliant PIDs and for the vct claim in [SD-JWT VC]-compliant PIDs are defined in Topic 3.

Person identification data for the legal person is out of scope of this document.

1.2 Document structure

This PID Rulebook is structured as follows:

• Chapter 2 describes the PID attributes and metadata on a generic level, regardless of the encoding used for the PID. Most of the content of this chapter is a direct copy of the Annex of Commission Implementing Regulation 2024/2977 on PID and EAA. However, a few additional attributes are specified in this chapter.
• Chapter 3 specifies how the PID attributes and metadata are encoded in case the PID complies with [ISO/IEC 18013-5] or [SD-JWT VC]
• Chapter 4 specifies how PIDs are issued and used.
• Chapter 5 discusses mechanisms for the provision of trust anchors that shall be used for the verification of PIDs.
• Chapter 6 discusses how PIDs can be revoked, and how Relying Parties can perform revocation checking.
• Chapter 7 states how this PID Rulebook complies with the general EUDI framework, the ARF, and relevant Regulations.
• Chapter 8 lists references to relevant documents.

1.3 Keywords

This document uses the capitalised keywords 'SHALL', 'SHOULD' and 'MAY' as specified in [RFC 2119], i.e. to indicate requirements, recommendations and options specified in this document.

In addition, 'must' (non-capitalised) is used to indicate an external constraint, i.e. a requirement that is not mandated by this document, but, for instance, by an external document. The word 'can' indicates a capability, whereas other words, such as 'will', and 'is' or 'are' are intended as statements of fact.

1.4 Terminology

This document uses the terminology specified in Annex 1 of the ARF.

1.5 Deviations from the ARF 2.8.0 defined PID version 1.5 for WE BUILD

1. The attribute and metadata tables of chapter two have been extended with links to the semantic vocabulary of WE BUILD.
2. The structure of this rulebook follows the EUDI template version 1.1. The ARF PID rulebook is diverging from this version.
3. WE BUILD specifies an explicit token-list-based status mapping for SD-JWT in line with Architecture Decision Record for WE BUILD on the topic
4. Chapter 4, Chapter 5 and Chapter 6 have been expanded compared out over the ARF 2.8.0 PID version 1.5

2 PID attributes and metadata

2.1 Introduction

Sections 2.2, 2.3, 2.4, 2.5 and 2.6 of this chapter list the mandatory and optional PID attributes and PID metadata defined in CIR 2024/2977. Section 2.7 lists the optional PID attributes additionally defined in this PID Rulebook.

Note that, when requesting PID attributes from a Wallet Unit, a Relying Party is not required to request all mandatory attributes. Also, a user is allowed to refuse to present a mandatory attribute, if it is requested by a Relying Party.

The data identifiers and definitions given in Sections 2.2, 2.3, 2.4, and 2.5 are identical to those in CIR 2024/2977, except where explicitly indicated that some further explanations have been added in this Rulebook.

All data identifiers and definitions in this chapter are independent of any encoding used. Consequently,

• the data identifiers in these tables are not necessarily the same as the attribute identifiers used for PIDs complying with [ISO/IEC 18013-5]. Chapter 3.1 specifies the attribute identifiers to be used for PIDs in [ISO/IEC 18013-5] format
• the data identifiers in these tables are not necessarily the same as the claim names used for PIDs complying with [SD-JWT VC]. Section 3.2 specifies the claim names to be used for such PIDs.

2.2 Mandatory attributes specified in CIR 2024/2977

2.3 Optional attributes specified in CIR 2024/2977

2.4 Condition Attributes

The PID defined in this rulebook does not contain any condition attributes.

2.5 Mandatory metadata specified in CIR 2024/2977

2.6 Optional metadata specified in CIR 2024/2977

2.7 Additional optional attributes specified in this Rulebook

3 Attestation encoding

3.1 ISO/IEC 18013-5-compliant encoding

3.1.1 Document type and namespace

As specified in Topic 3 in Annex 2 of the ARF, "eu.europa.ec.eudi.pid.1" will be used as the attestation type for ISO/IEC 18013-5-compliant PIDs.

Similarly, "eu.europa.ec.eudi.pid.1" will be used for the namespace of the attributes specified below.

3.1.2 Attributes overview

The ISO/IEC 18013-5-compliant encoding of PID attributes and metadata is specified in the table below. The table contains the following information for all attributes:

• The first column lists the data identifier specified in Chapter 2 above.
• The second column lists the corresponding attribute identifier to be used in presentation requests and responses according to [ISO/IEC 18013-5].
• The third column indicates the encoding of each attribute. This column uses CDDL representation types defined in [RFC 8610]. The following notes and requirements apply:
  • tstr, uint, bstr, bool and tdate are CDDL representation types defined in [RFC 8610].
  • Regarding type tstr: this document confirms that, as specified in RFC 8949, a tstr SHALL be encoded in UTF-8 and SHALL support the full Unicode range.
  • All attributes having encoding type tstr SHALL have a maximum length of 150 characters.
  • This document specifies full-date as full-date = #6.1004(tstr), where tag 1004 is specified in [RFC 8943].
  • In accordance with [RFC 8949], section 3.4.1, a tdate attribute SHALL contain a date-time string as specified in [RFC 3339]. In accordance with [RFC 8943], a full-date attribute SHALL contain a full-date string as specified in [RFC 3339].
  • The following requirements apply to the representation of dates in attributes, unless otherwise indicated:
    • Fractions of seconds SHALL NOT be used;
    • A local offset from UTC SHALL NOT be used; the time-offset defined in [RFC 3339] SHALL be to "Z".
  • RFC 8949, section 4.2, describes four rules for canonical CBOR. Three of those rules SHALL be implemented for all CBOR structures in PIDs, as follows:
    • integers (major types 0 and 1) SHALL be as small as possible;
    • the expression of the length in a bstr, tstr, array or map SHALL be as short as possible;
    • indefinite-length items SHALL be made into definite-length items.

Note that the presence of each attribute (mandatory or optional) is already specified in Chapter 2 above.

3.1.3 Attribute nationality

The attribute nationality is encoded as a type nationalities, i.e., an array of Alpha-2 country codes as specified in ISO 3166-1. Using CDDL notation as specified in RFC 8610, the encoding of this attribute is:

nationalities = [+ CountryCode]

CountryCode = tstr ; Alpha-2 country code specified in ISO 3166-1

Note: If the user to whom the person identification data relates has multiple nationalities (and the PID Provider is willing to attest to these multiple nationalities), the PID Provider can include all of the nationalities in the nationalities array. A potential drawback of this solution is that the user cannot selectively disclose only one of these nationalities, since for ISO/IEC 18013-5-compliant attestations, always the entire array will be presented if the user approves the presentation of the nationality attribute. A potential solution to this challenge is for the PID Provider to include only one nationality in the nationality attribute, and for the remaining nationalities use one or more domestic data attributes specified according to requirement PID_06 in Annex 2, Topic 3.

3.1.4 Attribute location_status

For ISO/IEC 18013-5-compliant PIDs, the attribute location_status is absent, since the PID issuer will add revocation information, if needed, to the MSO as specified in [ISO/IEC 18013-5].

3.1.5 Attribute birth_date

For PIDs compliant with ISO/IEC 18013-5, dates are encoded as specified in RFC 8949 (which references RFC 3339). This encoding does not contain provisions for encoding partial dates. This may cause challenges in case the birth date of a user is not (fully) known. To deal with such cases, a PID Provider could adopt a policy to choose appropriate (and RFC 3339-compliant) values for the unknown date elements. However, mandating such a policy is out of scope of this document.

3.1.6 Attribute place_of_birth

The attribute place_of_birth is encoded as a type place_of_birth. Using CDDL notation as specified in RFC 8610, the encoding of this attribute is:

place_of_birth =
{
  ? "country": tstr  ; a single alpha-2 country code as specified in ISO 3166-1
  ? "region": tstr   ; the name of a state, province, district, or local area
  ? "locality": tstr ; the name of a municipality, city, town, or village
}

place_of_birth SHALL contain at least one of the following key-value pairs: "country", "region", or "locality".

3.2 SD-JWT VC-based encoding of PID

3.2.1 Overview

Following requirement ARB_06b, SD-JWT VC-encoded PIDs use claim names that are either registered in the JSON Web Token Claims Registry [IANA-JWT-Claims], are Public Names as defined in [RFC 7519], or are Private Names specific to the attestation type. The tables below map the data identifiers defined above to the corresponding claim names and specify the encoding format of the claim value.

A JSON string used in an SD-JWT VC-encoded PID SHALL be encoded in UTF-8, and SHALL support the full Unicode range, unless explicitly specified otherwise in the tables below or the references therein.

Note that a hierarchical claim name structure can be used in SD-JWT VC encoded PIDs as SD-JWT allows for individual selective disclosure of objects and their properties. A hierarchical claim name structure is indicated by the notation parent.child in the tables below.

The following IANA registered claim names are to be used for PIDs:

Note: The standard JWT claims nbf and exp are used to express the technical validity period of a SD-JWT VC-compliant PID.

The following Private Names specific to the attestation type defined in this document are to be used for PIDs:

3.2.2 Attribute status

For SD-JWT VC-compliant PIDs, the PID MUST include a status claim if the technical validity period is greater than 25 hours. This claim enables Relying Parties to determine if a credential has been revoked via a status list mechanism, as specified in [SD-JWT VC].

The status claim SHALL be a JSON object with the following members:

• type (string): SHALL be "status-list".
• status_list_credential (string, URI): The URI of the Status List Credential document that contains the status bitstring.
• status_list_index (integer, >= 0): The zero-based index into the status list bitstring that corresponds to this credential.
• status_purpose (string): SHALL be "revocation" for this PID.

Example:

{
  "status": {
    "type": "status-list",
    "status_list_credential": "https://issuer.example.com/status/1",
    "status_list_index": 42,
    "status_purpose": "revocation"
  }
}

3.2.3 Note on VCT

SD-JWT VC defines the Verifiable Credential Type (vct). A type comes with associated metadata that, for instance, provides information about the type itself, outlines a schema detailing the claims that are optional or mandatory in the SD-JWT VC, and specifies their display methods. Additionally, a type can extend another type, enabling the creation of domestic types based on a common EU-wide type, while preserving the mandatory claims from the base type. Domestic types MAY however define additional claims and display information. Details are defined in [SD-JWT VC].

Requirement PID_14 in ARF Annex 2 defines the base type to be "urn:eudi:pid:1". As a convention, all PIDs must use types in the namespace "urn:eudi:pid:".

SD-JWT VC specifies Type Metadata as a machine-readable format for information regarding a type, including the information on claims such as what is contained in this document. Requirement PID_15 in Annex 2, Topic 3 requires that the information on the common EU-wide type as well as on any domestic types is published and accessible in a catalog.

3.3 Example

EXAMPLE: The following example shows the payload of a PID in SD-JWT VC format before the encoding into the SD-JWT format.

{
    "vct": "urn:eudi:pid:de:1",
    "attestation_legal_category": "PUB-EAA",

    "given_name": "Jean",
    "family_name": "Dupont",
    "birthdate": "1980-05-23",

    "address": {
        "street_address": "123 Via Appia",
        "locality": "Rome",
        "region": "Lazio",
        "postal_code": "00100",
        "country": "IT"
    },

    "nationalities": ["FR"],

    "sex": 5,

    "place_of_birth": {
        "country": "DD"
    },

    "cnf": {
        "jwk": {
            "kty": "EC",
            "crv": "P-256",
            "x": "52aDI_ur05n1f_p3jiYGUU82oKZr3m4LsAErM536crQ",
            "y": "ckhZ-KQ5aXNL91R8Eufg1aOf8Z5pZJnIvuCzNGfdnzo"
        }
    },

    "issuing_authority": "DE",
    "issuing_country": "DE",

    "status": {
        "type": "status-list",
        "status_list_credential": "https://issuer.example.com/status/1",
        "status_list_index": 42,
        "status_purpose": "revocation"
    }
}

Note: The cnf claim is used for expressing key binding in SD-JWT VCs. The example above shows a public key in JWK format.

Note: Additional technical claims are not shown here, including references to the issuer and more.

4 PID usage

4.1 Use-case context

PID is used to identify a natural person (user) in national and cross-border digital services within the EUDI Wallet ecosystem.

Primary use cases:

• Proving the identity of a natural person (user) to a Relying Party(RP) in online services.
• Supporting regulated or high-trust onboarding and access control flows where identification is required.
• Supporting attribute verification (e.g., residency, age) subject to data minimisation and proportionality.

Issuance requirements and expectations:

• PID Providers SHALL issue PID only after identity verification according to the applicable Member State PID issuance framework.
• PID Providers SHALL bind PID to the Wallet Unit key material as defined in Chapter 3 (e.g., cnf for SD-JWT VC).
• PID Providers SHALL set technical validity (exp, and nbf if present) and SHALL provide status/revocation capability as defined in Chapter 6.
• For SD-JWT VC PIDs, the PID SHALL include a status claim when required by Section 3.2.2 (technical validity period > 25 hours).

Expected user behaviours:

• The user SHOULD approve PID presentation only when the Wallet Unit shows the RP identity, intended use, and a privacy policy reference.
• The user SHOULD approve presentation only when the requested attributes are necessary for the transaction.
• Preferably, the user SHOULD either approve all requested attributes or deny the request. If the user does not want to disclose a requested attribute, the user SHOULD deny the request and allow the RP to send a revised request (see Section 2.1).
• Where selective disclosure is supported by the format, the user SHOULD disclose only the minimum attributes required by the transaction.

Relying Party (RP) behaviours:

• The RP SHALL be registered as a Wallet RP and SHALL request only attributes justified for the intended use.
• The RP SHALL authenticate to the Wallet Unit (e.g., using its access certificate chain) in the applicable presentation protocol.
• The RP SHOULD include (or enable retrieval of) the registered intended use information and privacy policy reference so the Wallet Unit can inform the user.
• The RP SHALL verify the PID signature according to Chapter 3 and SHALL validate issuer trust and authorisation using applicable trust anchors (Chapter 5).
• The RP SHALL validate technical validity (check exp, and nbf if present) and SHALL apply revocation/status checks as defined in Chapter 6.
• The RP MAY verify device binding / proof of possession where supported. If the RP requests cryptographic holder binding in the presentation protocol, it SHALL NOT accept a non-device-bound PID.

Presentation requirements:

• The RP SHOULD request only the minimum attributes needed for the transaction (data minimisation).
• The RP SHALL NOT rely on non-unique contact attributes (e.g., email_address) as unique identifiers, as already stated in Chapter 3.

Transactional data:

• The RP MAY keep minimal logs necessary to demonstrate verification events and security-relevant auditability (e.g., timestamps, verification outcome, issuer identifier, status-check result).
• The RP SHOULD avoid storing full PID payloads unless required by law or strictly necessary for dispute handling.

5 Trust anchors

This chapter specifies how trust anchors relevant to PID are distributed and looked up. Two trust relationships are in scope:

• PID authenticity - the RP verifies the PID signature.
• RP authenticity - the Wallet Unit authenticates the RP before presenting PID attributes.

For PID and QEAAs, trust anchors of the Provider are obtained from a List of Trusted Entities (LoTE) or Trusted List. For PuB-EAAs, the RP uses the QTSP Trusted List to validate the certificate chain of the PuB-EAA Provider certificate. The applicable rulebook specifies the mechanisms enabling trust anchor distribution and lookup for non-qualified cases.

Trust anchor distribution:

• PID Provider trust anchors SHALL be distributed via LoTE following the PID Provider registration and notification process, where applicable.
• Qualified trust anchors (QTSP trust anchors) SHALL be obtained via eIDAS Trusted Lists (and their corresponding publication mechanisms).
• Access Certificate Authority trust anchors (used for RP authentication towards the Wallet Unit) SHALL be distributed via LoTE.
• PID Providers SHOULD populate the optional PID metadata trust_anchor (Section 2.6) with at least one machine-readable pointer to the applicable trust anchor source (LoTE entry, Trusted List, or an index pointing to the authoritative source).

Trust anchor lookup mechanisms:

• RPs and Wallet Units SHALL support trust anchor lookup based on:
  • issuing_country (Section 2.5) for selecting the relevant national LoTE / Trusted List context, and
  • the optional trust_anchor metadata (Section 2.6) as a machine-readable pointer when present.
• RPs and Wallet Units SHOULD cache trust anchor artefacts and apply an update policy appropriate for the deployment, including re-fetching when a pointer changes or when cached artefacts expire.

Verification steps - RP verifies PID authenticity:

1. Determine the legal category of the PID using attestation_legal_category (Section 2.5).
2. Verify the PID signature according to Chapter 3.
3. Obtain the relevant trust anchor(s):
   • For PID or QEAA, obtain the Provider trust anchor from the applicable LoTE / Trusted List.
   • For PuB-EAA, validate the PuB-EAA Provider certificate chain up to the QTSP trust anchor from the QTSP Trusted List.
   • For non-qualified EAA cases, obtain the applicable domain trust anchor using the mechanism defined below (WE BUILD profile).
4. Validate the trust chain (including intermediate certificates where used) and validate revocation/status information as specified in Chapter 6.
5. Where a trust anchor source is retrieved dynamically, validate the authenticity and integrity of the retrieved artefact before use (for example, using a signed LoTE/Trusted List artefact or an authenticated distribution channel).

Verification steps - Wallet Unit authenticates the RP (precondition for PID presentation):

1. Obtain the trust anchor of the Access Certificate Authority from the applicable LoTE.
2. Validate the RP access certificate chain included in the presentation request up to the Access CA trust anchor.
3. Validate revocation/status of certificates in the chain as required by the applicable ecosystem rules and Chapter 6.
4. Proceed to user approval only after successful RP authentication.

WE BUILD specific profile and extensions:

• WE BUILD SHALL support a machine-readable LoTE endpoint (or equivalent distribution mechanism) that contains:
  • trust anchors for PID Providers participating in WE BUILD, and
  • trust anchors for the Access Certificate Authorities used by WE BUILD participants.
• The WE BUILD LoTE SHOULD be structured so that entries can be resolved by issuing_country and entity identifier, and SHOULD support inclusion of pointers to authoritative national LoTE / Trusted List sources where available.
• Wallet Units and RPs in WE BUILD SHALL be able to resolve trust anchors using either:
  • the trust_anchor metadata carried in the PID, or
  • a pre-configured WE BUILD LoTE entry point based on issuing_country.

Practical examples (illustrative):

• Example 1 - PID includes trust_anchor pointing to a LoTE entry:
  • trust_anchor: https://lote.example.org/XX/pid-providers.json
  • RP retrieves the LoTE artefact, selects the PID Provider entry, and uses the contained trust anchor to validate the PID Provider signing chain.
• Example 2 - Wallet Unit authenticates an RP:
  • Wallet Unit retrieves the Access CA trust anchor for issuing_country = "XX" from LoTE.
  • RP includes its access certificate and intermediate certificates in the request.
  • Wallet Unit validates the chain up to the Access CA trust anchor before showing the request to the user.

For information regarding the use of the trust list in WE BUILD, please consult the Architecture Blueprint

6 Revocation

PIDs MAY be either (a) short-lived and non-revocable, or (b) long-lived and revocable, in line with ARF Annex 2 Topic 7.

Revocation strategy:

• A PID Provider SHALL use one of the following approaches:
  • Issue short-lived PIDs with a technical validity period of 24 hours or less; or
  • Support revocation using an Attestation Status List (ASL) or Attestation Revocation List (ARL) mechanism.
• If a PID is revocable, the PID Provider SHALL be the only party responsible for executing revocation of that PID, and SHALL NOT reverse revocation once executed.
• The PID Provider MAY support temporary suspension before permanent revocation, with a maximum suspension period defined in the revocation policy.
• The PID Provider SHALL maintain a revocation policy specifying under which conditions it revokes a PID (e.g. compromise, attribute changes, explicit user request, death of the subject), notification procedures for users, and user rights including the right to request revocation at any time.

Technical mechanisms:

• For SD-JWT VC-based PIDs, revocation is expressed via the status claim (see Section 3.2.2) using the status-list mechanism.
• For ISO/IEC 18013-5-compliant PIDs, revocation information is provided via the MSO as defined in ISO/IEC 18013-5; no location_status attribute is used (see Section 3.1.3).

Relying Party (RP) checks:

• A RP Instance SHOULD verify revocation status when the PID is revocable, and SHALL perform a risk analysis if it decides not to.
• Relying Parties SHOULD NOT fetch status information at presentation time. Instead, they SHOULD periodically retrieve and cache the relevant ASL/ARL and distribute it to their RP Instances.
• If reliable revocation information is unavailable or indeterminate, the RP SHALL decide whether to accept or refuse the PID based on its risk analysis. The RP SHALL log such incidents and MAY report recurring failures to the PID Provider.
• Revocation status checking SHALL be designed to prevent correlation of user identity across Relying Parties (e.g., using batch status lists rather than per-credential status endpoints).

Timing:

• Where revocation is supported, the PID Provider SHOULD ensure that revocation is reflected in published status information within 24 hours of the revocation decision.
• For emergency revocations (e.g., security compromise), the PID Provider SHOULD propagate revocation within a shorter timeframe where technically feasible.

7 Compliance

This PID Rulebook complies with all applicable requirements in Topic 12 (Attestation Rulebooks) in Annex 2 of the Architecture Reference Framework. It also complies with the template for Attestation Rulebooks.

The attributes specified in this Rulebook comply with CIR 2024/2977.

Further requirements in this Rulebook comply with or reference the applicable requirements in the ARF and the relevant Implementing Acts.

8 References

For further references please see ARF Chapter 10 of the ARF main document.