EAASD-JWT VCmdoc

Attestation Rulebook for attestations of type Tax ID

Category: non-qualified EAA

This rulebook is derived from the generic WE BUILD attestation rulebook template, version 1.0 with 11 chapters and profiles the Tax Identification Number (TaxID) attestation description for natural persons within the WE BUILD Large-Scale Pilot (LSP).

This is a working document that holds no legal value and does not reflect any common agreement or position of the co-legislators or of the WE BUILD consortium. It presents a state-of-play of ongoing work and should not be considered final.

Author(s):

• [Sevastianos Chatzistergos, Greek Ministry of Digital Governance
• Uwe Pfizenmaier, IDnow]

Previous Authors:

• [Sevastianos Chatzistergos, Greek Ministry of Digital Governance (0.1, 0.2, 0.3, 0.4)
• Uwe Pfizenmaier, IDnow (0.2., 0.3, 0.4)]

Feedback: [s.chatzistergos@mindigital.gr; uwe.pfizenmaier@idnow.io]

Open Issues Register

The following open issues are flagged inline throughout this document and are collected here for visibility:

ID	Section	Description
OI-01	§§ 2.1, 3.1, 3.2	Namespace and attestation type eu.europa.ec.eudi.taxid.1 is proposed; pending WE BUILD consortium confirmation.
OI-02	§§ 2.2, 3.1, 3.2	birth_date is encoded as tdate (datetime) in the source description. ARF PID convention uses full-date (date only). Resolution required before finalisation.
OI-03	§ 2.5	issuing_authority definition is dual-use: either a name string or an ISO 3166-1 Alpha-2 code. This creates schema ambiguity; a single, unambiguous definition is needed.
OI-04	§ 2.3	church_tax_ID is a jurisdiction-specific attribute (primarily Germany). Consortium should decide whether to retain as a general optional attribute or restrict to a jurisdiction-specific extension namespace.
OI-05	§ 3.3	W3C VCDM encoding not yet defined. Rulebook author to complete before finalisation.
OI-06	§§ 3.1, 3.2	Illustrative encoding examples (mDoc fragment, SD-JWT token) not yet provided. Rulebook author to complete.
OI-07	§ 2.7, § 5	trust_anchor_location resolution protocol (HTTP semantics, expected response format/profile) is referenced but not yet normatively specified; depends on a forthcoming Commission technical specification for non-qualified EAA trust anchors.

Written against: ARF version 3.0.0, WE BUILD template version 1.0 (generic)

Feedback: GitHub issues

1 Introduction

1.1 Document scope and purpose

This rulebook defines functional, semantic, and technical requirements for a Tax Identification Number (TaxID) attestation for natural persons within the WE BUILD Large-Scale Pilot (LSP) and the EUDI Wallet ecosystem.

What the attestation expresses: The TaxID attestation provides structured, verifiable evidence of a natural person's tax identification number within a national tax system, bound to their identity. It enables relying parties to verify the official and unique tax identification of an individual within and across EU member states.

Scope assumption: Each attestation is associated with a single Tax ID number. Where a natural person holds multiple Tax IDs (e.g. in multiple jurisdictions), each is represented by a separate attestation.

Issuers, holders, and relying parties:

• Issuers: Primarily National Tax Authorities (the actual issuers of tax identification numbers). The role of authentic source may also be assumed by other government agencies (e.g. social security or public service agencies) that hold Tax ID information, or by third-party services authorised by governments to verify and validate Tax IDs. In countries where no authentic source is capable of providing the information via interoperability, a QTSP may issue a TaxID QEAA after receiving a relevant physical or electronic document providing the required proof.
• Holders: Natural persons to whom a Tax ID has been assigned under national law.
• Relying parties: Any entity that requires verification of a natural person's tax identification, including obliged entities performing Customer Due Diligence (CDD), financial institutions, public administrations, and other service providers.

Primary use cases:

1. Verification of a natural person's tax identity in the context of financial services (e.g. account opening, investment services).
2. Cross-border identification of individuals for tax reporting and information exchange within and across EU member states.
3. Reuse of verified Tax ID data in digital onboarding workflows where a tax number is required.

