EAASD-JWT VC

Attestation Rulebook for attestations of type Boarding Pass

Category: non-qualified EAA

[Based on the WE BUILD Attestation Rulebook Template and the Ferry Boarding Pass Attestation model.]

• Author(s):
  • Nikos Triantafyllou, UAegean
• Previous Authors
  • N/A

Feedback:

• Github, portal, email, Slack

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 Ferry Boarding Pass Attestation for use in the European Digital Identity Wallet ecosystem.

The Ferry Boarding Pass Attestation expresses the real-world fact that a natural person holds a valid boarding pass for a specific ferry journey and is entitled to board a specific vessel at a given departure date and time.

The attestation is intended to be issued by an authentic source, such as a ferry operator or an authorised ticketing system acting on behalf of the ferry operator. The Holder is the passenger to whom the boarding entitlement applies. Relying Parties include ferry operators, port boarding gates, authorised boarding control staff, and other authorised systems that need to verify boarding entitlement.

In practical terms, the attestation enables a passenger to present proof of boarding entitlement through an EUDI Wallet. It can reduce reliance on paper tickets and can reduce the need for real-time backend lookups during boarding, provided that the Relying Party can verify the issuer, the signature, the validity period, and the relevant journey details.

The attestation supports ferry boarding use cases, including online or offline verification at ports and boarding gates. It contains journey-specific and passenger-specific information strictly related to the boarding process, including passenger name, ticket identifiers, departure and arrival information, vessel information, and seat allocation where applicable.

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.

In addition, the following domain-specific terms are used:

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 is designed to align with the EUDI Wallet architectural approach for Electronic Attestations of Attributes and with the Attestation Rulebook structure defined in the ARF.

The Rulebook supports the following compliance objectives:

• it defines the attestation purpose and scope;
• it defines mandatory, optional, and conditional attributes in an encoding-independent manner;
• it defines a legal category indication through attestation_legal_category;
• it defines an SD-JWT VC vct value for the attestation type;
• it defines issuer, validity, and status metadata needed for verification;
• it defines code lists and integrity rules required for consistent interpretation;
• it defines how trust anchors can be obtained and used;
• it defines expiry and revocation expectations;
• it supports selective disclosure and data minimisation.

This Rulebook does not define a qualified EAA or public-sector EAA profile. It also does not define ISO/IEC 18013-5 mdoc or W3C VCDM encodings in 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 Ferry Boarding Pass Attestation is defined as a non-qualified Electronic Attestation of Attributes unless a future version of this Rulebook explicitly defines a qualified or public-sector legal category.

The attribute attestation_legal_category SHALL be included and SHALL have the value non-qualified-EAA.

The attestation model consists of the following logical groups:

• passenger identification data;
• ticket identifiers;
• journey details;
• vessel and port information;
• issuer information;
• credential metadata.

The attestation is bound to a single passenger and a single ferry journey. It SHALL NOT be treated as a reusable credential after the scheduled departure time.

Chapter overview and requirements

This chapter defines the attributes and metadata that a Ferry Boarding Pass Attestation may contain. The attributes are defined in an encoding-independent manner. Each attribute is classified as mandatory, optional, or conditional.

The Ferry Boarding Pass Attestation is journey-specific and time-bound. It contains only the information necessary to verify that the Holder is entitled to board a specific ferry service. The attribute set is intentionally limited to support data minimisation.

3.2 Mandatory attributes

3.3 Optional attributes

3.4 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

4.4 Code lists

4.5 Integrity rules

5 Formats

5.1 SD-JWT VC-based encoding

The Ferry Boarding Pass Attestation SHALL be issued as an SD-JWT VC.

The Verifiable Credential Type (vct) for this attestation type is:

urn:eu.europa.ec.eudi:ferry_boarding_pass:1

The credential claims defined in this section SHALL follow SD-JWT VC and HAIP conventions where applicable. Claim names are either IANA-registered JWT claims, public names, or private names specific to this attestation type.

For all claims, this Rulebook specifies whether an Attestation Provider MUST, MAY, or MUST NOT make the claim selectively disclosable.

5.1.1 IANA-registered and standard JWT / SD-JWT VC claims

5.1.2 Public or reusable claims

5.1.3 Private claims specific to the Ferry Boarding Pass Attestation

5.1.4 Example JWT claim set

{
  "iss": "https://issuer.example-ferry.gr",
  "iat": 1780315200,
  "nbf": 1780315200,
  "exp": 1781508600,
  "jti": "urn:uuid:1ddcf8dc-3f0b-4b30-987d-5eacb9dba111",
  "vct": "urn:eu.europa.ec.eudi:ferry_boarding_pass:1",
  "attestation_legal_category": "non-qualified-EAA",
  "identifier": "BP-2026-000123456",
  "ticketQR": "M1_FASTFERRIES_20260615_000123456",
  "ticketNumber": "000123456",
  "ticketLet": "A",
  "firstName": "Nikos",
  "lastName": "Triantafyllou",
  "seatType": "AIR_SEAT",
  "seatNumber": "12A",
  "departureDate": "2026-06-15",
  "departureTime": "07:30",
  "arrivalDate": "2026-06-15",
  "arrivalTime": "12:45",
  "arrivalPort": "GRMLO",
  "vesselDescription": "Fast Ferries Andros",
  "issuer": {
    "issuing_country": "GR",
    "issuing_organisation": "Fast Ferries S.A.",
    "issuing_date": "2026-06-01"
  },
  "trust_anchor": "https://trust.example.eu/ferry/operators/fast-ferries",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "...",
      "y": "..."
    }
  }
}

5.1.5 Example issued SD-JWT

The following is a non-normative placeholder example. A production SD-JWT SHALL be generated by the issuer using the applicable signing algorithm, disclosure construction, holder binding, and SD-JWT VC rules.

