• Template version: 1.1, 20-08-2025

Attestation Rulebook for attestations of type European Company Certificate (EUCC)

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

• Author(s):

  • Jonas Toennis, Brønnøysund Registry Center
  • Erwin Nieuwlaar, KVK
  • Astrid Verhallen, Infogreffe

• Previous Authors

  • celiacouson

Provide versioning information about the Rulebook in the following form:

Feedback: Main feedback channel: GitHub issues Alternative: Contact Business usecase 2 contact points in WE BUILD.

1 Introduction

1.1 Attestation introduction

This document is the EU Company Certificate Data Rulebook (referred to as EUCC) based on the EU Company Law regulation. It contains the specific requirements, issuance process, formatting and content of the EUCC. This document is created and used by the WEBUILD consortium to provide a common understanding, data schema, format and usage guidlines for the WEBUILD eco system.

This document MAY be used as one of multiple innputs toward a final EUCC definition for the EBW ecosystem. That is under the sole discreation of the EU commission or any other relevant authority with delgated power from the commission.

This attestation represents a legally valid European Company Certificate (EUCC). It embodies:

• Information of a legal person registered in a Member State
• The legal form of the entity
• The unique company identifier (EUID structure)
• The Member State of registration
• The official registered address
• The registration date
• The legal status of the entity
• The main economic activity (e.g. NACE classification)
• The legal representatives authorized to bind the company
• The applicable signatory rules

1.2 Introduction attribute specification

The attestation attributes are defined in the tables of Chapter 2 of this document. These tables contain the following information:

• The first column specifies the identifiers of the attestation attributes. The attribute identifiers in this column SHALL be used in requests and responses. There SHALL be at most one attribute with the same attribute identifier in each attestation attribute.
• The second column describes the meaning of the attribute.
• The third column specifies whether the presence of the attribute in an attestation is mandatory (M), or optional (O).
  • NOTE: If the table indicates an attribute 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 fourth column indicates how the data elements SHALL be encoded, using the CDDL representation types defined in [RFC 8610].

1.3 Document structure

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

1.4 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.5 Terminology

This document uses terminology specified in Regulation (EU) 2024/1183 and Annex 1 of the ARF.

In addition to the attributes definition necessary to understand the data schema, it's 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]).

[Topic 12] of Annex 2 of the ARF defines the following High-Level Requirements with respect to the Attestation Rulebooks

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])

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])

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

2.1 Overview attributes attestation

The following table combines all attestation attributes for the EUCC (mandatory, optional, and conditional) in a single overview. Attribute identifiers SHALL be used in requests and responses.

2.2 Code lists

The following code lists apply to specific attributes:

legal_person_status

Examples (Member-State specific):

• active
• dissolved
• in_liquidation
• insolvent
• struck_off

legal_person_activity

Values:

• NACE codes (EU)
• ATECO (Italy)

registration_member_state

ISO 3166-1 alpha-2 country codes

signatory_rule

Values:

• sole
• joint
• joint_two
• joint_all
• limited

2.3 Integrity rules

• registration_member_state MUST be a valid ISO 3166-1 alpha-2 code.
• registration_date MUST be equal to or earlier than the issuance date of the attestation.
• legal_person_id MUST follow the EUID structure.
• At least one legal_representative MUST be present.
• signatory_rule MUST be defined for each legal representative.

2.4 Conditional attributes

If a Natural Person is representative of a legal person, the following attributes SHALL be included:

If a Legal Person is representative of a legal person, the following attributes SHALL be included:

A combination of natural and legal persons can be legal representatives of a legal person.

2.5 Address

There is currently no open standard for addresses. As such, the definitions from EWC for company addresses are re-used.

2.6 Mandatory metadata

2.7 Conditional metadata

3 Attestation encoding

3.1 ISO/IEC 18013-5-compliant encoding

ISO/IEC 18013-5 (also called mdoc) is out of scope for this rulebook, as offline proximity presentation is not a current requirement for EUCC.

3.2 SD-JWT VC-based encoding

The EUCC attestation uses the SD-JWT VC format to allow for selective disclosure of company attributes. Selective Disclosure: Claims of EUCC SHALL NOT be selectively disclosable to preserve the legally mandated content of the EUCC.

The . notation is used to indicate the nesting of attributes.

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

3.2.1 Attribute status

For SD-JWT VC-compliant EUCCs, the EUCC 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.2.3 Example Payload

Sample payloads provided under ../../data-schemas/sd-jwt-vc/sample-data/ds004-eucc-sd-jwt-sample.json

3.3 W3C Verifiable Credentials Data Model-based encoding

W3C Verifiable Credentials are defined using linked data (JSON-LD). Ontologies (vocabularies) are used to semantically define the different aspects of credentials including the credential subject. Validation of data structures is optional. If required, either JSON-schemes (data structure) are SHACL (data graph) can be used to validate data.

