EAASD-JWT VCmdoc

Attestation Rulebook for attestations of type Approved Supplier

Category: non-qualified EAA

This Rulebook is derived from the generic WE BUILD attestation rulebook template, version 1.0 with 11 chapters (itself derived from the EUDI attestation rulebook template) and keeps the template's chapter structure. It specifies the Approved Supplier attestation used in WE BUILD Use Case SC5 (eInvoicing), Scenario 1 (Supplier pre-approval).

• Author(s):
  • Rune Kjørlaug, Emning AS / OpenPeppol (SC5 co-lead)

Feedback:

• WE BUILD SC5 issue tracker

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

Feedback: GitHub issues

1 Introduction

1.1 Document scope and purpose

This Rulebook defines the Approved Supplier attestation, an Electronic Attestation of Attributes (EAA) used within WE BUILD Use Case SC5 (eInvoicing).

In plain language, the Approved Supplier attestation lets a Buyer declare, in a machine-verifiable way, that it has an active commercial relationship with a specific Supplier and approves the receipt of invoices from that Supplier. The attestation is issued by the Buyer to the Supplier and is later presented by the Supplier (or on the Supplier's behalf) so that a Service Provider can verify, before an invoice enters the Peppol network, that the sending Supplier is genuinely approved by the Buyer it claims to invoice. This prevents unauthorised or fraudulent invoices from being transmitted on behalf of buyers who have no relationship with the sender.

• Real-world fact expressed: that a named Buyer has pre-approved a named Supplier to send it invoices, for a defined scope and validity period.
• Issuers: the Buyer (Peppol corner C4), acting as a legal person through its European Business Wallet (EBW).
• Holders: the Supplier (Peppol corner C1), holding the attestation in its EBW.
• Relying parties: the Supplier's Access Point (Peppol corner C2), which verifies the attestation at invoice-submission time. Other access points or supervisory parties may verify it in MVP+ scenarios.
• Use case / user journey: SC5 Scenario 1 (Supplier pre-approval). The attestation is issued once (or periodically) and verified on each invoice submission in a machine-to-machine flow.
• Source material: the SC5 eInvoicing scenario specification (SC5_Introduction.md and SC5_Scenario1_SupplierPreApproval.md). Actor terminology (C1–C4, EBW, EBWOID, Access Point) is kept aligned with that specification and with the Peppol Interoperability Framework.

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 the terminology specified in Annex 1 of the ARF, supplemented by Peppol terminology (C1–C4, Access Point, SMP/SML, Peppol participant identifier) and WE BUILD terminology (EBW, EBWOID, WE BUILD LoTL, WE BUILD Trusted List) as defined in the SC5 specification and the WP4 Blueprint.

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.

This Rulebook follows the structure mandated by [Topic 12] of the ARF and the WE BUILD Attestation Rulebook Template v1.1. The Approved Supplier attestation is a non-qualified EAA in the sense of the [European Digital Identity Regulation] and is implemented within the WE BUILD pilot trust framework rather than the eIDAS production ecosystem (WA1.1, WA1.5; WP4 Blueprint D4.1 §1.2.1). It uses the SD-JWT VC format profiled by [HAIP], OpenID4VCI for issuance and OpenID4VP for presentation per the WE BUILD Conformance Specifications (cs-01, cs-02), and the IETF Token Status List for revocation per the WE BUILD ADR on Attestation Revocation. Escalation to an eIDAS-qualified EAA (QEAA), and any associated QTSP involvement, is a post-pilot decision and out of scope for this version.

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.

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 Approved Supplier attestation expresses a single business relationship: a Buyer's approval of a Supplier. The design models two parties, the approving party (the Buyer, who is also the technical issuer) and the approved supplier (the Supplier, who is the holder/subject), together with the scope and validity of the approval.

Per ARB_12 of [Topic 12], this document defines the attribute attestation_legal_category, which for this attestation type SHALL have the value EAA.

Logical model (informative):

ApprovedSupplierAttestation
├── attestation_legal_category : "EAA"
├── approving_party            (the Buyer, C4, also the issuer)
│   ├── legal_name
│   ├── legal_id               (EUID / LPID, from the Buyer's EBWOID)
│   └── peppol_id              (Peppol participant identifier)
├── approved_supplier          (the Supplier, C1, the holder/subject)
│   ├── legal_name
│   ├── legal_id               (EUID / LPID, from the Supplier's EBWOID)
│   └── peppol_id
├── approval_scope             (code list, see 4.4)
├── approval_valid_from        (date)
└── approval_valid_until       (date; see also the exp metadata claim)

This model refines the flat claim list in the SC5 specification (issuer_id, issuer_name, subject_id, subject_name, scope, approval_date, expiry_date, buyer_peppol_id, supplier_peppol_id) into two grouped party objects, while preserving the same information content.

Sections 3.2 to 3.4 define the attributes and sections 4.1 to 4.3 the metadata. Section 4.4 documents the scope code list and section 4.5 the integrity rules.

Chapter overview and requirements

This chapter defines all attributes and metadata that an Approved Supplier attestation may contain, in an encoding-independent manner (ARB_06 in [Topic 12]). Each attribute is marked mandatory, optional, or conditional in its section (ARB_09).

Applicable legal category. Per SC5 working assumption WA1.1, the Approved Supplier attestation is implemented as a non-qualified EAA for the WE BUILD pilot. A qualification mandate (QEAA) would require QTSP involvement and is treated as a post-pilot decision. Where the SC5 specification refers to a "WE BUILD QEAA", this denotes a technically interoperable, ITB-tested attestation within the pilot trust framework, not an eIDAS-qualified EAA (WA1.5). The requirements for non-qualified EAA in [Topic 12] therefore apply:

• An attribute indicating that the attestation is an EAA SHOULD be included (ARB_12). See section 3.1.
• One or more attributes or metadata representing identification data of the issuer SHALL be included (ARB_15).
• One or more attributes representing the subject SHOULD be included (ARB_17).
• Attributes or metadata representing the validity period SHOULD be defined (ARB_19).
• Attributes or metadata representing the location of the trust anchor SHOULD be defined (ARB_21); see chapter 10.

3.2 Mandatory attributes

3.3 Optional attributes

3.4 Conditional attributes

The Approved Supplier attestation defined in this Rulebook does not contain any conditional attributes.

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

The Approved Supplier attestation defined in this Rulebook does not contain any conditional metadata.

4.4 Code lists

4.5 Integrity rules

5 Formats

5.1 SD-JWT VC-based encoding

This attestation type SHALL be issued in the [SD-JWT VC]-compliant format and SHALL comply with the 'SD-JWT VCs' profile specified in [HAIP] (ARB_01b).

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

(Proposed value; subject to registration in the WE BUILD Attestation Rulebooks catalog by the WP4 semantics group, ARB_05.)

For all claims, the table below specifies whether an Attestation Provider MUST, MAY, or MUST NOT make the claim selectively disclosable (ARB_30). A Type Metadata Document SHOULD be defined for this vct per Chapter 6 of [SD-JWT VC] (ARB_31).

A JSON Schema for this encoding is published in the catalog at data-schemas/sd-jwt/approved-supplier-sd-jwt.json, with sample data at data-schemas/sd-jwt/sample-data/approved-supplier-sd-jwt-sample.json.

Registered / standard claims:

Private claims specific to this attestation type:

Illustrative JWT claim set (informative, synthetic data):

{
  "vct": "eu.we-build:approvedsupplier:1",
  "iss": "https://wallet.lesrosesdor.example/issuer",
  "iat": 1767225600,
  "exp": 1798761600,
  "attestation_legal_category": "EAA",
  "status": { "status_list": { "idx": 412, "uri": "https://status.webuild.example/sc5/approved_supplier" } },
  "cnf": { "jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." } },
  "approving_party": {
    "legal_name": "Les Roses d'Or SARL",
    "legal_id": "FR59120680088",
    "peppol_id": "0009:FR59120680088"
  },
  "approved_supplier": {
    "legal_name": "Green Flowers B.V.",
    "legal_id": "NL853746281B01",
    "peppol_id": "0106:853746281"
  },
  "approval_scope": "peppol:einvoice",
  "approval_valid_from": "2026-01-01",
  "approval_valid_until": "2026-12-31"
}

[RULEBOOK AUTHOR TO PROVIDE AN EXAMPLE OF THE ISSUED SD-JWT IN base64 ENCODING ONCE A REFERENCE ISSUER IS AVAILABLE]

[RULEBOOK AUTHOR TO PROVIDE A HUMAN-READABLE VERSION OF THE SD-JWT PAYLOAD WITH THE DISCLOSURES, ONCE THE SELECTIVE-DISCLOSURE STRUCTURE IS FINALISED WITH WP4]

5.2 ISO/IEC 18013-5-compliant encoding

The Approved Supplier attestation is presented in automated, online, system-to-system flows between European Business Wallets and Access Points (see chapter 9). There is no proximity or offline presentation use case (ARB_02). Therefore an ISO/IEC 18013-5 (mdoc) encoding is not specified in this version. If a future use case requires proximity presentation, a document type and mdoc encoding would be added here.

5.3 W3C Verifiable Credentials Data Model-based encoding

A W3C VCDM encoding is not specified for this attestation type. SD-JWT VC (section 5.1) is the single normative encoding for SC5, consistent with the WE BUILD Conformance Specifications. (Note that only a non-qualified EAA may use the VCDM format, ARB_01a; this attestation is a non-qualified EAA, so a VCDM encoding could be added in future if an interoperability need arises.)

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

7.2 Issuance Policy

Primary use case. SC5 Scenario 1 (Supplier pre-approval). The Supplier (C1) holds the attestation in its EBW and presents it, in a machine-to-machine OpenID4VP flow, to its Access Point (C2) so that C2 can verify the Buyer's approval before transmitting an invoice into the Peppol network.

PID verification (ARB_27). A relying party (C2) does not request or verify a PID. The holder is a legal person, not a natural person; identity assurance is provided by the EBWOID binding (see chapter 10), not by a PID.

Presentation requirements. Presentation is online and system-to-system via OpenID4VP, using DCQL queries as profiled by the WE BUILD Conformance Specification cs-02. There is no human-in-the-loop wallet interaction at runtime (WA1.3). No offline / proximity presentation is supported. Where the relying party is itself an EBW-based system, the Mutual Identification & Consent Handshake defined in [rb-base, Handshake] SHOULD be applied before presentation.

Device binding (ARB_34). An attestation of this type SHOULD be device-bound to the holder's Wallet Unit (the Supplier's EBW), evidenced by the cnf claim and verified through key binding at presentation (base verification step 4.2.8).

Binding to another attestation (ARB_28). An attestation of this type SHOULD be cryptographically bound to the Supplier's organisational identity attestation (EBWOID) on the same Wallet Unit. Where present, the binding metadata identifier SHALL be cryptographically_bound_to, its value SHALL be a string containing the bound attestation's vct, and that value SHALL be uri:eu.ebw.oid.1 (the EBWOID vct defined in [rb-ebwoid]).

Transactional data ([Topic 20]). No payment-authentication transactional data is defined for this attestation type. The attestation authorises a relationship, not an individual payment, so the strong-user-authentication transactional-data mechanism of [Topic 20] does not apply.

The issuer is the Buyer (C4), a legal person self-issuing this EAA through its EBW after having established the commercial relationship with the Supplier outside the wallet system (e.g. via a procurement process). Issuance uses OpenID4VCI as profiled by the WE BUILD Conformance Specification cs-01.

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

In particular, the issuer SHALL include the holder-generated public key (cnf) in the payload, SHALL include its own EBWOID-anchored certificate material in the attestation header (see chapter 10), and SHALL populate the status metadata (see chapter 8) in every issued attestation.

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 Approved Supplier attestation SHALL remain valid only while the underlying commercial approval is in effect. The attestation is revocable (it is not a short-lived ≤24h attestation, since approvals typically persist for the duration of a commercial relationship).

8.1 Revocation mechanism

• Token Status List: the issuer SHALL maintain an active IETF Token Status List ([Token Status List]), aligned with the Attestation Status List mechanism specified by the EU Commission and mandated by the WE BUILD ADR on Attestation Revocation.
• Credential metadata: the status metadata SHALL be populated in every issued attestation with:
• status_list_credential (string, URI), the URI of the Status List Credential containing the status bitstring;
• status_list_index (integer, ≥ 0), the zero-based index into the status list bitstring for this attestation;
• status_purpose (string), SHALL be revocation.
• Authorized authority: only the issuing Buyer (the self-issuing legal entity) may modify the status list entry.

8.2 Revocation triggers and business rules

• Issuer trigger (obligation): the Buyer SHALL revoke the attestation without undue delay when the underlying commercial relationship ends, when the approval scope no longer applies, or when the Supplier's identity data becomes inaccurate.
• Relying Party action: a revoked or suspended attestation SHALL be treated as invalid; C2 SHALL reject invoice submissions relying on it. The business interpretation of a revocation (e.g. grace handling for invoices already in flight) is determined by the Relying Party's internal policies.

9 Presentation

Base Verification Process

The Relying Party SHALL perform the base attestation verification process for EAAs 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

This covers verification of attestation authenticity and issuer identity via the EBWOID chain (4.2.2–4.2.4), validity periods (4.2.5), revocation status (4.2.6), wallet integrity via the WUA (4.2.7), and holder key binding (4.2.8).

Validate attestation-specific integrity rules

In addition to the base verification, the Relying Party SHALL apply the integrity rules IR-AS-01 to IR-AS-03 defined in section 4.5. In particular (IR-AS-03), C2 SHALL match the attestation's approved_supplier.peppol_id and approving_party.peppol_id against, respectively, the sender and buyer participant identifiers of the invoice in flight, and SHALL reject the invoice submission on mismatch.

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:

When receiving and processing an Approved Supplier attestation, the Relying Party (C2) SHALL perform the following verification obligations.

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

This chapter specifies how a Relying Party establishes trust in the issuer of an Approved Supplier attestation. The corresponding verification procedures are steps 4.2.2–4.2.4 of the Base Verification specification.

The Approved Supplier attestation is an EAA self-issued by a legal entity (the Buyer). Buyers are not, and cannot practically be, individually registered on a Trusted List. Trust is therefore established through a cryptographic chain anchored in the issuer's EBWOID, following the common WE BUILD EAA trust model:

• The issuer's EBWOID SHALL be included in the header of every issued Approved Supplier attestation. During EBWOID issuance, the EBWOID provider verifies that the public key contained in the EBWOID is owned by the EBW owner.
• The Relying Party SHALL verify the EBWOID in accordance with [rb-ebwoid] and the Base Verification specification. The EBWOID provider's trust anchor is obtained via the WE BUILD trust list infrastructure (TLOL) operated under WP4.
• Upon successful verification, the Relying Party obtains: assurance that the EBWOID was issued by an authorised provider (and is not self-issued); the verified identity of the issuer, including its legal name and EUID; and the public key authorised to verify the attestation signature.
• The Relying Party SHALL then confirm that the verified issuer identity (EUID) matches approving_party.legal_id in the attestation payload.

Authorization of the issuer as a Buyer is subsequently determined in accordance with the Relying Party's internal policies (e.g. C2 confirming that the approving party is a registered Peppol participant it can route to), optionally supported by domain-specific trust list services.

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