EAAmdoc

Attestation Rulebook for attestations of type Power of Attorney and Proof of Existence

Category: non-qualified EAA

Authors of the previous version: * Boris Lingl * Sofia Lucas * Alexander Manecke * Ignacio Ripoll * Iris Speiser * Marlene Urbschat

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

Feedback: GitHub issues, https://github.com/webuild-consortium/BU4/issues/

1 Introduction

This rulebook provides a common conceptual and operational foundation for the use of Power of Attorney and Power of Representation within the WeBUILD ecosystem. It explains how legal authority can be expressed, issued, presented, and verified in a digital context, enabling trusted business and public-sector processes across organizational and national boundaries.

Power of Attorney refers to a legally granted authority by which an economic operator authorizes another to act on its behalf within a defined scope. Power of Representation dcertifies a specific position or role held by the representative within an organization to operate with unliminted capacity in a given transaction or process, based on law, internal governance, mandate, or delegated authority. In digital wallet-based ecosystems such as EUBW and EUDI, these concepts need to be represented in a machine-readable, verifiable, and selective-disclosure-friendly form so that relying parties can validate both the existence and the limits of the authority.

The rulebook aims to align legal meaning, technical implementation, and operational trust requirements. It supports interoperable issuance and presentation flows, consistent terminology, and reliable validation of representation claims in cross-border use cases such as business-to-government interactions, tax-related procedures, and other regulated transactions. By establishing shared rules and reference patterns, the rulebook helps create a scalable foundation for trustworthy digital representation in the European business wallet environment.

1.1 Document scope and purpose

Scope

This document defines the scope and purpose of the WeBUILD rulebook for the use of Power of Attorney (PoA) and Power of Representation (PoR) here called Power of X (PoX) in digital business and public-sector interactions. It establishes a shared framework for how representation rights are described, issued, presented, verified, and relied upon in interoperable wallet-based environments, particularly in the context of the European Digital Identity Wallet and the European Business Wallet ecosystem.

The scope of this document covers the conceptual, legal, organizational, and technical foundations required to support trustworthy representation of economic operators acting on behalf of other economic operator. It addresses the roles of relevant actors, the structure and meaning of representation mandates, the requirements for verifiable attestations, and the conditions under which relying parties can assess the validity and scope of delegated authority in cross-border and regulated use cases.

The purpose of the rulebook is to create a common understanding among participating stakeholders and to support consistent implementation across pilots and future productive environments. It aims to reduce ambiguity, improve interoperability, and provide a reliable basis for secure and legally meaningful digital representation processes within the WeBUILD framework.This Rulebook specifies semantic, organizational and technical requirements for the digital representation of Power of X (PoX) attestations within the WE BUILD ecosystem.

It defines:

• the legal meaning of a digital Power of Attorney (PoA);
• the legal meaning of a digital Power of Representation (PoR);
• the actors participating in its lifecycle;
• the mandatory and optional data elements;
• issuance requirements;
• presentation and verification requirements;
• trust requirements;
• revocation mechanisms;
• encoding requirements for interoperable attestation formats.

The Rulebook applies to Powers of X (PoA, PoR) issued for cross-border business interactions involving legal entities, public administrations and regulated service providers. The attestations of attributes described in this document MUST be supported by an authentic source, as defined in the eIDAS Regulation [CIR 2024/1183]. They shall be issued by a public sector body that is responsible for an authentic source or by a public sector body that is designated by the Member State to issue such attestations of attributes on behalf of the public sector bodies responsible for authentic sources in accordance with Article 45f and with Annex VI of the regulation. The issuer of the electronic attestation of attributes MAY choose not to validate the information with an authentic source in those cases where the subject of the attestation is not included in Annex VI of the eIDAS Regulation. Any attestation not supported by information provided by an authentic source MUST not be qualified according to eIDAS Regulation and ADRXXX.

Purpose

The primary objective of this Rulebook is to establish a common interoperable model for representing delegated authority inside the European Digital Identity ecosystem.

The objective of Power or X (PoX) is to provide legally valid and verifiable proof that an economic operator has the capacity to act on behalf of another, with clearly defined terms, scope, duration and limitations, based on the faculties and authority granted to them by holding an organic position within the entity (such as Sole Administrators, Supportive Administrator, Joint Administrator or Board Member) or by having a power of attorney with specific faculties.

The Rulebook enables organizations to digitally authorize individuals or other legal entities to perform legally binding actions on their behalf in B2B and B2G contecxts. Typical examples include:

• submitting tax declarations;
• representing an enterprise before public authorities;
• signing legally binding business transactions;
• submitting regulatory filings;
• accessing business platforms;
• performing financial or administrative operations.

The Rulebook ensures that delegated authority can be issued once and reused across multiple relying parties without repeated manual verification.

What real-world fact, entitlement, role, status, or capability the attestation expresses

This attestation expresses that the holder (the attorney-in-fact in the case of PoA) has been legally authorized by the granter (the principal) to act on their behalf in specific or general legal, administrative, or business matters; or certifies a specific position or role of the holder within a company, in accordance with the data entered in the official register authorised by each Member State (in the case of PoR). It formally establishes the entitlement to represent the principal before third parties, including government authorities, courts, financial institutions, or business partners. The attestation confirms the capability to make binding declarations, sign documents, submit applications, receive payments, or perform other defined actions within the scope of the granted power.

Which issuers, holders, and relying parties are expected to use it

