Attestation Rulebook for attestations of type EBWOID (European Business Wallet – Owner Identification Data)

Provide information about the author(s) of this Rulebook in the following form:

• Author(s):
  • Jonas Toennis, Brønnøysund Registry Center

Provide versioning information about the Rulebook in the following form:

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

1 Introduction

1.1 Document scope and purpose

The European Business Wallet – Owner Identification Data (EBWOID) is based on the European Business Wallet Regulation draft COM(2025) 838. While this document is still in draft status, WE BUILD decided at the beginning of 2026 that the draft would be accepted as the basis for the Business Wallet work. This means that the suggested amendments to Regulation 2024/1183 will be applied within WE BUILD.

The European Business Wallet – Owner Identification Data (EBWOID) attestation defines a legally defined, common set of data that uniquely identifies an EBW owner (economic operator or public sector body) within the European Business Wallets (EBW) ecosystem. Its purpose is to provide a harmonised, interoperable attestation that enables Relying Parties and business wallets to establish trust in an EBW owner entity. EBWOID focuses on the core identifiers needed across national and cross‑border use cases.

Primary objectives:

• Provide a cross‑border unique identifier for the EBW owner (In WE BUILD EUID where available, otherwise a similarly constructed, unique per issuer identifier. <CountryCode ISO 3166-1 alpha-2>. e.g. SEBOLREG.123456789) and the official name of the EBW owner.
• Serving as the activation and ownership attestation enabler for the EBW.
• Support verification of issuer authenticity and attestation integrity based on the EBW proposal (Articles 8–9) and ARF trust requirements.
• Enable consistent consumption in EBW and EUDI flows as Electronic Attestations of Attributes (QEAA/Pub-EAA) aligned with applicable implementing acts.

1.2 Document structure

This Rulebook is structured as follows:

• Chapter 2 defines the EBWOID attestation attributes and metadata in an encoding‑independent manner.
• Chapter 3 specifies encodings. EBWOID is profiled for SD‑JWT VC and W3C VCDM; ISO/IEC 18013‑5 is out of scope for EBWOID.
• Chapter 4 defines the intended usage patterns and Relying Party obligations.
• Chapter 5 defines trust anchors and how Relying Parties verify EBWOID issuers.
• Chapter 6 defines revocation approaches.
• Chapter 7 states compliance to the EUDI framework and applicable regulations.

1.3 Keywords

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

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

1.4 Terminology

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

The terminology is extended as follows:

For more terminology, please refer to Article 3 of the legislation draft COM 2025/838

2 Attestation attributes and metadata

Requirements for the EBWOID 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])

Requirements for PuB-EAA

• Αn 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.
• Οne 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]).
• Οne 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]).
• Οne 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])

2.1 Introduction

The EBW Owner Identification Data (EBWOID) is a structured digital attribute designed to uniquely and verifiably identify economic operators and public sector bodies—within the EBW ecosystem in both national and cross‑border digital interactions. It encapsulates a claim (e.g. “This is the official name and unique identifier of the EBW owner”), metadata about the source of that claim (such as the registry or official record), and cryptographic assurances that validate the claim’s authenticity and issuer. EBWOIDs SHOULD be issued in SD‑JWT and/or W3C VCDM formats as Pub-EAAs/QEAAs. This chapter defines the legally required minimum attributes, as well as optional attributes.

In the WE BUILD context, EBWOIDs can be issued for any EBW owner, provided the attributes are derived from authentic sources notified to the Commission (EBW Article 8(2)).

All data identifiers and definitions in this chapter are independent of any encoding used. Consequently, the data identifiers in these tables are not necessarily the same as the claim names used for EBWOID complying with [SD-JWT VC]. Chapter 3.2 specifies the claim names to be used for such EBWOID.

2.2 Mandatory attributes per EBW proposal (Articles 8–9)

2.4 Mandatory metadata

2.5 Optional metadata

3 Attestation encoding

3.1 ISO/IEC 18013-5-compliant encoding

The ISO/IEC 18013-5 encoding is out of scope for the WE BUILD rulebook. This decision is based on the results of the specification phase of the WE BUILD consortium, during which no requirements or use cases for proximity sharing of the EBWOID credential were identified.

3.2 SD-JWT VC-based encoding

Verifiable Credential Type (vct): uri:eu.ebw.oid.1

Claim names and disclosure policy (aligned with Chapter 2 attributes):

Selective Disclosure: Attributes of the EBWOID SHALL NOT be selectively disclosable.

3.2.1 Attribute status

For SD‑JWT VC‑compliant EBWOID, the EBWOID 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 PID.

Example:

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

3.3 Example

Illustrative examples:

• Example claim set (human‑readable):

