EAASD-JWT VC

Attestation Rulebook for attestations of type ESG Certificate

Category: non-qualified EAA

• Author(s):
• [Dominic Hurni, SBB]
• [Werner Folkendt, Robert Bosch GmbH]
• Previous Authors
• Reviewer(s):
• [Florin Coptil, Robert Bosch GmbH]
• Contact:
• Dominic Hurni *
• Werner Folkendt *
• Feedback:

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

Feedback: GitHub issues

1 Introduction

This attestation addresses the following question:

Does this legal entity hold a valid ESG-related certificate (e.g., ISO 9001, ISO 14001, IATF 16949) and what is its certified scope?

The ESG Certificate Attestation provides a standardized, verifiable digital representation of Environmental, Social, and Governance certificates held by a legal entity, enabling structured exchange of certification data for use in KYS, supplier onboarding, compliance verification, and regulatory audit processes.

The issuers of the certificate are: - (a) Accredited issuers — certification bodies authorized to issue ESG-related certificates (e.g., Bureau Veritas, TÜV, DNV). - (b) Legal entities — companies that own certificates that are still valid but need to present the data as an EAA during onboarding to their customers.

1 Introduction

1.1 Document scope and purpose

The ESG Certificate Attestation provides a standardized, verifiable digital representation of Environmental, Social, and Governance certificates held by a legal entity. It enables structured exchange of certification data for use in KYS (Know Your Supplier), supplier onboarding, compliance verification, and regulatory audit processes.

This attestation captures the essential attributes of a physical or digital ESG certificate - including the certificate type, registration number, validity dates, certified scope, site information, and optional evidence attachment, in a machine-readable, selectively disclosable format compliant with the EUDI Wallet framework.

Design Decisions

This ESG Certificate Attestation Rulebook is based on: - EUDI Wallet / eIDAS 2.0 framework for digital identity and verifiable attestations - ISO 8601 for date formatting - International Code Designator (ICD) 0243 for BPNL (Business Partner Number Legal entity) as used in Catena-X - Support for multiple legal entity identifier schemes (EUID, LEI, DUNS, EORI, VAT ID, BPNL, GLN, SIREN) - CDDL representation types per [RFC 8610] for attribute encoding

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

Additional terminology specific to this attestation:

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

Where the attestation is issued as a qualified electronic attestation of attributes, the trust model of chapter 10 applies in its qualified form and the legal category recorded in section 4.1 changes accordingly.

2.3 Traceability

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

3 Attestation attributes

The ESG Certificate Attestation is designed to provide a standardized, verifiable digital representation of ESG-related certificates held by a legal entity. It captures all essential attributes of a physical or digital ESG certificate, including the economic operator identity, certificate metadata, certified scope with site-level granularity, and optional evidence, in a machine-readable and selectively disclosable format.

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

[Economic Operator] --- owns --- [Certificate] --- allocated to --- [Site and Scope]

Data Model:

├─ type (tstr), mandatory                      
├─ version (tstr), mandatory
├─ registration_number (tstr), mandatory 
├─ registration_initial_date (date), mandatory  
├─ registration_expiration_date (date), mandatory 
├─ legal_entity (M)
│   ├─ legal_person  (M)
│   │   ├─ legal_person_name (tstr) (M)
│   │   ├─ legal_form_type (tstr) (M)
│   ├─ identifier  (M)                          // At least one identifier required
│   │   ├─ euid (str) (O)                       // European Unique Identifier
│   │   ├─ lei (str) (O)                        // Legal Entity Identifier per ISO 17442
│   │   ├─ tax (str) (O)                        // National tax or registration number    
│   │   ├─ gln (str) (O)                        // Global Location Number for legal entities, GS1 identifier
│   │   ├─ duns (str) (O)                       // Data Universal Numbering System, Dun & Bradstreet identifier
│   │   ├─ eori (str) (O)                       // Economic Operators Registration and Identification number, EU customs identifier
│   │   ├─ bpnl (str) (O)                       // Business Partner Number Legal entity, Catena-X identifier per ICD 0243
│   │   ├─ siren (str) (O)                      // Système d'Identification du Répertoire des ENtreprises, French company identifier
│   ├─ address (Address) (M)           
│   │   ├─ street (tstr) (M)
│   │   ├─ house_number (tstr) (M)
│   │   ├─ locality (tstr) (M)
│   │   ├─ region (tstr) (M)
│   │   ├─ postal_code (tstr) (M)
│   │   └─ country (tstr) (M)                   // ISO 3166-1 alpha-2
├─ scope [1..n], mandatory                     // Array of ScopeObject
│   ├─ legal_entity_name (tstr) (M)
│   ├─ legal_entity_identifier  (M)             // At least one identifier required
│   │   ├─ euid (str) (O)                       // European Unique Identifier
│   │   ├─ lei (str) (O)                        // Legal Entity Identifier per ISO 17442
│   │   ├─ tax (str) (O)                        // National tax or registration number    
│   │   ├─ gln (str) (O)                        // Global Location Number for legal entities, GS1 identifier
│   │   ├─ duns (str) (O)                       // Data Universal Numbering System, Dun & Bradstreet identifier
│   │   ├─ eori (str) (O)                       // Economic Operators Registration and Identification number, EU customs identifier
│   │   ├─ bpnl (str) (O)                       // Business Partner Number Legal entity, Catena-X identifier per ICD 0243
│   │   ├─ siren (str) (O)                      // Système d'Identification du Répertoire des ENtreprises, French company identifier
│   ├─ site_identifier (uuid), (O)
│   ├─ site_address (Address), (M)
│   │   ├─ street (tstr) (M)
│   │   ├─ house_number (tstr) (M)
│   │   ├─ locality (tstr) (M)
│   │   ├─ region (tstr) (M)
│   │   ├─ postal_code (tstr) (M)
│   │   └─ country (tstr) (M)                     // ISO 3166-1 alpha-2
│   ├─ scope_description (tstr), (M)
│   └─ certified_site (boolean), (M) 
└─ evidence (Evidence), mandatory
    ├─ id (tstr) (M)                            // Unique identifier, URI, or URN
    ├─ type (tstr) (M)                          // Evidence type, see Section 2.8.9
    ├─ url (uri) (O)                            // URI to publicly accessible source document
    └─ data (base64) (O)                        // Base64-encoded, required if url absent

Note: M - mandatory / O - optional.

Explanation:

• The root object of the attestation is the Certificate itself.
• The legal_entity object is mandatory and identifies the primary organization to which the certificate was issued. It includes the legal name, legal form, at least one official identifier, and the primary Address.
• The scope attribute is a mandatory array that SHALL contain at least one ScopeObject. Each ScopeObject defines a specific certified entity or site, its address, a description of the certified activities, and a boolean flag (certified_site) indicating if the entire site is covered.
• The evidence object is mandatory and serves to prove the existence of the original certificate. It SHALL contain a unique id and a type. It MAY also include a url pointing to the document or the data of the document itself, encoded in base64.

Attestation Classification:

This attestation type MAY be classified as: - "EAA" self-issued by the legal entity as part of its disclosures. - "QEAA" issued by a Qualified Trust Service Provider (QTSP) or authorized competent body that can independently attest it.

3.2 Mandatory attributes

Certificate Attributes

Legal_Entity Attributes

ScopeObject Attributes This object is defined for each entry in the scope array.

Evidence Attributes

3.3 Optional attributes

Legal_Entity Identifier Optional Attributes

ScopeObject Identifier Optional Attributes

Evidence Optional Attributes

3.4 Conditional attributes

4 Metadata

Metadata describes the attestation rather than its subject.

4.1 Mandatory metadata

Note: Standard JWT claims (iss, iat, exp) are also mandatory.

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

No conditional metadata elements are defined for this attestation type.

4.4 Code lists

4.4.1 Legal Entity Identifier Type Codes

The identifier objects within Legal_Entity and scope SHOULD use one or more of the following standardized identifier types as keys:

4.4.2 Certificate Type Codes

The type attribute SHOULD use one of the following standardized values where applicable. Other certificate types MAY be used as free-text strings.

4.4.3 Evidence Type Codes

The evidence.type attribute SHOULD use one of the following values:

4.5 Integrity rules

The following integrity rules SHALL be enforced: - All mandatory attributes as defined in the data model SHALL be present and non-empty. - registration_expiration_date SHALL be a date later than or equal to registration_initial_date. - Each identifier object (for Legal_Entity and scope) SHALL contain at least one non-empty identifier. - The scope array SHALL contain at least one valid ScopeObject. - evidence.id and evidence.type SHALL be non-empty strings. - Either evidence.url or evidence.data SHALL be present. - certified_site SHALL be a boolean value (true or false). - All Address objects SHALL contain non-empty street, house_number, locality, postal_code, and country.

