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

Category: PuB-EAA

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.

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

Feedback: GitHub issues

Table of contents

• 1 Introduction
  • 1.1 Document scope and purpose
  • 1.2 Document structure
  • 1.3 Key words
  • 1.4 Terminology
• 2 Compliance
  • 2.1 Compliance statement
  • 2.2 Regulatory basis
  • 2.3 Traceability
• 3 Attestation attributes
  • 3.1 Introduction
  • 3.2 Mandatory attributes
  • 3.3 Optional attributes
  • 3.4 Conditional attributes
• 4 Metadata
  • 4.1 Mandatory metadata
  • 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.2 ISO/IEC 18013-5-compliant encoding
  • 5.3 W3C Verifiable Credentials Data Model-based encoding
• 6 Protocols
• 7 Issuance
  • 7.1 Binding
  • 7.2 Issuance Policy
  • 7.3 Lifecycle management
  • 7.4 Embedded disclosure policy
• 8 Revocation
• 9 Presentation
  • 9.1 Presentation Policy
  • 9.2 Presentation modes
  • 9.3 Transactional data
• 10 Trust Framework
• 11 References

1 Introduction

1.1 Document scope and purpose

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

2.2 Regulatory basis

This attestation includes the data required by Annex VII of Regulation (EU) 2024/1183, points a, b, c, e and h, satisfying EW-DM-12-014, EW-DM-12-017, EW-DM-12-019, EW-DM-12-021 and EW-DM-12-023 respectively. It is issued by or on behalf of a public sector body responsible for an authentic source: the business register of the Member State of registration.

2.3 Traceability

Every applicable requirement mapped to the section that satisfies it. Requirements marked not applicable carry a stated reason.

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

The attestation attributes are defined in the tables of this chapter. 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].

3.1.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.

3.1.2 Address

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

3.2 Mandatory attributes

3.3 Optional attributes

3.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.

4 Metadata

Metadata describes the attestation rather than its subject.

4.1 Mandatory 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 urn:etsi:esi:eaa:eu:pub. 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

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

4.5 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.

5 Formats

5.1 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

5.1.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:

• status_list (object): the reference to this EUCC's entry in a Token Status List, as specified in CS-10 of the WE BUILD conformance specifications and in the IETF Token Status List.
• status_list.idx (integer, >= 0): the index of this EUCC in the status list.
• status_list.uri (string, URI): the URI of the Status List Token.

Example:

{
  "status": {
    "status_list": {
      "idx": 42,
      "uri": "https://issuer.example.com/statuslists/1"
    }
  }
}

5.1.2 Example Payload

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

5.2 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.

5.3 W3C Verifiable Credentials Data Model-based encoding

Note: EW-DM-12-001 (ARB_01a) permits the W3C Verifiable Credentials Data Model format for non-qualified EAA only. As a PuB-EAA the EUCC is not issued in this format. The encoding below is retained as an informative working profile of the EU Business Wallet ecosystem, pending a consortium decision, and the deviation is recorded for the rulebook quality assurance group.

W3C Verifiable Credentials are serialized 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 - see Data Schemas.

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 in order to support Electronic Attestions of Attributes:

• attestationLegalCategory in order to specify the category of the EAA, Pub-EAA for the EUCC.

Credential Subject

There are two different flavors of European Company Certificates:

• for limited liability companies and
• for partnerships.

Both are modeled by their own classes:

• LimitedLiabilityCompany - EU Company Certificate for limited liability companies
• Partnership - 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://w3id.org/ebwv/v0.1"
  ],
  "@id": "urn:d5dfeb39-edc7-40b1-a2fc-3968dbd3eac8",
  "@type": [
    "VerifiableCredential",
    "ElectronicAttestationOfAttributes"
  ],
  "attestationLegalCategory": "Pub-EAA",
  "credentialSubject": {
    "@id": "did:key:$publicKeyOfHolder$", // credential subject is bound to organisation
    "@type": [
      "EconomicOperator",
      "Company",
      "Partnership"
    ],
    "legalIdentifier": {
      "@type" : "Euid",
      "@value" : "NOFOR.987654321"
    },
    "legalName": "acme Partnership",
    "legalForm": "Partnership",
    "registeredAddress": {
      "@type":"Address",
      "fullAddress": "Via Appia 123, 00100 Rome, Italy",
      "thoroughfare": "Via Appia",
      "locatorDesignator": "123",
      "postName": "Rome",
      "adminUnitL2": "Lazio",
      "postCode": "00100",
      "adminUnitL1": "IT"
    },
    "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": "EUR"
        }
      },
      {
        "@type": "StatutoryPartner",
        "partnerId": "did:key:$publicKeyOfPartner3$", // statutory partner is bound to natural person 3
        "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.

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

The EUCC is a legal-person attestation held in an EU Business Wallet and identified through the EBWOID, so the PuB-EAA defaults of binding to a natural person's device and to the PID do not apply. Device binding MAY be applied to the key of the business wallet unit, and no cryptographically_bound_to attribute is used.

7.2 Issuance Policy

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.

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

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

Attestations of this type are revocable. The facts attested by an EU Company Certificate change when the company's registration changes, and the superseded attestation is revoked when a new one is issued (section 7.3).

Revocation status is published using a Token Status List, as specified in CS-10 of the WE BUILD conformance specifications and in the IETF Token Status List. Every revocable EUCC carries a status claim with a status_list object holding the idx of its entry and the uri of the Status List Token (section 5.1.1). The business register that issued the EUCC, or a Status Provider acting on its behalf, publishes the status. The expected time from the registration change to the status list update is to be stated by the authors.

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:

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

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.

10 Trust Framework

The trust anchor for this attestation is obtained as described below for a PuB-EAA. The trust anchor location applies in either case.

PuB-EAA

The Relying Party verifies a PuB-EAA by first verifying the signature of the PuB-EAA Provider over the attestation, using the PuB-EAA Provider certificate issued by a qualified trust service provider. It then verifies the signature over that certificate using the corresponding trust anchor from the QTSP Trusted List, as described in section 6.6.3.6 of the ARF main document. Both the PuB-EAA Provider and the QTSP may use an intermediate signing certificate, in which case the trust anchor is used to verify that certificate rather than the attestation directly.

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. For a PuB-EAA this location refers to the qualified certificate that signed the attestation (EW-DM-12-023); in this Rulebook it is the trust_anchor metadata of section 4.2.

Deployment profile

#TODO: the authors are to record how the business registers' certificates are distributed in the WE BUILD deployment, how a Relying Party or Wallet Unit looks them up, and the ordered verification steps.

11 References