Attestation Rulebook for attestations of type Contact Person

• Author(s):
  • [Florin Coptil, Robert Bosch GmbH]
  • [Dominic Hurni, SBB]
• Previous Authors *
• Reviewer(s):
  • [Werner Folkendt, Robert Bosch GmbH]
  • [Stephan-A Fuchs, Deutsche Bank]

• Contact:

  • Florin Coptil*

• Feedback:

1 Introduction

This attestation addresses the following question:

Who are the designated contact persons within a legal entity and what are their roles and contact details?

The Contact Person Attestation identifies natural persons acting as designated contacts within a legal entity, enabling automated and trusted exchange of contact person data between organizations in supply chain, procurement, and onboarding processes.

1.1 Document Scope and Purpose

Cross-company communication is daily business in supply management. To know the correct and valid contact persons for different issues (e.g., finance, product, quality, logistics) is crucial to conduct efficient business in the onboarding, pre-contracting, or contracting phase. In the onboarding process, a minimum of one contact person is required.

Use Cases:

Relying Party:

• Logistics employees have instant access to valid logistics contact person data. For example, in the event of a wrongly delivered battery cell, an employee contacts the responsible sales representative by email or phone.
• The Relying Party Wallet validates the revocation status of contact person data. Workflows into internal systems (e.g., master data management) follow automatically. Administrative employees receive a notification if a contact person is no longer valid.

Holder:

• An administrative employee receives a request from a procurer to provide contact persons for sales, production, finance, and quality for a specific product (e.g., battery cell). The holder company has issued Contact Person attestations for all its employees into its Company Wallet. The system selects the fitting employee to answer the request (e.g., a Key Account Manager as the battery cell sales contact person).
• The Holder is responsible for the lifecycle of the attestation, including revocation and role changes.

The added value of the Contact Person attestation for organizations is to automate the onboarding and maintenance process of contact person data, increasing data accuracy and enabling fast and secure business interactions.

This attestation flows only between organizations where a business relationship exists.

Design Decisions

This Contact Person Attestation Rulebook is based on:

• EU Company Certificate (EUCC) / European Business Wallet (EBW) framework as the foundational legal identity layer for the employing organization
• Schema.org vocabulary for personal name attributes
• Core Public Organisation Vocabulary (CPOV) for contact point attributes
• The Organization Ontology for role classification
• RFC 4021 for email address formatting
• ITU-T E.164 for telephone number formatting

1.2 Document Structure

This Rulebook is structured as follows:

• Chapter 2 describes the Contact Person attestation attributes and metadata in an encoding-independent manner, including the data model.
• Chapter 3 specifies how the attestation attributes and metadata are encoded: Section 3.2 covers SD-JWT VC-based encoding.
• Chapter 4 specifies attestation usage scenarios, Relying Party obligations, and integration with supplier onboarding and KYS workflows.
• Chapter 5 defines trust anchors and verification mechanisms for issuer authorization.
• Chapter 6 defines revocation mechanisms for the attestation.
• Chapter 7 provides compliance information regarding the EUDI framework and applicable data protection laws.

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

Additional terminology specific to this attestation:

2 Attestation Attributes and Metadata

The Contact Person Attestation is designed to provide a standardized, verifiable representation of a natural person designated as a contact within a legal entity. This attestation enables trusted and automated exchange of contact person data between organizations in supply chain, procurement, and onboarding processes.

2.1 Introduction

The data model for the Contact Person Attestation is structured as follows:

Data Model:*

ContactPerson Attestation
├─ legal_entity (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
└── contact_persons [1..n]                      // Array of ContactPerson 
│   ├─  given_name (M)
│   ├─  family_name (M)
│   ├─  role (M)
│   ├─  email (M)
│   ├─  telephone (O)

Note: M - mandatory / O - optional.

Explanation:

• The legal_entity object SHALL appear exactly once and contains an identifier object with at least one official identifier of the company.
• The Contact_Person object SHALL appear at least once and MAY be repeated for each designated contact. Each instance contains the person's name, role, and contact details.

Attestation Classification:

This attestation type is classified as:

• "EAA" Self-issued by the legal entity as part of its disclosures.

2.2 Mandatory Attributes

LegalEntity Attributes This object is defined once per attestation.

ContactPerson Attributes This object is defined for each person represented in the Contact Person Attestation.

2.3 Optional Attributes

LegalEntity Identifier Optional Attributes At least one of the following sub-fields SHALL be provided within the legal_entity.identifier object.

ContactPerson Optional Attributes

2.4 Conditional Attributes

No conditional attributes are defined for this attestation type.

2.5 Mandatory Metadata

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

2.6 Optional Metadata

2.7 Conditional metadata

No conditional metadata elements are defined for this attestation type.

2.8 Value Lists

2.8.1 Role Values

The role attribute SHOULD use descriptive role labels aligned with organizational functions. The following non-exhaustive list is provided for guidance:

2.9 Integrity Rules

The following integrity rules SHALL be enforced:

• The legal_entity.identifier object SHALL contain at least one non-empty identifier sub-field.
• The contact_persons array SHALL contain at least one entry.
• Each contact_person entry SHALL contain a non-empty given_name, family_name, role, and email.
• email SHALL be a valid email address conforming to RFC 4021.
• telephone, if provided, SHALL conform to ITU-T E.164.

3 Attestation Encoding

3.1 ISO/IEC 18013-5-compliant encoding

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

3.2 SD-JWT VC-based encoding

The Contact Person Attestation uses the SD-JWT VC format to allow for selective disclosure of contact attributes.

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

3.2.1 Attribute Encoding Table

3.2.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/contactperson/2026",
    "status_list_index": 321,
    "status_purpose": "revocation"
  }
}

3.2.3 Example Payload

Here is a non-normative example payload reflecting the new model:

{
  "vct":"eu.we-build:contactperson:1",
  "iss":"did:example:webuild-company-456",
  "iat":1736935200,
  "exp":1768471200,
  "attestation_legal_category":"EAA",
  "schema_version":"1.0",
  "trust_anchor_url":"https://trust.webuildconsortium.eu/anchors/eidas-tl",
  "legal_entity":{
    "identifier":{
      "euid":"DE-HRB-123456",
      "tax":"DE123456789",
      "lei":"529900T8BM49AURSDO55"
    }
  },
  "contact_persons":[
    {
      "given_name":"Anna",
      "family_name":"Schmidt",
      "role":"logistics",
      "email":"anna.schmidt@example.com",
      "telephone":"+4915123456789"
    },
    {
      "given_name":"Max",
      "family_name":"Mustermann",
      "role":"finance",
      "email":"max.mustermann@example.com"
    }
  ],
  "status":{
    "type":"status-list",
    "status_list_credential":"https://issuer.example.com/status/contactperson/2026",
    "status_list_index":321,
    "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/contact-person-sd-jwt-sample.json

3.3 W3C Verifiable Credentials Data Model-based encoding

4 Attestation usage

4.1. Issuance process

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.

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

4.2 Relying Party Obligations

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

4.2.1 – 4.2.8 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

4.2.9 Validate Integrity Rules

Validation of integrity and policy rules will be specified in a future version of this Rulebook.

5 Trust anchors

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.

5.1 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

6 Revocation

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

6.1 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 self-issuing legal entity for EAA) may modify the status list entry.

6.2 Revocation Triggers & Business Rules

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

7 References