Role Expected Actors - Issuers. In EUDI and EUBW context: Qualified Trust Service Providers (QTSPs) issuing digitally signed attestations with QES/QEAA. Economic operators wanting to attest authorizations to act on its behalf (self-issued). The attestation SHALL be issued by actors within the trust framework who are authorised to do so, whether they are a Trust Service Provider that has an agreement with the authentic source responsible for the data, a public sector body responsible for an authentic source, or an organisation acting on its behalf. - Holders. The appointed attorney-in-fact (natural or legal person), who may be a family member, legal advisor, company representative, or professional agent (PoA) or a person having a position within the company that entitles unlimited representation capacities (PoR). The holder stores the attestation in their EUBW wallet. - Relying. Parties Government agencies (e.g., courts, tax authorities, DPMA), financial institutions, notaries, businesses, or any third party requiring proof of representation authority before accepting actions taken by the holder. - Authentic Sources. Repository or system, held under the responsibility of a public sector body or private entity, that contains and provides attributes about a natural or legal person or object and that is considered to be a primary source of that information or recognised as authentic in accordance with Union or national law, including administrative practice;

Which use case or user journey the attestation supports

Primary Use Cases:

B2B: Authorizing employees or partners to sign contracts, conduct financial transactions, or represent the company in negotiations or get access to services

B2G: Representation before public authorities (e.g., submitting tax reporting, social security matters, ...)

Legal Proceedings: representation against 3rd parties, public sector and other relying parties, accepting service of documents and in most cases directly through personal actions as personal Affair while taking actionb / decisions on behalf of a company or organsation.

Example

This attestation enables a relying party (e.a. a tax authority) to verify, in plain language, that the holder (e.g. a tax advisor) is authorised to act in a specific project role (e.g. to file a tax declaration on behalf of a company in a another EU member state). It is intended for project operators, service providers, and supervisory relying parties in the WE BUILD ecosystem. The functional description and actor terminology can be reused from the corresponding use-case attestation description and refined here into rulebook language.

Business Context

Many European business processes require an individual to act on behalf of an organization in B2B and B2G contexts. Traditionally, such mandates are expressed by paper documents, national electronic registers or proprietary authorization mechanisms.

These approaches suffer from lack of interoperability, manual verification, legal uncertainty across borders, duplicated onboarding procedures and high operational costs.

Digital Powers of Attorney address these challenges by providing verifiable, machine-readable evidence of delegated authority.

Objectives

This Rulebook pursues the following objectives:

• establish a common semantic model;
• support cross-border interoperability;
• enable selective disclosure;
• reduce administrative burden;
• improve legal certainty;
• enable automated authorization decisions;
• support reuse across multiple services;
• align with the EUDI Wallet Architecture and Reference Framework.

Intended Audience

This Rulebook is intended for:

• Qualified Trust Service Providers;
• Electronic Attestation Providers;
• Authentic Sources;
• Business Register Operators;
• Wallet Providers;
• European Business Wallet Providers;
• Relying Parties;
• Public Administrations;
• solution architects;
• developers implementing WE BUILD pilots.

Power of X within WE BUILD

Within the WE BUILD ecosystem, Power of X (PoX) is the common semantic model used to describe the authority of a natural or legal person to act on behalf of a Economic Operator in a legally meaningful and verifiable manner. Rather than defining a separate attestation type, PoX provides a common representation framework for different forms of delegated or inherent authority. It establishes a shared conceptual model that can be specialized according to the legal origin of the authority.

The WE BUILD PoX model currently distinguishes three authority models:

• Power of Attorney (PoA) – authority explicitly delegated by a principal through a legally valid mandate defining the scope, duration and limitations of the delegated powers.
• Power of Representation (PoR) – authority derived directly from law, company statutes or an official register. The representative acts by virtue of holding an organizational position recorded by an authentic source.
• Power of Employee (PoE) – authority granted by an organization to an employee or contractor to perform defined operational activities or access specific services on behalf of the organization. Support for PoE may be specified in future versions of this Rulebook.

REMARK: As a BU4 Onsite Berlin decission, PoE will NOT be covered in MVP Pilot scenarios. It might be covered in MVP+ scenarios.

Common Representation Model

In general all PoX attestation will be based on one common approach and the same logical structure.

Representation
│
├── economic_operator_represented (legal_entity_represented)
│
├── proxy
│      │
│      ├── entity_type
│      ├── natural_entity_proxy
│      └── legal_entity_proxy
│
├── authority
│      │
│      ├── proxy_position
│      ├── proxy_power_scope
│      └── proxy_employee_authorisation
│
└── metadata

All three authority models share the same semantic foundation and differ only in the legal source from which the authority originates.

Where:

• Represented Economic Operator identifies the organization or Legal Entity on whose behalf actions may be performed.
• Proxy identifies the economic operator exercising the authority.
• Authority describes the legal basis that enables representation.
• Metadata contains attestation lifecycle and trust information.

The Authority component is specialized depending on the representation model:

Relationship to pilot cases and other WE BUILD Rulebooks

This Rulebook forms the wider WE BUILD Power of X framework. As one layer, it represents use case scenarios:

Power of X provides the common semantic foundation for authority-based attestations within WE BUILD. This Rulebook specifies the specialization for Power of X. All related specifications are included within this document:

• WE BUILD Attestation Rulebook – Power of Attorney
• WE BUILD Attestation Rulebook – Power of Representation
• WE BUILD Attestation Rulebook - Power of Employee Specification (future work - for transparency but will not be covered) plus
• WE BUILD Operational Rulebook – Access to Service