5 Formats

5.1 SD-JWT VC-based encoding

The ESG Certificate Attestation uses the SD-JWT VC format to allow for selective disclosure.

Verifiable Credential Type (vct): eu.we-build:esgcertificate:1

5.1.1 Attribute Encoding Table

5.1.2 Status Claim

For SD-JWT VC-compliant Attestations, the attestation MUST include a status claim if the technical validity period is greater than 24 hours.

The status claim SHALL be a JSON object with the following members:

Example:

{
  "status": {
    "type": "status-list",
    "status_list_credential": "https://issuer.example.com/status/esgcertificate/2025",
    "status_list_index": 456,
    "status_purpose": "revocation"
  }
}

5.1.3 Example Payload

The following is a non-normative example of an ESG Certificate Attestation SD-JWT VC payload.

{
  "vct": "eu.we-build:esgcertificate:1",
  "iss": "did:example:accredited-cert-issuer-123",
  "iat": 1724284800,
  "exp": 1882051200,
  "attestation_legal_category": "QEAA",
  "type": "ISO9001",
  "version": "2015",
  "registration_number": "DE015008",
  "registration_initial_date": "2024-08-22",
  "registration_expiration_date": "2027-08-22",
  "legal_entity": {
    "legal_person": {
      "legal_person_name": "Robert Bosch GmbH",
      "legal_form_type": "GmbH"
    },
    "identifier": {
      "euid": "DE.HRB.12345",
      "lei": "529900T8BM49AURSDO55",
      "tax": "DE811001001"
    },
    "address": {
      "street": "Robert-Bosch-Platz",
      "house_number": "1",
      "locality": "Gerlingen-Schillerhöhe",
      "region": "Baden-Württemberg",
      "postal_code": "70839",
      "country": "DE"
    }
  },
  "scope": [
    {
      "legal_entity_name": "Robert Bosch GmbH",
      "legal_entity_identifier": {
        "bpnl": "BPNL00000003CML1"
      },
      "site_identifier": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
      "site_address": {
        "street": "Auf der Breit",
        "house_number": "4",
        "locality": "Karlsruhe",
        "region": "Baden-Württemberg",
        "postal_code": "76227",
        "country": "DE"
      },
      "scope_description": "Development, production and distribution of products and services for the automotive aftermarket.",
      "certified_site": true
    }
  ],
  "evidence": {
    "id": "urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66",
    "type": "OriginalCertificate",
    "url": "https://certificates.issuer.com/DE015008.pdf"
  },
  "status": {
    "type": "status-list",
    "status_list_credential": "https://issuer.example.com/status/esg/2024",
    "status_list_index": 101,
    "status_purpose": "revocation"
  },
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "TCAER19Zvu3OHF4j4W4vfSVoHIP1ILilDls7vCeGemc",
      "y": "ZxjiWWbZMQGHVWKVQ4hbSIirsVfuecCE6t4jT9F2HZQ"
    }
  }
}

Sample payloads are provided under ../data-schemas/sd-jwt/sample-data/esg-certificate-sd-jwt-sample.json

5.2 ISO/IEC 18013-5-compliant encoding

ISO/IEC 18013-5 is out of scope for this Rulebook.

5.3 W3C Verifiable Credentials Data Model-based encoding

This Rulebook does not define a W3C Verifiable Credentials Data Model encoding for this attestation type.

6 Protocols

6.1 Issuance

This attestation is issued using OpenID for Verifiable Credential Issuance [OpenID4VCI], as profiled by [HAIP].

6.2 Presentation

This attestation is presented using OpenID for Verifiable Presentations [OpenID4VP]. Only remote presentation is in scope, consistent with chapter 5, which records the mdoc encoding as out of scope.

7 Issuance

7.1 Binding

7.2 Issuance Policy

For EAA (Self-Issued / Standard Issuance): - The issuer (i.e., the legal entity itself) issues the attestation based on the information and supporting documentation available at the time of issuance. - The issuer is responsible for ensuring that the attested information remains accurate and must immediately revoke the attestation if any change occurs that affects the validity or accuracy of the underlying data.

For QEAA (Qualified Issuance): - The issuer-either a Qualified Trust Service Provider (QTSP) or another authorized competent body-must issue and verify the attestation exclusively on the basis of authoritative sources, such as official company register data or audited financial statements. - The issuer is also responsible for maintaining a high level of assurance throughout the attestation's validity period by continuously monitoring the underlying information. If any change affecting the accuracy or validity of the attested data is detected, the issuer must promptly revoke the attestation.