Source material: This rulebook is derived from the TaxID attestation description (WE BUILD LSP, v0.1, 17-02-2026). Where not explicitly amended or extended here, the provisions of that source description remain applicable.

1.2 Document structure

This Rulebook follows the generic WE BUILD attestation rulebook template. Chapter 2 states how it complies with the ARF and the applicable Regulations. Chapters 3 and 4 define the attributes and metadata in an encoding-independent manner. Chapter 5 states the formats in which this attestation is issued. Chapters 6 to 9 cover protocols, issuance, revocation and presentation. Chapter 10 sets out the trust framework, and chapter 11 lists references.

1.3 Key words

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

In addition, 'must' (non-capitalised) indicates an external constraint, a requirement not mandated by this document but by an external document. The word 'can' indicates a capability. Other words such as 'will', 'is' and 'are' are statements of fact.

1.4 Terminology

This document uses the terminology specified in Annex 1 of the ARF and in the WE BUILD LSP documentation. Key terms:

• Tax Identification Number (Tax ID / TaxID): A unique identifier assigned to a natural person by a national tax authority or equivalent body for purposes of tax administration and identification.
• National Tax Authority: The governmental body in a Member State responsible for issuing and administering Tax IDs (e.g. Bundeszentralamt für Steuern in Germany, Direction Générale des Finances Publiques in France).
• Authentic source: An authoritative repository or system holding Tax ID information, which may serve as the data source for TaxID attestation issuance.

2 Compliance

2.1 Compliance statement

This Rulebook complies with the applicable requirements of Topic 12, Attestation Rulebooks, in Annex 2 of the Architecture and Reference Framework, version 3.0.0. It uses the terminology of Annex 1 of the ARF.

This rulebook addresses compliance with the High-Level Requirements of [Topic 12] of Annex 2 of the ARF. The table below maps each relevant ARB requirement to its coverage in this rulebook.

2.2 Regulatory basis

This attestation is not a qualified electronic attestation of attributes. The data described in Annex V points b, c and e of Regulation (EU) 2024/1183 is addressed as required by EW-DM-12-018 and as recommended by EW-DM-12-020 and EW-DM-12-022. Where a recommendation is not followed, the reason is stated below.

2.3 Traceability

Every applicable requirement mapped to the section that satisfies it. Requirements marked not applicable carry a stated reason.

3 Attestation attributes

Attributes are defined here in an encoding-independent manner (EW-DM-12-007). The encoding of each attribute is given in chapter 5.

3.1 Introduction

The TaxID attestation is designed to enable relying parties to verify a natural person's tax identity in a machine-readable, privacy-preserving manner. It is used together with, or independently from, a PID attestation, depending on the relying party's requirements.

The TaxID attestation may be issued as a QEAA, PuB-EAA, or non-qualified EAA, depending on the issuing authority and Member State governance framework. This rulebook defines the mandatory metadata attribute attestation_legal_category (§ 2.5), which SHALL have the value "QEAA", "PuB-EAA", or "non-qualified-EAA" as appropriate.

OI-01, OPEN ISSUE (Namespace): The attestation namespace and type identifier is proposed as eu.europa.ec.eudi.taxid.1. This identifier is used throughout this rulebook but is pending confirmation by the WE BUILD consortium before this rulebook can be considered final.

All tstr / string attributes SHALL have a maximum length of 150 characters unless otherwise stated.

Chapter overview and requirements

This chapter defines all attributes and metadata that a TaxID attestation MAY contain, in an encoding-independent manner. Each attribute is classified as mandatory, optional, or conditional. Abstract data types are used; format-specific encoding details are provided in Chapter 3.

Structure: The TaxID attestation is a single flat object, no nested or composite attribute structures are defined.

Requirements applicable to TaxID as a QEAA:

• An indication that the attestation has been issued as a QEAA SHALL be included (ARB_11, Annex V point a of [European Digital Identity Regulation]).
• Attributes or metadata representing issuer identity and country SHALL be included (ARB_13, Annex V point b).
• Attributes representing subject identity SHALL be included (ARB_16, Annex V point c).
• Validity period metadata SHALL be included (ARB_18, Annex V point e).
• Trust anchor location SHALL be indicated (ARB_20, Annex V point h).

Requirements applicable to TaxID as a PuB-EAA or non-qualified EAA follow the corresponding provisions of Annex VII and ARB_12–ARB_21 of [Topic 12] respectively.

3.2 Mandatory attributes

NOTE: If an attribute is indicated as mandatory, this solely means that the Issuer SHALL ensure that the element is present in the attestation. It does not imply that a Relying Party is required to request it, nor that the User cannot refuse to disclose it.

OI-02, OPEN ISSUE (birth_date encoding): The source TaxID description specifies birth_date with encoding type tdate, which is a CDDL datetime type. ARF PID convention uses full-date (date only, tag 1004), which is more appropriate for a date of birth. The WE BUILD consortium and rulebook author SHOULD resolve this discrepancy and align to full-date for consistency with ARF PID. Until resolved, implementers SHOULD use full-date in conformance with ARF PID conventions. This rulebook adopts full-date as the normative encoding in § 3.

3.3 Optional attributes

OI-04, OPEN ISSUE (church_tax_ID scope): church_tax_ID is primarily a Germany-specific attribute. The consortium SHOULD decide whether to retain it as a general optional attribute in the common namespace, or relocate it to a jurisdiction-specific domestic namespace (e.g. eu.europa.ec.eudi.taxid.de.1). Until resolved, it is retained here as optional.

3.4 Conditional attributes

The following attribute is conditional: it SHALL be present when the TaxID attestation is device-bound and cryptographically linked to another attestation on the same Wallet Unit (see § 4.4 and ARB_28 of [Topic 12]). It SHALL be omitted when the attestation is not device-bound.

4 Metadata

Metadata describes the attestation rather than its subject.

4.1 Mandatory metadata

OI-03, OPEN ISSUE (issuing_authority definition): The current definition is dual-use: either a human-readable name string, or an ISO 3166-1 Alpha-2 country code. This creates schema ambiguity (the field could contain either "Bundeszentralamt für Steuern" or "DE"). A single, unambiguous definition is needed, either always a name, or always a code, or split into two distinct fields. The rulebook author SHOULD resolve this before finalisation and update the attribute definition and code list (§ 2.8) accordingly.

Legal category. This Rulebook retains the attestation_legal_category attribute. Section 4.1 of the generic template replaces it with the category attribute of [ETSI TS 119 472-1], whose value for this category is eaa:eu:non-qualified. EW-DM-12-029, legacy ARB_25, of ARF version 3.0.0 is a SHALL that still requires attestation_legal_category, so the template and the ARF disagree. The attribute is left as written and the deviation is recorded for the rulebook quality assurance group.

4.2 Optional metadata

4.3 Conditional metadata

The following metadata attribute is conditional on the attestation's legal category (see § 2.5 attestation_legal_category and Chapter 5 Trust anchors).

OI-07, OPEN ISSUE (trust_anchor_location resolution): This rulebook defines the attribute that carries the trust anchor location, but the resolution protocol (e.g. HTTPS GET semantics, expected response content-type, and the machine-readable trust anchor format/profile) is not yet normatively specified. This depends on a forthcoming Commission technical specification for non-qualified EAA trust anchors. See § 5 for the interim resolution model.

4.4 Code lists

4.5 Integrity rules

5 Formats

5.1 SD-JWT VC-based encoding

The TaxID attestation SHALL be issued in SD-JWT VC-compliant format in conformance with the SD-JWT VCs profile specified in [HAIP] (ARB_01b of [Topic 12]). Selective Disclosure SHALL be used.

OI-01 (reminder): The vct value below is proposed and pending consortium confirmation.

Verifiable Credential Type (vct): eu.europa.ec.eudi.taxid.1

General encoding rules:

• JSON attributes SHALL be encoded as specified in [RFC 8259].
• Date-only values (birth_date) SHALL be encoded as a JSON string in ISO 8601 / [RFC 3339] full-date format (e.g. "1988-08-25").
• Datetime values (issuance_date, expiry_date) SHALL be encoded as a JSON string in [RFC 3339] date-time format with UTC offset "Z" (e.g. "2025-03-01T10:00:00Z").
• All string attributes SHALL have a maximum length of 150 characters.
• The TaxID attestation is a flat object, no nested SD-JWT recursive disclosures are required. Each top-level claim is individually selectively disclosable according to the table below.
• Non-disclosable claims (marked MUST NOT) SHALL be included as plain JSON in the JWT payload, not wrapped in SD-JWT disclosure structures. This ensures that metadata cannot be hidden from verifiers.

Disclosability rationale for non-disclosable claims: attestation_legal_category, issuance_date, issuing_authority, issuing_country, and cryptographically_bound_to are attestation integrity and provenance metadata. Hiding them would prevent verifiers from establishing the legal status, currency, and provenance of the attestation, which are prerequisites for valid verification. They are therefore not selectively disclosable.

IANA-registered / well-known claims:

Private claim names specific to TaxID attestation type:

OI-06 (reminder): The following examples SHALL be completed by the rulebook author before finalisation.

[RULEBOOK AUTHOR TO PROVIDE AN EXAMPLE OF THE JWT CLAIM SET USED BY THE PROVIDER]

[RULEBOOK AUTHOR TO PROVIDE AN EXAMPLE OF THE ISSUED SD-JWT (IN base64url ENCODING)]

[RULEBOOK AUTHOR TO PROVIDE A HUMAN-READABLE VERSION OF THE SD-JWT PAYLOAD AND A DESCRIPTION OF THE DISCLOSURES INCLUDED IN THE EXAMPLE]

5.2 ISO/IEC 18013-5-compliant encoding

The TaxID attestation MAY be issued in ISO/IEC 18013-5-compliant mdoc format where proximity presentation (without internet) is required by the deployment context. Issuers and Member States SHALL determine, in accordance with ARB_02 of [Topic 12], whether proximity presentation is a required capability for their deployment of the TaxID attestation.

OI-01 (reminder): The document type below is proposed and pending consortium confirmation.

Document type: eu.europa.ec.eudi.taxid.1

General encoding rules:

• tstr, uint, bstr, bool, tdate, and full-date are CDDL representation types defined in [RFC 8610].
• A tstr SHALL be encoded in UTF-8 (as specified in [RFC 8949]) and SHALL support the full Unicode range.
• All tstr attributes SHALL have a maximum length of 150 characters.
• full-date is encoded as full-date = #6.1004(tstr), where tag 1004 is specified in [RFC 8943]. In accordance with [RFC 8943], a full-date attribute SHALL contain a full-date string as specified in [RFC 3339].
• tdate is used for datetime values (issuance_date, expiry_date). In accordance with [RFC 8949] section 3.4.1, a tdate attribute SHALL contain a date-time string as specified in [RFC 3339]. Fractions of seconds SHALL NOT be used; the time-offset SHALL be "Z".
• birth_date encoding: Per OI-02, this rulebook adopts full-date for birth_date (date only), overriding the source description's tdate. Implementers SHALL use full-date for birth_date.
• Canonical CBOR rules per [RFC 8949] section 4.2 SHALL apply: integers SHALL be as small as possible; lengths SHALL be as short as possible; indefinite-length items SHALL be definite-length.

Attribute encoding table:

OI-06, OPEN ISSUE: A full or partial mDoc illustrative example SHALL be provided here before finalisation. [RULEBOOK AUTHOR TO PROVIDE AN EXAMPLE OF FULL OR PARTIAL mDOC OF THE ATTESTATION AND THE ATTRIBUTES AND THEIR VALUES]

5.3 W3C Verifiable Credentials Data Model-based encoding

The TaxID attestation MAY be issued in W3C VCDM v2.0-compliant format. Note that, per ARB_01a of [Topic 12], only a non-qualified EAA can use this format.