Represented Economic Operator 
          │
          ▼
        Proxy
          │
          ▼
      Authority
          │
          ▼
       Metadata

Represented Economic Operator with attestation
          │
          ▼
 get access to service 

This Rulebooks is expected to share the same core semantic model while specializing the Authority component according to their legal basis.

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 Rulebook adopts terminology defined by the European Digital Identity Regulation, the Architecture and Reference Framework, ETSI Electronic Attestation specifications and the WE BUILD semantic model.

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

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.

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

[RULEBOOK AUTHOR TO DEFINE]

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.

2.4 Purpose

This chapter specifies compliance requirements applicable to implementations of the WE BUILD Power of Attorney Rulebook.

Its purpose is to ensure that all participating ecosystem actors implement interoperable, secure and legally reliable Power of Attorney credentials.

Compliance with this Rulebook SHALL be assessed independently from national legislation. Where national law imposes additional requirements, such requirements SHALL take precedence.

2.5 Relationship to the European Digital Identity Framework

This Rulebook has been developed in accordance with objectives of the European Digital Identity Framework. In particular, it aligns with:

• Regulation (EU) 2024/1183;
• Architecture and Reference Framework https://eudi.dev/2.9.0/;
• Annex 2 – Topic 12, Attestation Rulebooks;
• Annex 2 – Topic 7, Revocation;
• Annex 2 – Topic 10, Issuance;
• applicable ETSI trust service specifications.

This Rulebook SHALL be interpreted consistently with those documents.

2.6 Compliance Objectives

Implementations conforming to this Rulebook SHALL support interoperable issuance, presentation, verification, revocation, cross-border recognition and selective disclosure where supported by the chosen encoding.

2.7 Issuer Compliance

An Issuer claiming compliance with this Rulebook SHALL:

• issue attestations according to the semantic model defined in Chapter 2;
• use one of the encoding formats defined in Chapter 3;
• implement the trust framework defined in Chapter 5;
• implement revocation mechanisms defined in Chapter 6;
• issue globally unique attestation identifiers;
• maintain issuer metadata;
• publish attestation status information.

Where Qualified Electronic Attestations are issued, the Issuer SHALL comply with applicable eIDAS requirements.

2.8 Wallet Compliance

Wallet implementations SHALL support secure attestation storage, secure attestation presentation, user consent, cryptographic verification, selective disclosure where supported and attestation lifecycle management.

Wallets SHOULD additionally support offline presentation where applicable, automatic status synchronization, Holder notifications and attestation backup and recovery according to applicable security policies.

2.9 Relying Party Compliance

Failure of any mandatory verification SHALL result in rejection of the attestation.

2.10 Holder Compliance

The Holder SHALL protect private cryptographic keys, prevent unauthorized attestation disclosure, present attestation only with informed consent and notify the Issuer where compromise is suspected.

The Holder SHOULD regularly synchronize attestation status and remove obsolete attestations where appropriate.

2.11 Semantic Compliance

Implementations SHALL preserve the semantic meaning of every attribute defined in Chapter 2. Encoding transformations SHALL NOT alter legal meaning, business interpretation, delegated authority, validity or scope.

Semantic interoperability SHALL take precedence over implementation-specific optimizations.

2.12 Privacy Compliance

Implementations SHALL comply with applicable European data protection legislation.

The following principles SHALL apply:

• data minimization;
• purpose limitation;
• user consent;
• confidentiality;
• integrity;
• accountability.

Selective disclosure SHOULD be supported whenever technically feasible. Relying Parties SHALL request only attributes necessary for the requested transaction.

2.13 Security Compliance

Every implementation SHALL support cryptographic attestation signatures, issuer authentication, secure communication, integrity protection, replay protection and attestation status verification.

Private keys SHALL remain under the exclusive control of their legitimate owner.

2.14 Interoperability Compliance

Conformant implementations SHALL support interoperability across Member States, Wallet Providers, Issuers, Relying Parties and Trust Service Providers.

Interoperability SHALL include common semantics, compatible attestation encodings, standardized verification procedures and standardized trust mechanisms.

2.15 Conformance Levels

Organizations SHOULD aim to satisfy all five levels.

2.16 Future Compatibility

Future revisions of this Rulebook SHALL strive to maintain backward compatibility. Breaking changes SHOULD only be introduced where required by legislation, ARF revisions or security reasons.

Version identifiers SHALL clearly distinguish incompatible releases.

2.17 Governance

Maintenance of this Rulebook SHOULD be performed through the WE BUILD governance process. Governance responsibilities include publication of new versions, management of semantic changes, coordination with WP4 Semantics, alignment with ETSI and alignment with future EUDI Architecture and Reference Framework revisions.

2.18 Conformance Statement

An implementation claiming compliance with the WE BUILD Power of Attorney Rulebook SHALL demonstrate that it satisfies all mandatory requirements identified by the keyword SHALL throughout this document.

Requirements expressed using SHOULD are considered recommendations supporting interoperability and operational best practices. Requirements expressed using MAY identify optional capabilities.

Conformance SHALL be evaluated over the complete attestation lifecycle, including issuance, storage, presentation, verification, revocation and expiration.

Only implementations satisfying all mandatory requirements may claim compliance with this Rulebook.

2.19 Summary

This Rulebook establishes a common semantic, operational and technical foundation for interoperable digital Powers of Attorney within the WE BUILD ecosystem.

