QEAAPuB-EAA

Attestation Rulebook for attestations of type Tax Residence Certificate

Category: QEAA / PuB-EAA

• Author(s):
  • Pasi Sinervo Finnish Tax Administration
  • Sierd Westerfield, Dutch Tax Administration

Feedback: * mail the author * Create Pull Request

1 Introduction

1.1 Document scope and purpose

The electronic tax residence certificate (etrc) attestation is an official document issued by a Tax Administration, that verifies the country in which the taxable person is resident for tax purposes. This attestation serves as a proof of the company’s, administrative unit’s or natural paerson's tax liability towards different jurisdictions on tax issues: unlimited or limited tax liability. It contains only information directly related to the etrc. This model is based on the Council directive 2025/50 on faster and safer relief of excess withholdinh taxes.

The etrc attestation can be utilized by a company to substantiate its identity and ownership of the provided etrc. The recipient of the attestation can trust its authenticity, eliminating the need for external verification if such a process is available.

One of the most important use cases is taxation of the investment revenues from other countries. In order to tax the income correctly the receiver of the income must present the etrc to the payer, the custodian or the tax administration in a refund application. The Council directive 2025/50 seeks to improve this use of the etrc.

The etrc attestation improves other processes including opening a bank account (We Build PA1 and PA3) and opening an account of a merchant in a platform (BU1).

The etrc attestation seeks to replace the traditional paper-based proof with an attestation. The etrc Attestation is expected to enhance both the efficiency and security of the process.

1.2 Document structure

Chapter 2 states how this Rulebook complies with the applicable regulatory and architectural requirements. Chapter 3 specifies the attestation attributes and chapter 4 the metadata, both in an encoding-independent manner, each referencing the machine-readable schema artefacts that define their encoding. Chapter 5 lists the attestation formats supported. Chapter 6 lists the issuance and presentation protocols supported. Chapter 7 specifies issuance, including binding and lifecycle management. Chapter 8 specifies revocation. Chapter 9 specifies presentation. Chapter 10 specifies the trust framework, including how trust anchors are obtained. Chapter 11 lists references. Chapters 5 and 6 identify formats and protocols only. The substantive rules for issuance and presentation are in chapters 7 and 9 respectively, and are not repeated in chapters 5 and 6.

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, that is, a requirement mandated by an external document rather than by this 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.

2 Compliance

This chapter states how this Rulebook complies with the Architecture and Reference Framework and with the applicable Regulations. Sections 2.1 and 2.2 follow from the legal category of this attestation. Section 2.3 maps each applicable requirement to the section that satisfies it.

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 [ARF VERSION]. It uses the terminology of Annex 1 of the ARF.

2.2 Regulatory basis

The regulatory basis below is the one applicable to the legal category of this attestation.

QEAA

This attestation includes the data required by Annex V of Regulation (EU) 2024/1183, points a, b, c, e and h, satisfying EW-DM-12-014, EW-DM-12-016, EW-DM-12-019, EW-DM-12-021 and EW-DM-12-023 respectively. It is issued by a qualified trust service provider.

PuB-EAA This attestation includes the data required by Annex VII of Regulation (EU)

2024/1183, points a, b, c, e and h, satisfying EW-DM-12-014, EW-DM-12-017, EW-DM-12-019, EW-DM-12-021 and EW-DM-12-023 respectively. It is issued by or on behalf of a public sector body responsible for an authentic source.

2.3 Traceability

Every applicable requirement mapped to the section that satisfies it. Mark a requirement not applicable only with a stated reason. No blank rows at submission.

3 Attestation attributes

Attributes are defined here in an encoding-independent manner (EW-DM-12-007). The authoritative encoding lives in the machine-readable schema artefacts referenced in section 3.1, not in this document. Do not paste schema fragments into the prose, they will drift.

3.1 Introduction