{
  "vct": "uri:eu.ebw.oid.1",
  "id": "NOFOR.123456789",
  "name": "Example AS",
  "attestation_legal_category": "PUB-EAA",
  "issuing_authority": "Brønnøysundregistrene",
  "issuing_country": "NO",
  "date_of_expiry": "2026-12-31",
  "trust_anchor": "https://tl.eidas.europa.eu/tl-browser/#/",
  "status": {
    "type": "status-list",
    "status_list_credential": "https://issuer.example.no/status/1",
    "status_list_index": 42,
    "status_purpose": "revocation"
  },
  "cnf": {
    "jwk": {
        "kty": "EC",
        "crv": "P-256",
        "x": "52aDI_ur05n1f_p3jiYGUU82oKZr3m4LsAErM536crQ",
        "y": "ckhZ-KQ5aXNL91R8Eufg1aOf8Z5pZJnIvuCzNGfdnzo"
    }
  }
}

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

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

4 Attestation usage

4.1 Use-case context

The EBWOID attestation serves diverse types of EBW owners across European digital services:

• Public sector body — a Union entity, a national, state, regional or local authority, a body governed by public law or an association formed by one or several such entities or bodies, or a private entity mandated by at least one such entities, authorities, bodies or associations to provide public services, when acting under such a mandate.
• Economic operator — any natural or legal person, or a group of such persons, including temporary associations of undertakings, acting in a commercial or professional capacity for purposes related to their trade, business, craft or profession

EBWOID is profiled for SD-JWT VC and W3C VCDM because these formats:

• Are mandated or recommended by the ARF and applicable implementing acts for electronic attestations of attributes.
• Support selective disclosure (SD-JWT VC) and linked-data integrity (W3C VCDM), enabling both privacy and semantical presentations.

Primary use cases:

• Proving the legal identity of an organisation (holder) to a Relying Party in national and cross‑border digital online services.
• Activating and enabling the ownership binding of the EBW.
• Establishing a trust context for additional legal‑person attestations that reference the EBWOID id.

Relying Party obligations:

• Verify the SD‑JWT VC signature and ensure the issuer is an authorised public body by validating the qualified certificate chain against the appropriate QTSP Trusted List (see Chapter 5).
• Check freshness: validate exp and consider iat.
• Apply revocation/status checks as defined in Chapter 6.
• Where the transaction requires binding to a natural person representative, the RP SHOULD request and verify a PID for the representative in addition to the EBWOID.

Presentation requirements:

• Selective disclosure is NOT permitted for the core EBWOID attributes; the holder presents EBWOID atomically.

Transactional data:

• The RP MAY keep minimal logs necessary to demonstrate lawful processing and verification events; no additional transaction‑specific attributes are introduced by EBWOID.

5 Trust anchors

For EBWOID as a PUB-EAA/QEAA, Relying Parties SHALL verify the EBWOID using the issuer credential:

• Public‑body issuer certificate issued by a Qualified Trust Service Provider (QTSP) when provided by or on behalf of a public sector body responsible for an authentic source;
• Qualified electronic attestation of attributes when provided by a QTSP; or
• Commission issuance for Union entities (having the same legal effect per EBW Article 8(4)). Relying Parties SHALL verify the relevant certificate chain up to the appropriate trust anchor (eIDAS Trust List or Commission trust anchor as applicable).

Verification steps:

1. Verify the SD‑JWT VC signature over the EBWOID using the issuer certificate.
2. Build and validate the certificate chain from the issuer certificate to a QTSP trust anchor listed in the appropriate Trusted List.
3. Validate certificate status (validity, revocation) per eIDAS trust list rules.
4. Use the trust_list_location metadata to discover the appropriate Trusted List or machine‑readable pointer.

Issuers MAY use intermediate signing certificates. RPs SHALL handle such chains. The trust model is equivalent to Annex VII for PuB‑EAA.

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

6 Revocation

TODO: WE BUILD WP4 - EBW owner identification data revocation task 5

EBWOID is expected to be long‑lived but revocable. This Rulebook adopts the following policy:

• EBWOID SHALL include exp. Validity longer than 24 hours is permitted; therefore, revocation MUST be supported.
• When the Commission specifies the Attestation Status List (ASL) or Attestation Revocation List (ARL) mechanism, EBWOID Providers SHALL implement that mechanism.
• Until such mechanisms are specified, EBWOID Providers SHALL publish revocation status via a machine‑readable endpoint referenced from the issuer’s policy, and Relying Parties SHALL implement status checking per that policy. Issuers SHOULD implement the oauth status list until otherwise specified.

Relying Party checks:

• Validate exp not in the past.
• Query the designated ASL/ARL (or interim status endpoints) to determine the current status.
• Treat any indeterminate status as non‑valid per risk policy.

7 Compliance

This EBWOID rulebook is compliant with the draft for regulation COM(2025) 838, and in line with the ARF version 2.8.0. While the legislative process for the EBW Regulation continues, major updates to this rulebook within the WE BUILD context are not expected unless required by exceptional circumstances or requested by the WE BUILD Management Board.

8 References