By combining common semantics, interoperable attestation formats, trusted issuance, standardized verification, robust revocation mechanisms and cross-border trust, the Rulebook enables legally reliable delegation of authority throughout the European Digital Identity ecosystem and provides a foundation for future European Business Wallet services.

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

Chapter Overview

This chapter defines the semantic model of the Power of X (PoA, PoR) attestation independently of any attestation encoding format.

Every Power of Attorney SHALL express a legally valid delegation of authority between a Principal and a Position or an Attorney-in-Fact. The attestation SHALL allow a Relying Party to determine:

• who delegated authority;
• who received authority;
• which organization is represented;
• which actions are authorized;
• under which legal basis;
• for which validity period;
• under which restrictions;
• whether the mandate remains valid.

The semantic model defined in this chapter SHALL remain independent of the chosen attestation format.

3.1.1 Overall Semantic Model

A Power of X attestation is composed of four common semantic domains.

Power of X
│
├── Represented Economic Operator (Legal Entity)
├── Proxy
├── Authority
└── Metadata

Depending on the selected authority model, the Authority domain is represented as:

• Position (Power of Representation)
• Mandate (Power of Attorney)
• Employee Authorization (Power of Employee)

Remark

The attestation description used here for Power of X (PoA, PoR, PoE) already contain a domain model showing the holder, issuer, project, permit, and validity period. Depending on your way of personal information gathering and to make things easier to understand, the following UML diagram might help to sort information out easier

If you experience trouble viewing the UML-File please refer directly to our GitGUB Repo

https://github.com/webuild-consortium/BU4/blob/main/rulebooks/pox_rulebook_uml.png

Chapter overview and requirements

This chapter defines the semantic model of the Power of X (PoA, PoR) attestation independently of any credential encoding format.

Every Power of Attorney SHALL express a legally valid delegation of authority between a Principal and a Position or an Attorney-in-Fact. The attestation SHALL allow a Relying Party to determine:

• who delegated authority;
• who received authority;
• which economic operator is represented;
• which actions are authorized;
• under which legal basis;
• for which validity period;
• under which restrictions;
• whether the mandate remains valid.

The semantic model defined in this chapter SHALL remain independent of the chosen attestation format.

Requirements for non-qualified EAA

• An attribute indicating that the attestation is an EAA SHOULD be included (see ARB_12 in [Topic 12]). See also section 2.1.
• One or more attributes or metadata representing the set of data meant in Annex V point b) of the [European Digital Identity Regulation] SHALL be included (see ARB_15 in [Topic 12]).
• One or more attributes representing the set of data meant in Annex V point c) of the [European Digital Identity Regulation] SHOULD be included (see ARB_17 in [Topic 12])
• One or more attributes representing the set of data meant in Annex V point e) of the [European Digital Identity Regulation] SHOULD be defined (see ARB_19 in [Topic 12]).
• One or more attributes or metadata representing the location at which a machine-readable version of the trust anchor to be used for verifying the EAA can be found or looked up SHOULD be defined. What this location indicates precisely is dependent on the nature of the mechanism used for distributing trust anchors, detailed in section 5 (see ARB_21 in [Topic 12])
• Non-qualified EAA MAY be self-issued without the perticipation of an authentic source in the issuance process.

Requirements for QEAA

• An attribute as meant in Annex V point a) of the [European Digital Identity Regulation] SHALL be included (see ARB_11 in [Topic 12]). See also section 2.1.
• One or more attributes or metadata representing the set of data meant in Annex V point b) of the [European Digital Identity Regulation] SHALL be included (see ARB_13 in [Topic 12])
• One or more attributes representing the set of data meant in Annex V point c)
  of the [European Digital Identity Regulation] SHALL be included (see ARB_16 in [Topic 12]).
• One or more attributes or metadata representing the set of data meant in Annex V point e) of the [European Digital Identity Regulation] SHALL be included (see ARB_18 in [Topic 12]).
• One or more attributes or metadata representing the location meant in Annex V point h) of the [European Digital Identity Regulation] SHALL be included. This location SHALL indicate at least the URL at which a machine-readable version of the trust anchor to be used for verifying the QEAA can be found or looked up (see ARB_20 in [Topic 12]).
• Qualified EAA MUST use the information registered in an authentic source in the issuance process.

Requirements for PuB-EAA

• An attribute as meant in Annex VII point a) of the [European Digital Identity Regulation] SHALL be included (see ARB_11 in [Topic 12]). See also section 2.1.
• One or more attributes or metadata representing the set of data meant in Annex VII point b) of the [European Digital Identity Regulation] SHALL be included (see ARB_14 in [Topic 12]).
• One or more attributes representing the set of data meant in Annex VII point c) of the [European Digital Identity Regulation] SHALL be included (see ARB_16 in [Topic 12]).
• One or more attributes or metadata representing the set of data meant in Annex VII point e) of the [European Digital Identity Regulation] SHALL be included (see ARB_18 in [Topic 12]).
• one or more attributes or metadata representing the location meant in Annex VII point h) of the [European Digital Identity Regulation] SHALL be included. This location SHALL indicate at least the URL at which a machine-readable version of the qualified certificate that signed the PuB-EAA can be found or looked up. (see ARB_20 in [Topic 12])

3.2 Mandatory attributes

The semantic model is organized into four common domains that are shared by all Power of X attestations.

Domain 1 – Represented Economic Operator (Legal Entity)

An economic operator that has legal rights and obligations. An economic operator able to transact business, typically registered with a body able to confer legal status such as a national business register. It is able to trade, is legally liable for its actions, accounts, tax affairs etc. It will contain the minimum mandatory information for legal person identification, ensuring identity matching while delegating full company information to the EBW-OID [CIR 2024/2977]