Metadata

The metadata of an W3C Verifiable Credential are defined in the Verifiable Credentials Vocabulary v2.0. The following extensions are defined in the European Business Wallet Vocabulary v0.1 in order to support Electronic Attestions of Attributes:

• attestationLegalCategory in order to specify the category of the EAA (QEAA, Pub-EAA or EAA).

Credential Subject

There are two different flavors of European Business Certificates:

• for limit liability companies and
• for partnerships.

Both are modeled by their own classes:

• EuccLimitLiabilityCompany - EU Company Certificate for limited liability companies
• EuccPartnership - EU Company Certificate for partnerships

Holder Binding

EUCC credentials are hold by the organization and their legal representatives. Corresponding key binding is provided by using DID's. Please note that every node of JSON-LD tree is addressable by its own locally or globally unique identifier @id. Using Decentralized Identifiers (DIDs) v1.0 as identifiers allows to cryptographically bind any node to its underlying identity:

example of key binding using DID's:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://ebw-vocabulary.spherity.dev/ebw-context/v0.1"
  ],
  "@id": "urn:d5dfeb39-edc7-40b1-a2fc-3968dbd3eac8",
  "@type": [
    "VerifiableCredential",
    "ElectronicAttestationOfAttributes"
  ],
  "attestationLegalCategory": "QEAA",
  "credentialSubject": {
    "@id": "did:key:$publicKeyOfHolder$", // credential subject is bound to organisation   
    "@type": "EuccPartnership",
    "legalIdentifier": "NOFOR.987654321",
    "legalName": "acme Partnership",
    "registeredAddress": {
      "@type":"Address",
      "fullAddress": "Via Appia 123, 00100 Rome, Italy",
      "thoroughfare": "Via Appia",
      "locatorDesignator": "123",
      "postName": "Rome",
      "adminUnitL2": "Lazio",
      "postCode": "00100",
      "adminUnitL1": "IT"
    },
    "correspondenceAddress": {
      "@type":"Address",
      "fullAddress": "Via Appia 123, 00100 Rome, Italy",
      "thoroughfare": "Via Appia",
      "locatorDesignator": "123",
      "postName": "Rome",
      "adminUnitL2": "Lazio",
      "postCode": "00100",
      "adminUnitL1": "IT"
    },
    "dateOfRegistration": "2023-10-11",
    "companyStatus": "active",
    "economicActivity": {
      "@type": "Nace021",
      "naceCode": "01.12",
      "naceDescription": "Growing of rice"
    },
    "partner": [
      {
        "@type": "GeneralPartner",
        "partnerId": "did:key:$publicKeyOfPartner1$" // general partner is bound to natural person 1
      },
      {
        "@type": "LimitedPartner",
        "partnerId": "did:key:$publicKeyOfPartner2$", // limited partner is bound to natural person 2
        "liabilityOrContribution": {
          "@type": "Capital",
          "amount": 100000,
          "currency": "Euro"
        }
      },
      {
        "@type": "StatutoryPartner",
        "partnerId": "did:key:$publicKeyOfPartner3$",
        "role": "Head of HR",
        "scopeOfAuthorization": "Jointly"
      }
    ]
  },
  "validUntil": "2029-12-03T12:19:52Z",
  "validFrom": "2019-12-03T12:19:52Z",
  "issuer": "did:key:$publicKeyOfIssuer$"
}

The Verifiable Credential Data Model (VCDM) doesn't dictate any specific DID-method. Instead, any did method that supports the underlying trust framework and is able to provide the required level of assurance can be used:

• PKI-Infrastructure (e.g. EU-TLOL based on X.509 certificates): did:key - the public key is directly encoded in the identifier
• DTL (e.g.: Ethereum): did:ethr
• European Block Chain Infrastructure: did:ebsi
• Domain Name System (DNS): did:web
• Domain Name System verifiable history: did:webvh

Proof mechanisms

The preferred proof mechanism for the EUCC Attesation is ecdsa-sd-2023 as specified in Data Integrity ECDSA Cryptosuites v1.0. ecdsa-sd-2023 supports selective disclosure out of the box. The issuer doesn't need the select disclosable claims, create disclosures or manipulate the payload of the credential. The issuer just applies the ecdsa-sd-2023 data integrity proof to the credential. The holder chooses which claims he wants to disclose and derives a proof from the original assertion proof.

For backward compatibility and for trust frameworks whose policies require a particular proof mechanism, JOSE and SD-JWT as specified in Securing Verifiable Credentials using JOSE and COSE should be supported, too.

The Security Vocabulary is used to embed the proofs into the credentials.

A side-by-side comparision of the proofs is provided in the Verifiable Credentials Data Model v2.0.

Credential status

The EUCC SHALL include a status claim credentialStatus 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 Bitstring Status List v1.0.

