EAAmdoc

Attestation Rulebook for attestations of type eCMR

Category: non-qualified EAA

Author(s): - Christophe DANNA, IN Groupe - Mohamed OULMAHDI, IN Groupe - Heiti MERING, Digilogistika Keskus

Reviewer(s) - [to be added] when passing to V0.7

Version History

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

The eCMR Attestation is a verifiable electronic attestation designed to provide trusted, portable and interoperable evidence of an Electronic Consignment Note (eCMR) within the EUDI Wallet ecosystem. The attestation is issued by a trusted eCMR platform and enables transport stakeholders and competent authorities to verify the authenticity, integrity and provenance of transport information. The eCMR attestation issued to a company and presented by the driver with its EBW is a multi-purposes attestation: - Link to eCMR, used to give access only to the right consignment data (MVP); - The document itself for offline presentation by the driver (PDF, MVP+); - eFTI QR Code for roadside checks by authorities (via eFTI network, MVP+).

The attestation expresses the existence of a valid eCMR and establishes a trusted link between:

• The transport consignment;
• The issuing eCMR platform;
• The identified business parties involved in the transport operation;
• The evidence document associated with the transport operation.

The attestation supports:

• Roadside inspections;
• Cross-border freight transport operations;
• Logistics ecosystem interoperability;
• Future eFTI integration scenarios;
• Both online and offline (MVP+) verification processes.

The primary actors are:

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 terms used in this document:

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.

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 eCMR Attestation SHALL be issued exclusively as an ISO/IEC 18013-5 compliant mDoc. The workshop concluded that mDoc is the preferred format because it supports proximity presentation, offline verification and compatibility with EUDI Wallet requirements.

The attestation provides:

• Identification of a specific transport consignment;
• Trusted identification of involved business parties through EBWOIDs;
• Integrity protection of transport information;
• Support for both online and offline verification scenarios;
• Support for human-readable document presentation when required by national regulations.

The attribute attestation_legal_category SHALL indicate the legal classification of the attestation. This attestation type is classified as "EAA" within the EBW Wallet ecosystem, as it is typically issued by an eCMR platform and no authentic source is used.

All attributes and metadate SHALL be disclosable.

3.2 Mandatory attributes

3.2.1 Consignment identification

• The issuing eCMR platform can freely use whatever content needed to identify the consignment and its eCMR. On purpose, already defined Id fields in UN/CEFACT Electronic Road Consignment Note (eCMR)are not used [UN/CEFACT eCMR].

3.3 Optional attributes

Optional attributes are the eFTI Information and a human readable eCMR (MVP+).

3.3.1 eFTI information (MVP+)

eFTI Unique Information Link.

Note1: at the present time, the naming rule for eFTI platform and gate identifiers has not been defined yet by the eFTI technical guidance documents. Examples are fictional.

Note2: Other fields might be considered whith MVP+ scenario and added later if needed. - QR Code image could be added later if needed. - XML MMT file (base64).

3.3.2 Human readable eCMR (MVP+)

Note: no embedded transport dataset representation, only a human readable document

These attributes must be present when offline verification or human-readable presentation is required. Optional in MVP, mandatory in MVP+.

3.4 Conditional attributes

3.4.1 Parties identification (MVP)

Note: At least One ebwoid SHALL be included in the attestation, depending on the step reached in process.

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

None

4.3 Conditional metadata

None

4.4 Code lists

4.5 Integrity rules

5 Formats

5.1 SD-JWT VC-based encoding

SD-JWT is out of scope for this rulebook, as offline proximity is required.

5.2 ISO/IEC 18013-5-compliant encoding

The eCMR Attestation SHALL be issued exclusively as an ISO/IEC 18013-5 compliant mDoc. This format supports:

• Device-to-device proximity presentation;
• Offline verification;
• Integration within the EUDI Wallet ecosystem;
• Embedded transport evidence;
• Selective disclosure mechanisms.

docType "eu.webuildconsortium.ecmr.attestation.V1

Namespace "eu.webuildconsortium.ecmr.attestation.V1

Illustrative example

Example for MVP scenario (mandatory fields only). See clarification about MVP and MVP+ scenarios in section 1.1 Document scope and purpose .

{
  "docType": "eu.webuildconsortium.ecmr.attestation.V1",
  "issuerSigned": {
    "namespaces": {
      "eu.webuild.ecmr.attestation.1": [
        {"elementIdentifier": "attestation_legal_category", "elementValue": "non-qualified-EAA"},
        {"elementIdentifier": "trust_anchor_url", "elementValue": ""},
        {"elementIdentifier": "attestation_scheme", "elementValue": "TBD"},
        {"elementIdentifier": "consignment_identifier", "elementValue": "CMR-2026-000123"},
        {"elementIdentifier": "ecmr_platform_url", "elementValue": "https://platform.example.eu/ecmr/CMR-2026-000123"},
        {"elementIdentifier": "issuer_ebwoid", "elementValue": "EU.ebwoid.12345678"},
        {"elementIdentifier": "carrier_ebwoid", "elementValue": "EU.ebwoid.87654321"},
        {"elementIdentifier": "consignor_ebwoid", "elementValue": "EU.ebwoid.11223344"},
        {"elementIdentifier": "consignee_ebwoid", "elementValue": "EU.ebwoid.11789463"},
        {"elementIdentifier": "expiry_date", "elementValue": "2026-07-30T00:00:00Z"},
        {"elementIdentifier": "issuance_date", "elementValue": "2026-06-30T10:25:00Z"}
      ]     
    }    
}

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

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

The eCMR attestation is issued and managed by an eCMR platform throughout the transport lifecycle. - The platform creates the initial eCMR and generates a unique identifier linked to the consignment. - Pickup and delivery activities are initiated and managed through the platform using Business Wallet authentication. - The eCMR platform issues updated eCMR version. - The eCMR platform revoke the older eCMR Attestation when a new version is issued.

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

A balance between security and usability must be found: - Short-lived (24 hours) needs re-issuance / renewal by the issuer. ECMR lifecycle is much longer than one day. - Status List or revocation List requires internet access to retrieve trusted lists. Maintaining a cached copy of the trusted list and revocation information, updated regularly, may enable offline verification (MVP+).

The eCmr Platform (self-issuing entity) SHALL immediately update or revoke its EAA eCMR Attestation when a new version is issued. Nonetheless, the expiracy date SHALL always be set, especially when the eCMR is not the final one.

Note: WeBuild IETF Token Status List SHOULD be used to perform revocation checks to validate credentials.

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:

The relying party, typically a competent authority, receives the eCMR attestation presented through the Business Wallet. Where available, the relying party extracts the eFTI UIL from the eCMR attestation. The UIL is used to submit a query through the national eFTI Gate to locate the authoritative dataset. In offline situations, verification may rely solely on the wallet-based presentation

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 model relies on:

• Trusted eCMR platform issuers;
• Business Wallet identities;
• ebwoid-based legal entity identification;
• Cryptographically signed attestations.

Each participating organisation SHALL possess a Business Wallet containing an ebwoid identifying both its legal and technical identity.

The trust chain SHALL enable verification of:

1. The attestation signature.
2. The issuing eCMR platform.
3. The identified legal entity.
4. The associated trust anchor.

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 (eCMR Platform) SHALL verify the EBWOID. 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.

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