The etrc attestation is an attestation provided by an authentic source such as a TAX-Administration. The attestation proves how a taxable person should be taxed in the jurisdiction of the registration and of the RP. It indicates whether the taxable person has unlimiten or limited tax liability in the jurisdiction of the RP. The etrc attestation only contains information directly related to the etrc.

*According to Annex V point a) and Annex VII point a) of the [European Digital Identity Regulation] an indication, at least in a form suitable for automated processing, that the attestation has been issued as a QEAA or Pub-EAA SHALL be defined. Similarly, according to ARB_12 of [Topic 12] of Annex 2 of the ARF a similar indication SHOULD be defined for non-qualified EAA.

This document defines the attribute "etrc" which SHALL have the value "QEAA" or "PuB-EAA".*

etrc
├─ reference_number                        [1]       (Number of the document)
├─ entity                                  [1]       (entity that owns the etrc)
│   ├─ name                                [1]    
│   ├─ tax_identification_number           [1]       (tax identification number)
│   └─ tax_identification_number_type      [1]       
├─ natural person                          [1]       (person that owns the etrc)
│   ├─ family_name                         [1]       
│   ├─ given_name                          [1]       
│   ├─ date_of_birth                       [1]       
│   ├─ tax_identification_number           [1]              
│   └─ tax_identification_number_type      [1]       
├─ validity_period                         [1]       (period for which the etrc is valid)
│   ├─ start_date                          [1]       (start date of the validity period of the etrc)
│   ├─ end_date                            [1]       (end date of the validity period of the etrc)
│   ├─ validity_period_type                [1]       (calendar or fiscal year)
│   └─ remark                              [1]       (legal remark)
├─ issuer                                  [1]          
│   ├─ issuing_country                     [1]        
│   ├─ issuing_organisation                [1]        (tax authority)
│   ├─ issuing_date                        [1]        (date on which the attestation is issued)
│   └─ attestation_issuing_organisation    [1]
├─ treaty                                  [1]          
│   ├─ tax_treaty_name                     [1]        (tax treaty name)
│   ├─ tax_treaty_reference                [1]        (article of the treaty)
│   ├─ applicable_member_state             [1]        (jurisdiction of the RP)
│   └─ remark                              [1]
└─ address                                 [0]          
    ├─ po_box                              [0]        
    ├─ thoroughfare                        [0]        
    ├─ location_designator                 [0]       
    ├─ post_code                           [0]       
    ├─ post_name                           [0]       
    ├─ admin_unit_L1                       [0]              
    └─ admin_unit_L2                       [0]       

Schema artefacts.

3.2 Mandatory attributes

3.3 Mandatory Entity attributes

3.4 Validity Period

3.5 Relevant Double Tax Treaty

3.6 Person

3.7 Address optional

3.8 Mandatory metadata

3.8.1 Mandatory metadata

3.8.2 Optional metadata

2.8 Integrity rules

4 Metadata

Metadata describes the attestation rather than its subject. Use the same schema artefacts referenced in section 3.1.

4.1 Mandatory metadata

Includes the category attribute for all categories except PID.

3 Attestation encoding

3.1 ISO/IEC 18013-5-compliant encoding

If the attestation type supports the the format specified in ISO/IEC 18013-5, then in this section the ISO/IEC 18013-5-compliant encoding of attributes and metadata should be defined.

It is noted that (see ARB_02 in [Topic 12]) the Schema Provider SHALL analyse whether it must be possible for a User to present that type of attestation when the Wallet Unit and the Relying Party are in proximity and attestations are presented without using the internet. If so,the attestations must be issued in the ISO/IEC 18013-5-compliant mdoc format.

Furthermore, in this section a document type SHALL be defined, which SHALL be unique within the scope of the EUDI Wallet ecosystem (see ARB_05 in [Topic 12]).

[RULEBOOK AUTHOR TO DEFINE THE ATTESTATION TYPE]

Provide a list of available encoding formats and their specifications (e.g., encoding, maximum lengths, date formats, etc). For example:

• 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, 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.

This section should include a table the data identifier specified in Chapter 2, the corresponding attribute identifier to be used in presentation requests and responses according to [ISO/IEC 18013-5] and the encoding of each attribute.

Additionally, the following rules should be followed:

• When specifying new attributes, existing conventions for attribute identifier values and attribute syntaxes SHOULD be considered (see ARB_07 in [Topic 12]).
• Each attribute SHALL be defined within an attribute namespace.
  • An attribute namespace SHALL fully define the identifier, the syntax, and the semantics of each attribute within that namespace.
  • An attribute namespace SHALL have an identifier that is unique within the scope of the EUDI Wallet ecosystem, and each attribute identifier SHALL be unique within that namespace (see ARB_06a in [Topic 12])
  • A domestic namespace MAY defined to specify attributes that are specific to this Rulebook and are not included in the applicable EU-wide or sectoral namespace (see ARB_10 in [Topic 12]).

The corresponding entry for the "attestation_legal_category" attribute defined in Section 2.1 SHALL be:

Finally, illustrative examples SHALL be included.

[RULEBOOK AUTHOR TO PROVIDE AN EXAMPLE OF FULL OR PARTIAL mDOC OF THE ATTESTATION]

[RULEBOOK AUTHOR TO PROVIDE THE ATTRIBUTES AND THEIR VALUES INCLUDED IN THE EXAMPLE]

3.2 SD-JWT VC-based encoding

3.2.1 Attribute Encoding Table

Notes:

• MUST: The claim SHALL be selectively disclosable — the holder MAY choose to disclose or withhold this claim when presenting the credential to a Relying Party.
• MUST NOT: The claim SHALL NOT be selectively disclosable — it is always present in plain text in the JWT header/payload and cannot be withheld by the holder, as it is required for credential verification and trust establishment.
• iat and exp follow RFC 7519 standard JWT claim naming conventions.

3.2.2 Status Claim

For SD-JWT VC-compliant Ownership attestations, the attestation MUST include a status claim if the technical validity period is greater than 24 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 attestation.

Example:

{
  "status": {
 "type": "status-list",
 "status_list_credential": "https://issuer.example.com/status/ownership/2025",
 "status_list_index": 456,
 "status_purpose": "revocation"
  }
}

3.3 W3C Verifiable Credentials Data Model-based encoding

If the attestation type supports the the format specified in W3C Verifiable Credentials Data Model, then in this section the corresponding encoding of attributes and metadata should be defined.

It is noted that only a a non-qualified EAA can use this format (see ARB_01a in [Topic 12])

Tables similar to the ones specified in section 4 SHALL be defined.

This section SHALL reference one or more documents specifying in detail how a Relying Party can request attributes from a such an attestation, and how a User can selectively disclose attributes from such an attestation. Moreover, these referenced documents SHALL be approved by an EU standardisation body or by the European Digital Identity Cooperation Group established pursuant to Article 46e(1) of the [European Digital Identity Regulation] (see ARB_04 in [Topic 12]).

Finally, illustrative examples SHALL be included.

[RULEBOOK AUTHOR TO PROVIDE HUMAN READABLE EXAMPLE OF THE ISSUED ATTESTATION]

[RULEBOOK AUTHOR TO PROVIDE AN EXAMPLE OF THE PROOF TYPE]

4 Attestation usage

4.1 Usecases

The etrc attestion aims to be used in two general usecases, but it could be used elsewhere. The first usecae is where the relying party requires proof that the taxable person is resident for tax issues in some country. This helps the RP to determine whether this taxable person has unlimited or limited tax responsibility in the country of RP. In the 'paper' world, the relying party would request a 'Tax Residence or Tax Domicile Certificate' relyably issued by the relevant Tax Authority, and in some cases notarized and shared through Apostille. The taxable person requests the Certificate, and it will be sent to the registered address of the taxable person or downloaded from a portal. The Certificate is printed on paper (or pdf) of the Tax Authority and or contains stamps, signature or other ways to proof its validity. If required, the certificate is notarized before sharing to the RP.