4 Attestation usage

The EUCC is intended to be used as a standardised, machine-verifiable proof of a company's incorporation and registered company information, to be presented by a Wallet User to an RP in cross-border and domestic contexts.

Typical scenarios include, but are not limited to:

• Cross-border business onboarding (B2B): sharing official company registration data during supplier/customer onboarding, procurement qualification, or partner due diligence.
• Public administration procedures (G2B): providing evidence of registration and company attributes when applying for permits, registrations, notifications, or access to public services.
• Financial and regulated services: supporting organisational onboarding steps where official company data is required (e.g., account opening or contractual setup), where the RP needs a reliable, registry-backed set of company attributes.
• Replacement/supplement of national extracts: substituting ad-hoc sharing of national registry extracts (often requiring translation) with a harmonised EUCC attestation.

The EUCC is not intended to be used as a standalone authentication mechanism to log into a company register or to replace processes that legally require a natural person to act and be authenticated in their own right.

Note: The EUCC includes information about legal representation (e.g., legal representatives and signatory rules). This supports business decisions but does not, by itself, prove that the current presenter is one of those representatives unless the RP also performs an appropriate binding to the presenter (typically via PID and/or additional authorisation evidence outside the scope of this rulebook).

Note: The EUCC is intended for online, remote presentation using EUDI Wallet-compatible presentation protocols.

4.1 Issuance of the EUCC

• The Authentic Source of the data contained in the EUCC MUST be the company register. The company register can or MUST authorize an issuer to issue EUCCs on their behalf.
• The Issuance SHALL be based on up to date, authoritive data from the authorative source as defined by ????? #TODO
• The EUCC SHALL be key bound to the wallet, IF the wallet belongs to the company that the EUCC is issued for.
• If the EUCC is issued to a wallet that is not owned by the company that the EUCC is issued for, the EUCC SHALL NOT be key bound to the wallet.
• The EUCC SHALL be issued in a format that is compatible with the EUDI Wallet ecosystem (e.g., OpenID4VP profiles adopted by the ecosystem).
• To recive an EUCC with keybinding, the application shall ensure that the wallet is owned by the company that the EUCC is issued for through presentation, and matching of key material of the European busesiness wallet owner identifaction data (OID). Note If bulk issued to the same wallet, the authorisation process of the OID process SHOULD be considered sufficent for reciept of an EUCC with keybinding in the same transaction.

4.5 Relying Party obligations when processing an EUCC

Beyond protocol-level checks, an RP processing an EUCC presentation SHALL perform at least the following controls:

1. Verify authenticity and integrity

   • Verify the EUCC cryptographic protections (signature/seal chain validation as applicable for the legal category).
   • Verify that the issuer is authorised to issue EUCCs according to the trust anchor mechanism defined in this rulebook (see Chapter 5).

2. Verify time validity / freshness

   • Verify the EUCC is within its validity period (e.g., using exp in SD-JWT VC).

3. Check revocation / status (where applicable)

   • Where the EUCC validity exceeds 24 hours and a status mechanism is provided, the RP SHALL check the EUCC validity status using the mechanism defined in Chapter 6.

4. Process according to purpose limitation

   • RPs SHOULD request and process the EUCC only when needed for the specific transaction, and only for the purpose of the transaction, in line with applicable legal requirements.

EUCC presentation may involve transactional data exchanged as part of the presentation protocol. The following transactional data elements are relevant for EUCC usage:

• Relying Party request parameters, including the requested credential type(s) and any policy constraints (e.g., requirement to include PID alongside EUCC).
• Challenge/nonce and session identifiers used to prevent replay and bind the presentation to a specific session.
• Presentation timestamp (implicit or explicit), to support auditability and freshness validation.
• Relying Party identification information presented to the Wallet Unit (e.g., RP name, domain, certificate details), to support user transparency and consent decisions.

The specific protocol artefacts and parameter names depend on the adopted OpenID4VP profile(s). This rulebook does not prescribe additional EUCC-specific transactional data beyond what is required by the underlying presentation protocol(s).

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.

For non-qualified EAA in this section it SHOULD be defined (see ARB_26 in [Topic 12]) how the attributes or metadata representing the location at which a machine-readable version of the trust anchor to be used for verifying the attestation can be found, specified in section 2, are used. This includes a detailed description about how a Relying Party can obtain the trust anchor, as well as a detailed description about how this trust anchor can be used for verifying that the provider is authorised to issue the attestation. Additionally, for non-qualified EAA Provider this section MAY include a description of mechanisms that can be used by a Wallet Unit for verifying that the provider is authorised to issue this type of attestation (see ISSU_34 in [Topic 10])

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 included in a Technical Specification that will be specified by the Commission.
• Use an Attestation Revocation List mechanism included in a Technical Specification that will be specified by the Commission.

8 References