Domain 2 – Proxy

Refers to the identity of an economic operator authorised to act on behalf of the Represented Economic Operator. In the context of the PoX, two possible types of proxy are identified that are mutually exclusive, and the attestation will contain only one of the two options shown below.

Domain 2.1 – Economic Operator Proxy

It will contain the minimum mandatory information for legal person identification, ensuring identity matching while delegating full company information to the EBW-OID [CIR 2024/2977]

Domain 2.2 – Natural Entity Proxy

It will contain the minimum mandatory information for natural person identification, ensuring identity matching while delegating full person information to the PID [CIR 2024/2977] with any possible modification approved in the context of WeBuild Consorcium, specifically through WP4 PID-EBWOID group.

Domain 3 – Authority Scope

The Authority domain represents the legal basis enabling representation.

Depending on the attestation type, exactly one Authority specialization SHALL be present.

The Authority domain is specialized according to the legal origin of the authority while preserving a common representation model.

Three authority models are defined:

Only one Authority specialization SHALL be present in a single Power of X attestation.

For this Rulebook, the applicable Authority specialization is ProxyPowerScope.

Domain 3.1 Common Authority Components

Regardless of the specialization, the Authority domain may reference a common set of reusable semantic components.

These components are reused across multiple authority models to ensure semantic consistency.

Domain 3.2 ProxyPosition (Power of Representation | PoR)

This certifies a specific position or role held by the representative of a legal person, in accordance with the data entered in the official register authorised by each Member State.

Domain 3.3 ProxyPowerScope (Power of Attorney | PoA )

Representation powers authorise a person or entity to act on behalf of another in legal, administrative, or business matters. Each power has a specific scope that impose a context and limitations to the operations that may be performed by the Proxy.

3.3 Optional attributes

Optional attributes are grouped according to the common PoX semantic domains.

Domain 2.2 – Natural Entity Proxy

It will contain the optional information for natural person identification, ensuring identity matching while delegating full person information to the PID [CIR 2024/2977] with any possible modification approved in the context of WeBuild Consorcium, specifically through WP4 PID-EBWOID group.

Domain 3.2 ProxyPosition (Power of Representation | PoR)

This certifies the optional information regerding a specific position or role held by the representative of a legal person, in accordance with the data entered in the official register authorised by each Member State.

Domain 3.3 ProxyPowerScope (Power of Attorney | PoA )

This certifies the optional information regerding a specific scope and faculties of a Power of Attorney granted of a legal person, in accordance with the data entered in the official register authorised by each Member State.

Domain 3.3.1 Constraints

Operational restrictions on the use of power in accordance with its characteristics.

Domain 3.3.2 Mandator

The Mandator is the natural person that holds de PoR or PoA that entitles the empowerment of the subject. It will contain the minimum mandatory information for natural person identification, ensuring identity matching while delegating full person information to the PID [CIR 2024/2977]

| ProxyPowerScope.Mandator.FamilyName | TBD | Current last name(s) or surname(s) of the user to whom the person identification data relates | String | Duck | | ProxyPowerScope.Mandator.GivenName | TBD | Current first name(s), including middle name(s) where applicable, of the user to whom the person identification data relates. | String | Donald | | ProxyPowerScope.Mandator. BirthDate | TBD | Day, month, and year on which the user to whom the person identification data relates was born. | date-time or full-date as specified in RFC 3339 | 1990-07-08T10:30:21.000Z | | ProxyPowerScope.Mandator.BirthPlace | TBD | The country as an alpha-2 country code as specified in ISO 3166-1, or the state, province, district, or local area or the municipality, city, town, or village where the user to whom the person identification data relates was born. | alpha-2 country code as specified in ISO 3166-1 | BE | | ProxyPowerScope.Mandator.Nationality | TBD | One or more alpha-2 country codes as specified in ISO 3166-1, representing the nationality of the user to whom the person identification data relates. | BE |

Domain 3.3.2 Service Access

Relying parties that provide online services that require some evidence of representation capabilities that enables the user to access an online service and / or operate within its boundaries.

3.4 Conditional attributes

No conditional atributes in the context of the PoX attestation

4 Metadata

Metadata describes the attestation rather than its subject.

4.1 Mandatory metadata

Every attestation SHALL include at least the following metadata.

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

4.4 Code lists

4.5 Integrity rules

5 Formats

5.1 SD-JWT VC-based encoding

5.1.1 Human-readable Payload Example

PERSONAS & ROLES used in examples

Bianca (Beratung) is our tax advisor to whom PoA is granted

Hans Schreiner GmbH is our company who grants PoA

Hans (Schreiner) is our sole shareholder and managing director of Hans Schreiner GmbH

5.1.1.1 JSON Schema

The JSON schema is available in poa-pox-sd-jwt.json. It is still a draft.

5.1.1.2 SD-JWT VC Type Metadata

The type metadata document is available in poa-pox-sd-jwt-type-metadata.json.

5.1.1.3 SD-JWT VC Reference Credential PoA

Draft of the PoA example is available in poa-pox-sd-jwt-sample.json.

5.1.1.4 SD-JWT VC Reference Credential PoR

Draft of the PoR example is available in poa-pox-por-sd-jwt-sample.json.

5.1.2 Mandatory JWT Claims

NOTE The Canonical Information Model separates business metadata from transport metadata. Standard JWT claims (iss, sub, iat, exp, jti, cnf, status) remain top-level SD-JWT VC claims, whereas business-related metadata are represented inside credential_metadata.

