• Template version: 1.1, 08-04-2026

Attestation Rulebook for attestations of type EU Power of Attorney (EU PoA)

• Author(s):
  • Erwin Nieuwlaar, KVK
  • Astrid Verhallen, Infogreffe

Feedback: Main feedback channel: GitHub issues

1 Introduction

1.1 Document scope and purpose

This attestation represents a legally valid Power of Attorney (EU PoA) issued within the European Union. It embodies:

• The identification of a principal (natural person acting on behalf of a legal entity)
• The identification and registration details of the company
• The designation of an attorney (delegate)
• The defined scope of representation
• The validity period
• The applicable law
• The signing details
• A reference to the EU Company Certificate (EUCC) if applicable

This attestation enables a relying party to verify that an attorney (delegate) has been granted specific powers of representation by a principal acting on behalf of a legal entity. The specific powers are limited to 6: the formation of companies; changes to the instrument of constitution of companies and the statutes if contained in a separate instrument; registration and closure of branches of the company; all legal transactions regarding cross-border conversions involving the company; all legal transactions regarding cross-border mergers involving the company; and all legal transactions regarding cross-border divisions involving the company. The EU PoA complements the EU Company Certificate (EUCC) by providing granular delegation information beyond the company's registered legal representatives.

1.2 Document structure

• Chapter 2, Attestation attributes and metadata in an encoding-independent manner.
• Chapter 3, Attestation attributes for the specific encoding [SD-JWT VC].
• Chapter 4, Attestation usage.
• Chapter 5, Trust anchors
• Chapter 6, Revocation mechanisms
• Chapter 7, Compliance information

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 terminology specified in Regulation (EU) 2024/1183.

In addition to the attributes definition necessary to understand the data schema, it is important to understand:

2 Attestation attributes and metadata

This section is used for defining all attributes that an attestation of the defined type may contain. In this section the attributes SHALL be defined in an encoding-independent manner (see ARB_06 in [Topic 12]). Each attribute can be mandatory, optional, or conditional, and it SHALL be specified in the corresponding section (see ARB_09 in [Topic 12]).

When attributes are defined, referring to attributes that already exist in a catalogue of attestation attributes SHOULD be considered (see ARB_07 in [Topic 12]).

2.1 Introduction

The EU Power of Attorney attestation SHALL be represented as a single flat object.

The attestation attributes are defined in the sections below. The attribute identifiers SHALL be used in requests and responses. There SHALL be at most one attribute with the same attribute identifier in each attestation.

The optionality column specifies whether the presence of the attribute in an attestation is mandatory (M) or optional (O).

NOTE: If an attribute is indicated as mandatory, this solely means that the Issuer SHALL ensure that this element is present in the attestation. It does not imply that a Relying Party is required to request such an attribute when interacting with the Wallet Instance. Neither does it imply that the User cannot refuse to release a mandatory attribute if requested.

The encoding format column indicates how the data elements SHALL be encoded, using the CDDL representation types defined in [RFC 8610].

2.2 Mandatory attributes

2.3 Optional attributes

2.4 Conditional attributes

No conditional attributes are defined for this attestation.

2.5 Mandatory metadata

2.6 Optional metadata

2.7 Conditional metadata

No conditional metadata are defined for this attestation.

2.8 Code lists

2.9 Integrity rules

3 Attestation encoding

3.1 ISO/IEC 18013-5-compliant encoding

ISO/IEC 18013-5 (also called mdoc) is not currently included in this rulebook. Should a use case arise that requires offline proximity presentation for the EU PoA, support for this standard may be added in a future version.

3.2 SD-JWT VC-based encoding

The EU PoA attestation uses the SD-JWT VC format to allow for selective disclosure of PoA attributes.

Verifiable Credential Type (vct): uri:eu.eudi.eu-poa.1

#TODO: Provide an example of the issued SD-JWT (in Base64 encoding).

4 Attestation usage

#TODO: Briefly describe the primary use cases or scenarios for which this attestation type is intended.

5 Trust anchors

#TODO

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

#TODO

(Refer to [Topic 7] of the ARF for a list of High-Level Requirements related to Revocation)

In this section information about the revocation mechanism used SHALL be defined.

For PID, QEAA, or PuB-EAA it SHALL be defined whether only short-lived attestations will be used, having a validity period of 24 hours or less, such that revocation will never be necessary, or that the attestations are revocable.

For revocable attestations it SHALL be defined which of the following methods must be implemented:

• Use an Attestation Status List mechanism.
• Use an Attestation Revocation List mechanism.

7 Compliance

#TODO

8 References