<issuer-signed-sd-jwt>~<disclosure-1>~<disclosure-2>~<disclosure-n>~<holder-binding-jwt>

5.1.6 Example human-readable disclosed payload

A verifier that requests the minimum data needed for boarding may receive a presentation disclosing the following claims:

{
  "vct": "urn:eu.europa.ec.eudi:ferry_boarding_pass:1",
  "identifier": "BP-2026-000123456",
  "ticketNumber": "000123456",
  "firstName": "Nikos",
  "lastName": "Triantafyllou",
  "departureDate": "2026-06-15",
  "departureTime": "07:30",
  "arrivalDate": "2026-06-15",
  "arrivalTime": "12:45",
  "arrivalPort": "GRMLO",
  "vesselDescription": "Fast Ferries Andros"
}

The issuer identity, credential type, expiry time, signature, holder binding proof, and trust anchor information are not treated as selectively disclosable passenger attributes and SHALL remain available to the verifier for technical validation.

5.2 ISO/IEC 18013-5-compliant encoding

This version of the Rulebook does not define an ISO/IEC 18013-5 mdoc encoding for the Ferry Boarding Pass Attestation.

The Ferry Boarding Pass Attestation defined in this Rulebook is specified for SD-JWT VC-based issuance and presentation. If a future version of this Rulebook defines an ISO/IEC 18013-5-compliant mdoc representation, that version SHALL define a unique document type, namespaces, attribute identifiers, CBOR encoding rules, and illustrative mdoc examples.

5.3 W3C Verifiable Credentials Data Model-based encoding

This version of the Rulebook does not define a W3C Verifiable Credentials Data Model encoding for the Ferry Boarding Pass Attestation.

If a future version defines a W3C VCDM representation, that version SHALL define the credential context, type, credential subject structure, proof type, selective disclosure mechanism, and presentation requirements.

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 Ferry Boarding Pass Attestation is intended for verifying passenger boarding entitlement for a specific ferry journey.

Typical usage scenarios include:

• presentation by the passenger at a port or boarding gate;
• scanning or digital verification by authorised boarding staff;
• online verification by a ferry operator system;
• offline or low-connectivity verification where the verifier can validate the credential signature, issuer, validity period, and disclosed journey data without relying on a real-time ticketing backend.

A Relying Party receiving the attestation SHALL verify:

• the issuer signature;
• the SD-JWT VC type (vct);
• the issuer authorisation to issue Ferry Boarding Pass Attestations;
• the credential validity period;
• the credential status, where a status mechanism is present;
• holder binding, where used;
• the integrity rules defined in Section 2.9;
• that the journey details match the boarding context.

The Relying Party SHOULD request and verify PID or another accepted identity credential when the boarding process requires passenger identity matching. In such cases, the Relying Party SHOULD compare the relevant identity attributes, such as passenger name, with the Ferry Boarding Pass Attestation. The Relying Party SHALL apply data minimisation and SHALL request only the attributes required for the boarding decision.

The attestation SHOULD be device-bound through holder binding where supported by the EUDI Wallet and the applicable SD-JWT VC profile. The attestation MAY be cryptographically bound to a PID or another accepted identity attestation where the boarding process requires stronger passenger identity matching. Where this binding is used, the metadata attribute cryptographically_bound_to SHOULD contain:

urn:eudi:pid:1

No payment-specific transactional data is defined by this Rulebook. If the Ferry Boarding Pass Attestation is used as part of a transaction that also involves payment, payment-related requirements SHALL be defined in a separate payment attestation, payment profile, or transaction-specific rulebook.

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

The Ferry Boarding Pass Attestation is typically short-lived and journey-specific.

The preferred validity model for this attestation is short validity. The credential expiration time (exp) SHALL be set no later than the scheduled departure time unless a clearly defined operational grace period is required by the ferry operator or port boarding process.

After departure, the attestation SHALL be considered expired and SHALL NOT be accepted for boarding.

Revocation MAY be handled by one or more of the following mechanisms:

• short validity, where the attestation expires at or before departure time;
• backend verification by the ferry operator or authorised boarding system;
• an attestation status list mechanism, where supported;
• an attestation revocation list mechanism, where supported.

If a status or revocation mechanism is included in the credential, the Relying Party SHALL check the status before accepting the attestation, unless offline operating rules explicitly allow deferred status checking.

If a ticket is cancelled, refunded, exchanged, duplicated, or otherwise invalidated before departure, the issuer SHOULD either revoke or suspend the attestation, or ensure that backend verification detects the invalid state.

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:

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

A Relying Party SHALL verify that the issuer of the Ferry Boarding Pass Attestation is authorised to issue this attestation type.

For non-qualified EAA deployments, the Relying Party SHOULD obtain trust anchor information through one or more of the following mechanisms:

• a machine-readable trust list or trust registry used by the relevant ecosystem;
• an issuer metadata endpoint published by the ferry operator or authorised ticketing operator;
• a trust framework entry managed by the WE BUILD ecosystem or by another authorised governance body;
• a pilot trust list used for controlled interoperability testing.

Where the metadata attribute trust_anchor is present, it SHOULD identify the location or registry entry from which the Relying Party can obtain the issuer trust anchor or issuer authorisation information.

The Relying Party SHALL use the trust anchor to verify that:

• the issuer signing key or certificate chains to a trusted authority or registered trust anchor;
• the issuer is authorised to issue the urn:eu.europa.ec.eudi:ferry_boarding_pass:1 attestation type;
• the issuer metadata or trust framework entry has not expired or been revoked;
• the issuer identity in the credential is consistent with the issuer identity in the trust framework.

Wallet Units MAY also use the same trust framework information during issuance to determine whether the provider is authorised to issue this attestation type.

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