5.1.3 Private Claims

5.1.4 Selective Disclosure Policy

The following claims SHOULD be selectively disclosable:

• representative details;
• scope;
• restrictions;
• jurisdiction;
• professional registration;
• financial limits.

The following claims SHALL NOT be selectively disclosable:

• issuer;
• credential identifier;
• credential type;
• expiration;
• issue date;
• credential status.

5.2 ISO/IEC 18013-5-compliant encoding

ISO/IEC 18013-5-compliant Verifiable Credentials are not part of PoX attestations priority within WE BUILD, as we concentrate mainly on SD/JWT, mDoc for proximity use cased will be developed if and when needed

5.3 W3C Verifiable Credentials Data Model-based encoding

W3C Verifiable Credentials are not part of PoX attestations within WE BUILD, as we concentrate mainly on SD/JWT (mdoc for proximity use cased where applicable)

5.4 Encoding Consistency Rules

5.5 Selective Disclosure Requirements

Power of Attorney credentials contain legally sensitive information. Issuers SHOULD maximize use of selective disclosure mechanisms. A Holder SHOULD disclose only those attributes required by the transaction.

5.6 Privacy Considerations

Issuers SHALL apply the principle of data minimization. Wallets SHALL support selective disclosure where supported by the credential format. Relying Parties SHALL request only attributes necessary for the requested transaction.

5.7 Encoding Interoperability

A Power of Attorney issued in one supported encoding SHALL be semantically equivalent to the same credential issued in another encoding.

Wallets MAY internally convert between supported encodings provided that no semantic information is lost, cryptographic integrity is preserved, issuer authenticity remains verifiable and selective disclosure policies remain enforceable.

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

For detailed scenario description please review https://github.com/webuild-consortium/BU4/blob/main/scenarios/

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

8.1 Purpose

This chapter specifies mechanisms governing suspension, revocation and expiration of a Power of Attorney and Power of Representation attestation.

The objective is to ensure that delegated authority cannot be exercised after it has ceased to be legally valid. Within this rulebook both short-lived and long-lived attestation are permited and therefore revocation provitions SHALL be established.

8.2 Atestation Lifecycle

Draft
  |
  ▼
Issued
  |
  ▼
Active
|  |
| --- |
|  |
  ▼
Revoked
  |
  ▼
Expired

A attestation SHALL NOT return to the Active state after it has been revoked.

8.3 Expiration

Expiration occurs automatically when the validity period defined by the attestation ends. No explicit revocation is required after expiration. A Relying Party SHALL reject every expired attestation.

8.4 Revocation

Revocation permanently terminates the legal validity of a Power of Attorney before its scheduled expiration. Revocation SHALL occur whenever the delegated authority no longer exists.

Once revoked, the attestation SHALL NOT be accepted by any conformant Relying Party.

Once revoked, the attestation SHALL NOT regain it's valid status.

8.5 Suspension

Some jurisdictions permit temporary suspension of delegated authority. Where supported, suspension SHALL indicate that the mandate temporarily cannot be exercised. During suspension the attestation SHALL be treated as invalid.

8.6 Revocation Triggers

8.7 Authorized Revocation Actors

Only authorized entities SHALL revoke a attestation. Examples include the Issuer, Qualified Trust Service Provider, Principal, Competent Public Authority, Court and Authentic Source Operator.

The revocation authority SHALL be defined by applicable legislation.

8.8 Revocation Mechanisms

Implementations SHOULD support real-time status verification whenever technically feasible.

8.9 Atestation Status Values

Relying Parties SHALL reject every attestation except those having status active.

8.10 Status Verification

Before accepting a attestation, the Relying Party SHALL verify attestation identifier, current status, validity period and issuer status.

Status verification SHOULD occur online. Where offline verification is necessary, locally cached status information MAY be used if permitted by deployment policy.

8.11 Revocation Service

Each issuer SHALL publish a status service. The service SHALL support attestation lookup, status retrieval and timestamp of latest update. The endpoint SHALL be identified within the attestation metadata.

8.12 Short-Lived Attestation

Issuers MAY issue short-lived attestation. A attestation is considered short-lived where its validity period does not exceed 24 hours.

For short-lived attestations, explicit revocation MAY be omitted and expiration SHALL replace revocation.

8.13 Revocation Processing

Revocation Event
  |
  ▼
Issuer validates request
  |
  ▼
Attestation status updated
  |
  ▼
Status service updated
  |
  ▼
Wallet notified (optional)
  |
  ▼
Future presentations rejected

8.14 Wallet Behaviour

Wallets SHOULD periodically synchronize attestation status. Wallets SHOULD notify the Holder whenever a attestation has been revoked, suspended or approaches expiration.

Wallets SHALL prevent accidental presentation of revoked attestation. Wallets MAY retain revoked attestation for historical audit purposes provided they are clearly marked as invalid.

8.15 Relying Party Behaviour

Whenever a revoked attestation is presented, the Relying Party SHALL terminate validation, deny authorization, inform the Holder that the attestation is no longer valid and record the failed authorization event.

Business processes SHALL NOT continue using revoked attestation.

8.16 Audit Requirements

Issuers SHOULD maintain an auditable record of issuance, suspension, revocation and expiration. Audit records SHOULD contain credential identifier, timestamp, responsible authority, reason for revocation and evidence reference.

Audit records SHALL be protected against unauthorized modification.

8.17 Revocation Reasons