OI-05, OPEN ISSUE: W3C VCDM encoding is not yet defined for this attestation type. [RULEBOOK AUTHOR TO PROVIDE HUMAN-READABLE EXAMPLE OF THE ISSUED ATTESTATION IN W3C VCDM FORMAT AND AN EXAMPLE OF THE PROOF TYPE]

Tables analogous to those in § 3.2 SHALL be defined, referencing documents approved by an EU standardisation body or the European Digital Identity Cooperation Group as required by ARB_04 of [Topic 12].

6 Protocols

This attestation is issued using OpenID for Verifiable Credential Issuance [OpenID4VCI] and presented using OpenID for Verifiable Presentations [OpenID4VP], both as profiled by [HAIP].

7 Issuance

7.1 Binding

7.2 Issuance Policy

7.3 Lifecycle management

The issuer sets the validity period of the attestation and reissues it when the underlying facts change, revoking the superseded attestation as described in chapter 8.

7.4 Embedded disclosure policy

This attestation defines no embedded disclosure policy.

8 Revocation

Per [Topic 7] of Annex 2 of the ARF:

In the current WE BUILD LSP deployment, revocation is out of scope. Wallet instances and TaxID attestations are assumed not to be revoked during the pilot. Future deployments targeting production or cross-border use SHOULD define a revocation mechanism in conformance with one of the following methods (as applicable at the time of that deployment):

• An Attestation Status List mechanism included in a Technical Specification specified by the Commission.
• An Attestation Revocation List mechanism included in a Technical Specification specified by the Commission.

Where the TaxID attestation has a short validity period (24 hours or less), revocation is not required.

Note: The presence of an optional expiry_date attribute enables time-limited issuance, which reduces the need for active revocation. Issuers SHOULD set an appropriate expiry_date that reflects the expected validity of the tax identification data and the renewal cycle of the issuing authority.

9 Presentation

9.1 Presentation Policy

To verify and validate a received presentation of an attestation of this type, the following steps SHALL be performed:

1. verify the signature over the attestation using a trust anchor obtained as described in chapter 10;
2. verify that the attestation is within its validity period;
3. check revocation status as described in chapter 8, unless the attestation is short-lived, or its remaining lifetime is below the revocation time threshold;
4. verify device binding where section 7.1 records the attestation as device-bound;
5. request only those attributes that are necessary for the stated purpose of the transaction, and, where the trust model for this attestation requires Relying Party registration, only those attributes it is registered and authorised to request.

Obligations specific to this attestation type, carried over from the previous version of this Rulebook:

• Relying parties SHALL request and verify a PID attestation alongside the TaxID attestation (see ARB_27 of [Topic 12]). Where the TaxID attestation is cryptographically bound to a PID on the same Wallet Unit (§ 4.4), the PID SHALL always be requested and verified together with the TaxID to establish the natural person's full identity context; the PID is used to identify and verify the natural person customer (e.g. name, date and place of birth), while the TaxID attestation verifies the tax identification number itself.
• Relying parties SHALL verify the attestation signature and check that issuance_date is in the past and, where present, that expiry_date has not been exceeded.
• Relying parties SHALL NOT request iban unless it is strictly necessary for the specific transaction and lawful under applicable data protection rules.
• Relying parties SHALL ensure that tax_number is used only for the stated tax-identification purpose and is not repurposed as a general identifier.
• Relying parties are responsible for determining whether the issuer constitutes an acceptable and sufficiently reliable source for their specific use case, taking into account their risk-based approach and applicable legal requirements.
• TaxID attestation attributes SHALL be released only in a VP Token, as specified in [OpenID4VP].

9.2 Presentation modes

Remote presentation is in scope. Proximity presentation is in scope only where chapter 5 records an mdoc encoding.

9.3 Transactional data

This Rulebook defines no transactional data.

No transactional data requirements are defined for this attestation type at this time. [See Topic 20 of Annex 2 of the ARF for High-Level Requirements related to strong user authentication for electronic payments.]

9.4 Primary use cases