The second usecase is where a taxable person wants to open an account in a bank. The bank needs for its' KYC procedure a proof of the taxable person's residency for taxation: use cases We Build PA1 and PA3.

4.2 Issuing requirements

The etrc attestation may only be issued to the wallet of the organisation that holds the etrc, or to the wallet of an Agent (natural or legal person) that can prove that he is allowed to act upon the holder for this service. The attestation should be considered private. In order to issue the etrc attestation to the Economic Operator itself the issuing party SHOULD: Verify the identity of the Economic Opereator and issue the etrc attestation to the wallet of that Economic Operator.

If an agent wishes to receive the attestation of another economic operator, the issuing party SHOULD: * Check the identity of the Agent - check if the agent has a mandate with the right scope and actors - the mandate is not revoked - the mandate is currenty valid

4.3 Verification needs

The etrc provides a proof that the Economic Operator or natural person, registered in the attestation, is the owner of the etrc. It does not prove that the party that presents the attestation also is the owner of the attestation. The etrc attestion can also be issued to an Agent ( Intermediary party including financial institutions or custodians), if they have the right mandate to receive the attestation. However the mandate may be revoked by the owner, but the etrc attestation will (likely) not be revoked. Therefore the attestation itself (even if holderbinding is active) is not proof that the presenter actually holds, or may present the attestation.

The relying party SHOULD: - Check the status of revocation and expiary date of the attestation. - Check the validy period in the attestation.

• Check if the Economic Operator in the Attestation is:
• equal to the owner of the EBW (via EBWOID, PID, or other means) OR
• has a mandate with the right scope and actors
  • the mandate is not revoked
  • the mandate is currenty valid

If the relying party does not perform all verification aspects, he MUST accept the risks involved.

The attestation SHALL be non-device-bound. The relying party SHOULD check the ownership of the etrc using the method described above. Device binding might create a false sence of trustworthyness. Because the etrc can be issued to an itermediary organisation, using a mandate, presenting the etrc is no proof of owenership. The etrc attestation will not be revoked by the issuer, when the mandate is revoked.

5 Trust anchors

Mechanisms for the provision of a trust anchor that SHALL be used for the verification of an attestation SHALL be defined in this section.

It is noted that the ARF specifies the following for QEAAs and Pub-EAAs:

To do this for [...] QEAAs the Relying Party Instance uses a trust anchor of the Provider obtained from a Trusted List. Note that the PID Provider or QEAA Provider may use an intermediate signing certificate to sign the PID or attestation, and use the trust anchor to sign the signing certificate, instead of signing the PID or attestation directly with the trust anchor.

For PuB-EAAs, the Relying Party Instance verifies a PuB-EAA by first verifying the signature of the PuB-EAA Provider over the PuB-EAA, using the PuB-EAA Provider certificate issued by a QTSP. Subsequently, the Relying Party Instance verifies the signature over this certificate, using the corresponding trust anchor from the QTSP Trusted List. Note that both the PuB-EAA Provider and the QTSP may use an intermediate signing certificate. All other things being equal, the verification of a PuB-EAA will therefore involve one or more extra certificates, compared to the verification of a PID or QEAA.

6 Revocation

The etrc Attestation SHOULD preferably be issued as a longlived attestation. In order to make sure the attestation reflects the current situation, the issuer MUST have revocation in place. An issuer must revoke the attestation following an event that would render any part of the content invalid.

When the attestation is issued by a QTSP outside the Authentic Source it should receive information from the authentic source in case attributes of the attestation change at the source. If the QTSP cannot receive this information, the attestation MUST be shortlived.

7 Compliance

In this section explicitly state how this specific rulebook complies with the general EUDI framework, ARF, and relevant regulations

[RULEBOOK AUTHOR TO DEFINE]

8 References