The Issuer SHALL implement the base issuer obligation as defined in the Issuer Obligation specification: https://github.com/webuild-consortium/webuild-attestation-rulebooks-catalog/blob/main/rulebooks/rb-base/verifier-base-verification.md#41-issuer-obligations

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

An attestation SHALL remain valid only while its underlying information is accurate, complete, and legally effective.

Revocation Mechanism - Token Status List: The issuer must maintain an active IETF Token Status List (aligned with the Attestation Status List mechanism specified by the EU Commission). - Credential Metadata: The metadata status_list must be populated in every issued CompanyInfo attestation, referencing the status list URI and the credential's specific index.

Authorized Authority: Only the authorized issuer (the QTSP/competent body for QEAA, or the self-issuing legal entity for EAA) may modify the status list entry.

Revocation Triggers & Business Rules - QEAA Trigger (Automatic): The QTSP/competent body must actively monitor official company register data and audited financial statements. Any detected discrepancy or change in the company registry must automatically trigger revocation of the QEAA. - EAA Trigger (Manual Obligation): The self-issuing legal entity is under strict obligation to immediately update or revoke its EAA if its available documents, financial thresholds, or ownership structures change.

Relying Party Action: A revoked or suspended attestation must be treated as invalid for credential-validity purposes by all RPs. The business interpretation is determined by the Relying Party's internal compliance policies.

9 Presentation

Base Verification Process

The Relying Party SHALL perform the base attestation verification process as defined in the Base Verification specification: https://github.com/webuild-consortium/webuild-attestation-rulebooks-catalog/blob/main/rulebooks/rb-base/verifier-base-verification.md#42-relying-party-obligations

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 Relying Party obligations of the previous version of this Rulebook:

When receiving and processing an attestation, the Relying Party SHALL perform the following verification obligations.

9.2 Presentation modes

Remote presentation is in scope. Proximity presentation is not in scope, consistent with chapter 5, which records the mdoc encoding as out of scope.

9.3 Transactional data

This Rulebook defines no transactional data.

10 Trust Framework

The trust anchor is obtained as described in the branch below that corresponds to the legal category under which the attestation was issued.

This chapter specifies the trust anchor mechanisms used by Relying Parties to establish trust in the issuer of an Electronic Attestation of Attributes (EAA) or a Qualified Electronic Attestation of Attributes (QEAA). The corresponding verification procedures are defined in Sections 4.2.2–4.2.4.

Qualified Electronic Attestations of Attributes (QEAAs)

For QEAAs, trust is established through the X.509 Public Key Infrastructure (PKI) and the applicable Trust List of Licensees (TLOL). The issuer's certificate chain, including the intermediate certificate contained in the QEAA header, SHALL be validated up to a trusted root certificate. This validation SHALL be performed using the applicable TLOL, taking into account the trust list state applicable at the time of issuance.

Successful certificate chain validation establishes that: - the issuer's certificate was recognized within the applicable trust framework; - the issuer's identity has been validated by the supervisory authority during inclusion in the TLOL; and - the issuer satisfies the trust requirements applicable to QEAAs.

In addition, the Relying Party MAY apply further authorization checks based on its internal policies, such as maintaining a whitelist of accepted QEAA providers.

Electronic Attestations of Attributes (EAAs)

For EAAs, trust is established through a cryptographic chain anchored in the Electronic Business Wallet Owner Identity Document (EBWOID). The EBWOID SHALL be included in the header of every EAA. During EBWOID issuance, the EBWOID provider verifies that the public key contained in the EBWOID is owned by the Electronic Business Wallet (EBW) owner.

The Relying Party SHALL verify the EBWOID in accordance with the verification procedure defined in this Rulebook. Upon successful verification, the Relying Party obtains: - assurance that the EBWOID was issued by an authorized provider and is not self-issued; - the verified identity of the issuer, including its name and EUID (or another globally unique EBW owner identifier); and - the public key authorized to verify the EAA signature.

Authorization of the issuer is subsequently determined in accordance with the Relying Party's internal policies. Such authorization MAY be based on locally maintained wallet configuration or on trusted jurisdiction- or domain-specific trust list services that identify issuers authorized for a particular type of EAA

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.

11 References