These reason codes SHOULD be machine-readable.

8.18 Revocation Notifications

Issuers MAY notify the Holder, Principal, Wallet Provider, Relying Parties or organizational administrators. Notification SHALL NOT replace status verification.

8.19 Conformance Requirements

An implementation claiming conformance with this Rulebook SHALL support attestation expiration, attestation revocation, status verification, revocation endpoint publication and rejection of revoked attestations.

Implementations SHOULD additionally support suspension, real-time status updates, revocation notifications and audit logging.

8.20 Operational Recommendations

Issuers SHOULD revoke attestations immediately after legal authority ceases, automate synchronization with Authentic Sources and minimize delay between legal revocation and technical revocation.

Wallet Providers SHOULD synchronize status frequently and prevent presentation of invalid attestations.

Relying Parties SHOULD perform status verification for every presentation, avoid long-term caching of attestation status and maintain audit logs for authorization decisions.

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:

Before accepting a Power of Attorney, the Relying Party SHALL verify:

• the identity of the presenting Holder;
• attestation integrity;
• issuer trust;
• attestation status;
• scope;
• validity period;
• restrictions.

Where required by applicable legislation, a PID SHALL be requested and verified. Malformed attestations SHALL be rejected.

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.

9.4 Usecase 1a A person action on behalf of an organisation with PoA

9.5 Usecase 1b A person action on behalf of an organisation with PoR

9.6 Usecase 1c A person action on behalf of an organisation with PoA, PoR accessing a service

9.7 Purpose

This chapter specifies how a Power of Attorney attestation SHALL be used within the WE BUILD ecosystem throughout its operational lifecycle.

The lifecycle comprises four principal phases:

1. issuance;
2. storage;
3. presentation;
4. verification.

Each phase SHALL preserve the legal meaning, integrity and trustworthiness of the delegated authority.

9.8 Operational Lifecycle

Principal
  |
  ▼
Grant of Authority
  |
  ▼
Authentic Source / Supporting Evidence
  |
  ▼
Issuer (QTSP / EAA Provider)
  |
  ▼
Attestation Issuance
  |
  ▼
Wallet Storage
  |
  ▼
Presentation
  |
  ▼
Verification
  |
  ▼
Authorization Decision
  |
  ▼
Revocation / Expiration

The lifecycle SHALL terminate immediately when the attestation expires, is revoked, or the underlying mandate ceases to exist.

9.9 Typical Business Use Cases

A Power of Attorney and Power of Representation MAY be used in cross-border business interactions including:

• tax declaration submission;
• customs declarations;
• company registration;
• public procurement;
• banking procedures;
• access to regulated business platforms;
• contract execution;
• representation before supervisory authorities;
• financial reporting;
• legal representation.

The Relying Party SHALL evaluate whether the presented mandate authorizes the requested business transaction.

9.10 Presentation Requirements

Presentation SHALL occur through a wallet supporting one of the attestation formats specified in Chapter 3.

Presentation MAY be performed online, cross-device, same-device or in proximity where supported by ISO/IEC 18013-5.

Wallets SHALL support user consent prior to disclosure. Wallets SHOULD support selective disclosure whenever technically possible.

9.11 Holder Obligations

Before presenting a Power of Attorney or Power of Representation, the Holder SHALL:

• verify that the attestation is still valid;
• verify that the requested transaction falls within the mandate scope;
• consent to disclosure;
• protect private cryptographic keys.

The Holder SHOULD minimize disclosure of unnecessary attributes. The Holder SHALL NOT modify the attestation.

9.12 Authorization Decision

After successful verification, the Relying Party MAY authorize the requested transaction. Authorization SHALL depend upon attestation validity, issuer trust, business policy, legal requirements and mandate scope.

Possession of a valid attestaion SHALL NOT automatically imply authorization. Business-specific policies MAY impose additional conditions.

9.13 PID Binding

Where national legislation requires personal identification, the PoA SHALL be cryptographically or logically bound to a Personal Identification Data attestation.

The Relying Party SHALL verify that the PID identifies the presenting individual and that the Attorney-in-Fact referenced by the PoA corresponds to the PID Holder.

9.14 Device Binding

A Power of Attorney MAY be device-bound or non-device-bound. Where device binding is implemented, the attestation SHALL contain the metadata attribute cryptographically_bound_to.

The recommended value is:

urn:eudi:pid:1

where the attestation is bound to a Personal Identification Data attestation.

9.15 Transaction Data

Presentation MAY include transaction-specific information such as requested service, relying party identifier, requested authorization scope, requested signature level, requested attributes, transaction identifier and timestamp.

Transaction data SHALL NOT become part of the attestation itself.

9.16 Privacy Requirements

The following privacy principles SHALL apply:

• data minimization;
• selective disclosure;
• user consent;
• purpose limitation;
• privacy-preserving audit logging.

9.17 Error Handling

Appropriate error information MAY be presented to the Holder. Detailed trust validation errors SHOULD NOT expose sensitive security information.

9.18 Cross-Border Recognition

Power of Attorney and Power of Representation attestations are intended for cross-border use. Participating Relying Parties SHOULD recognize attestations issued by trusted issuers located in other Member States where the applicable trust anchor is recognized, attestations validation succeeds and no legal restriction prohibits acceptance.

9.19 Operational Recommendations

Issuers MUST automate revocation and synchronize mandate changes with authentic sources.

Issuers MAY issue short-lived attestation whenever needed.

Wallet Providers SHOULD support offline presentation where applicable, selective disclosure and attestation status updates.