1. Financial services onboarding: Verification of a natural person's tax identification in the context of account opening, investment services, or other regulated financial services where a Tax ID is required.
2. Cross-border tax information exchange: Identification of individuals for tax reporting and information exchange across EU member states, in support of DAC (Directive on Administrative Cooperation) or FATCA-equivalent processes.
3. Digital onboarding: Reuse of a verified TaxID attestation in workflows that require a tax number, avoiding re-verification at each service provider.

9.5 Presentation requirements

• Selective Disclosure SHALL be used for the TaxID attestation (ARF section 5.3).
• The TaxID attestation is designed primarily for remote (online) presentation. Proximity presentation (offline) is not required by default but MAY be supported by mdoc-capable issuers where Member State governance frameworks require it.
• Relying parties SHOULD request only the minimum set of attributes necessary for the transaction (data minimisation principle).

9.6 Device binding

The TaxID attestation SHOULD be device-bound to the EUDI Wallet Unit of the holder (ARB_34 of [Topic 12]). Where device binding is applied and cryptographic binding to the PID is required, the conditional attribute cryptographically_bound_to (defined in § 2.4) SHALL be present and SHALL be set to:

• "eu.europa.ec.eudi.pid.1" for ISO/IEC 18013-5 (mdoc) attestations; or
• "urn:eudi:pid:1" for SD-JWT VC attestations.

Where the TaxID attestation is not device-bound, the cryptographically_bound_to attribute SHALL be omitted.

10 Trust Framework

For QEAA and PuB-EAA TaxID attestations, relying parties SHALL obtain the trust anchor from the applicable EU Trusted List, in conformance with ARB_20 of [Topic 12] and the ARF. Issuers MAY use an intermediate signing certificate, with the trust anchor signing the intermediate certificate. For these legal categories, the conditional attribute trust_anchor_location (§ 2.7) SHALL be omitted; the EU Trusted List is the sole normative trust anchor mechanism.

For non-qualified EAA TaxID attestations, the location of the machine-readable trust anchor SHALL be indicated via the trust_anchor_location attestation metadata attribute (§ 2.7), in conformance with ARB_21 of [Topic 12]. Relying parties SHALL use this location to retrieve and verify the trust anchor.

Resolution model for trust_anchor_location (interim): Until a Commission technical specification for non-qualified EAA trust anchors is finalised, relying parties SHOULD resolve trust_anchor_location as follows:

1. Perform an HTTPS GET request against the URL given in trust_anchor_location.
2. Expect a machine-readable response (profile to be confirmed, candidates include a JWK Set per [RFC 7517] or an X.509 certificate bundle).
3. Validate that the resolved trust anchor corresponds to the key or certificate used to sign the attestation before accepting it as trusted.

This interim model is provisional (see OI-07) and SHALL be superseded once the Commission specification referenced by ARB_21 is published.

WE BUILD LSP context (current): In the current WE BUILD Large-Scale Pilot (LSP) deployment, a formal trusted issuer list mechanism is out of scope. Participating TaxID Attestation Providers and Relying Parties are assumed to be familiar with the TaxID attestation guideline and with the list of participating issuers. Where a TaxID attestation is issued as a non-qualified EAA within the LSP, trust_anchor_location SHOULD still be populated to enable forward compatibility with the resolution model above, even though resolution is not currently enforced by pilot participants.

Production / cross-border deployments (future): Future versions of this rulebook MUST replace the above with a concrete trust anchor mechanism aligned with:

• The EU Trusted List framework established pursuant to [2015/1505];
• ARF Chapter 6.2 and [HLR] Topic 31 part H (trusted list of issuers);
• The technical specifications for trust anchor distribution defined by the European Digital Identity Cooperation Group, including the final resolution protocol for trust_anchor_location (OI-07).

Signing (issuer signing attestation, verifier signing request) SHALL be implemented in conformance with applicable technical specifications. Specific cryptographic algorithms and elliptic curves SHALL be determined in accordance with those specifications once finalised. Holder/device binding SHALL conform to the applicable SD-JWT VC or mdoc specification.

Trust anchor location

The attribute or metadata carrying the trust anchor location contains at least the URL at which a machine-readable version can be found or looked up.

11 References