Relying Parties SHOULD cache trust anchors, perform online status checks whenever possible, log authorization decisions and apply the principle of least privilege.

9.20 Conformance

An implementation claiming conformance with this Rulebook SHALL implement attestation presentation, issuer trust verification, signature validation, attestation status verification, validity checks, mandate scope evaluation and authorization decision processing.

Selective disclosure support is RECOMMENDED. Offline presentation support is OPTIONAL unless explicitly required by the applicable deployment profile.

10 Trust Framework

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.

10.1 Purpose

This chapter defines the trust framework applicable to Power of Attorney attestations issued and verified within the WE BUILD ecosystem.

Its objective is to ensure that every Relying Party can establish a consistent level of trust in the issuer, the credential and the underlying delegation of authority.

10.2 Trust Model

European Digital Identity Framework
  |
  ▼
European Trusted Lists (eIDAS)
  |
  ▼
Qualified Trust Service Providers
  |
  ▼
QEAA / PubEAA / EAA Provider
  |
  ▼
Power of X (PoA, PoR) Attestation
  |
  ▼
Holder Wallet
  |
  ▼
Relying Party

Each trust layer SHALL validate the integrity of the previous layer. Failure of any trust layer SHALL invalidate the Attestation.

10.3 Trust Anchors

The trust anchor SHALL be machine-readable.

10.4 Qualified Electronic Attestations

For Qualified Electronic Attestations of Attributes, the Relying Party SHALL obtain the issuer certificate, validate the certificate chain, verify the Qualified Trust Service Provider, verify the Qualified Certificate and verify the attestation signature.

Trust SHALL ultimately terminate at a trust anchor contained within the applicable European Trusted List.

10.5 Public Electronic Attestations

Where a Public Electronic Attestation is used, the issuing public authority SHALL possess a qualified certificate, the certificate SHALL be verifiable through a Qualified Trust Service Provider and the QTSP SHALL be discoverable through the European Trusted Lists.

10.6 Non-qualified Electronic Attestations

For non-qualified Electronic Attestations, the trust framework SHALL be explicitly defined by the applicable governance framework. Acceptable trust mechanisms include organizational PKI, sector-specific trust frameworks, national trust registries and WE BUILD trusted issuer registries.

The issuer SHALL publish issuer identifier, public verification key, metadata endpoint and status endpoint.

10.7 Trust Anchor Distribution

Trust anchors SHALL be distributed through secure and authoritative mechanisms such as European Trusted Lists, Trusted List APIs, Organizational Trust Registries, Federation Metadata Services or signed Trust Lists.

Unsigned trust anchor distribution SHALL NOT be used.

10.8 Issuer Authentication

Before issuing a Power of Attorney, an Issuer SHALL authenticate itself towards the applicable trust infrastructure.

The following information SHALL be available:

• issuer identifier;
• certificate chain;
• public verification keys;
• attestation metadata endpoint;
• revocation endpoint.

10.9 Trust Verification by the Relying Party

Failure of any mandatory verification SHALL result in rejection of the attestation.

10.10 Trust Validation Process

Receive attestation
  |
  ▼
Verify Signature
  |
  ▼
Validate Certificate Chain
  |
  ▼
Resolve Trust Anchor
  |
  ▼
Validate Trust Anchor
  |
  ▼
Check attestation Status
  |
  ▼
Validate Business Rules
  |
  ▼
Authorize Transaction

The order MAY vary provided that equivalent security guarantees are achieved.

10.11 Authentic Sources

Where issuance of a Power of Attorney or Power of Representation depends on information obtained from an Authentic Source, the Issuer SHALL ensure that the Authentic Source is authoritative for the relevant information, the retrieved information is current at the time of issuance, the information has not been altered during transmission and access to the Authentic Source is appropriately authenticated and authorized.

Examples include Business Registers, Population Registers, Tax Registers, Professional Registers, Court Registers and National Mandate Registers.

10.12 Trust in Supporting Evidence

A Power of Attorney MAY be based upon additional supporting evidence such as notarized documents, court decisions, organizational resolutions, shareholder resolutions, employment contracts or professional licenses.

Where such evidence contributes to the issuance decision, the Issuer SHOULD maintain auditable references to that evidence. The evidence itself SHOULD NOT be embedded within the attestation.

10.13 Cross-Border Trust

A Relying Party SHOULD recognize issuers established in other Member States provided that the issuer is trusted, the applicable trust anchor is recognized, attestation validation succeeds and no national legal restrictions prohibit acceptance.

This Rulebook does not override national legislation governing legal recognition of mandates.

10.14 Trust Metadata

Metadata SHOULD be signed by the issuing authority.

10.15 Trust Failure Handling

The Relying Party SHOULD log trust failures for audit purposes.

10.16 Trust Governance

The governance of trusted issuers SHALL be defined by the WE BUILD Trust Framework. The framework SHOULD define issuer onboarding procedures, trust anchor publication, issuer suspension, issuer removal, key rollover procedures, certificate renewal and incident handling.

10.17 Conformance Requirements

An implementation claiming conformance with this Rulebook SHALL support issuer trust verification, certificate path validation, attestation signature verification, trust anchor resolution and attestation status verification.

Implementations SHOULD additionally support automatic trust anchor updates, metadata validation, key rollover handling and federated trust discovery.

Attestation lifespan defined in validity attribute SHALL NOT exceed the lifespan of the trust anchor.

11 References

Draft of the PoA example is available in poa-pox-sd-jwt-sample.json.