EAASD-JWT VC

Attestation Rulebook for attestations of type Loyalty Card

Category: non-qualified EAA

[Based on the WE BUILD Attestation Rulebook Template and the Ferry Loyalty Card 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 Loyalty Card Attestation for use in the European Digital Identity Wallet ecosystem.

The Ferry Loyalty Card Attestation expresses the real-world fact that a natural person is a registered customer of a ferry operator and participates in that operator's loyalty or frequent traveller programme. It proves the existence and validity of a loyalty card issued by, or on behalf of, a ferry operator.

The attestation is intended to be issued by an authentic source, such as a ferry operator or an authorised customer-management or ticketing system acting on behalf of the ferry operator. The Holder is the registered customer to whom the loyalty card applies. Relying Parties include ferry operators, authorised ticketing systems, customer-service systems, booking portals, port services, and other authorised partners that need to verify customer loyalty status or customer identity information for a legitimate service purpose.

In practical terms, the attestation enables a customer to present loyalty-card information through an EUDI Wallet. It can support customer identification, service personalisation, loyalty benefits, journey-related discounts, and reduced reliance on physical loyalty cards or account lookups.

The attestation contains customer, loyalty-card, organisation, and credential metadata. Because it is intended for repeated use across multiple journeys, it is longer-lived than a boarding pass and SHALL support revocation or status checking where operationally required.

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;
• it recognises the reusable nature of the loyalty-card attestation and therefore recommends status or revocation support.

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 Loyalty Card 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:

• customer information;
• loyalty-card information;
• organisation information;
• credential metadata.

The attestation is bound to a single registered customer and a single loyalty-card record issued by a specific ferry operator or authorised operator system. It MAY be presented repeatedly, subject to validity, expiry, and revocation rules.

Chapter overview and requirements

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

The Ferry Loyalty Card Attestation is a reusable, customer-specific attestation. It is not bound to a single journey. Its attribute set is designed to support customer identification, loyalty-card verification, and controlled disclosure of optional customer information.

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 Loyalty Card 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_loyalty_card: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 Loyalty Card Attestation

5.1.4 Example JWT claim set

{
  "iss": "https://issuer.example-ferry.gr",
  "iat": 1767787200,
  "nbf": 1767787200,
  "exp": 1830859200,
  "jti": "urn:uuid:ec622e9e-23f8-4c1d-9985-5c5b088caa11",
  "vct": "urn:eu.europa.ec.eudi:ferry_loyalty_card:1",
  "attestation_legal_category": "non-qualified-EAA",
  "customer": {
    "first_name": "Nikos",
    "last_name": "Triantafyllou",
    "nationality": "GR",
    "birth_date": "1985-04-12",
    "city": "Athens",
    "email": "nikos@example.com",
    "mobile": "+306901234567"
  },
  "loyalty_card": {
    "id": "LC-FAST-000123456",
    "issue_date": "2026-01-07"
  },
  "organization": {
    "name": "Fast Ferries S.A.",
    "id": "GR-FAST-FERRIES",
    "country": "GR"
  },
  "credential": {
    "type": "FerryLoyaltyCardAttestation",
    "issuer": "https://issuer.example-ferry.gr",
    "issuance_date": "2026-01-07",
    "expiry_date": "2028-01-07"
  },
  "trust_anchor": "https://trust.example.eu/ferry/operators/fast-ferries",
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "...",
      "y": "..."
    }
  },
  "status": {
    "status_list": {
      "idx": 12345,
      "uri": "https://issuer.example-ferry.gr/status/loyalty-card-status-list.jwt"
    }
  }
}

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 needs only to confirm loyalty-programme participation may receive a presentation disclosing the following claims:

{
  "vct": "urn:eu.europa.ec.eudi:ferry_loyalty_card:1",
  "customer": {
    "first_name": "Nikos",
    "last_name": "Triantafyllou"
  },
  "loyalty_card": {
    "id": "LC-FAST-000123456",
    "issue_date": "2026-01-07"
  },
  "organization": {
    "name": "Fast Ferries S.A.",
    "id": "GR-FAST-FERRIES",
    "country": "GR"
  }
}

A verifier that needs contact details for a customer-service interaction MAY request additional selectively disclosable claims such as customer.email or customer.mobile, provided those claims are necessary for the interaction and the Holder consents to disclosure.

The issuer identity, credential type, expiry time, signature, holder binding proof, status information, and trust anchor information are not treated as selectively disclosable customer 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 Loyalty Card Attestation.

The Ferry Loyalty Card 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 Loyalty Card 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 Loyalty Card Attestation is intended for verifying a customer's loyalty-programme membership and, where necessary, selected customer information.

Typical usage scenarios include:

• presentation by the customer during online ferry booking;
• presentation at a ticket office or customer-service point;
• verification of loyalty-card membership for customer benefits or discounts;
• customer identification for service personalisation;
• controlled disclosure of optional contact or residency information where required for a specific service interaction;
• repeated presentation across multiple journeys, subject to validity and revocation checks.

A Relying Party receiving the attestation SHALL verify:

• the issuer signature;
• the SD-JWT VC type (vct);
• the issuer authorisation to issue Ferry Loyalty Card Attestations;
• the credential validity period, where defined;
• the credential status, where a status mechanism is present;
• holder binding, where used;
• the integrity rules defined in Section 2.9;
• that the loyalty-card and organisation details match the service context.

The Relying Party SHOULD request and verify PID or another accepted identity credential when the service requires stronger customer identity matching. In such cases, the Relying Party SHOULD compare the relevant identity attributes, such as customer name, with the Ferry Loyalty Card Attestation. The Relying Party SHALL apply data minimisation and SHALL request only the attributes required for the specific loyalty or customer-service 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 relying-party process requires stronger customer 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 Loyalty Card Attestation is used as part of a transaction that also involves payment or discounts, payment-related requirements SHALL be defined in a separate payment attestation, payment profile, discount rulebook, 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 Loyalty Card Attestation is intended for repeated use and is typically longer-lived than a boarding pass.

The credential SHALL be considered invalid when:

• the credential.expiry_date has been reached, where present;
• the technical expiry timestamp exp has been reached, where present;
• the credential has been revoked or suspended by the issuer;
• the underlying loyalty-card record has been cancelled, replaced, closed, or otherwise invalidated.

Revocation SHOULD be supported for this attestation type because loyalty-card status may change before the declared expiry date.

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

• an attestation status list mechanism, where supported;
• an attestation revocation list mechanism, where supported;
• backend verification by the ferry operator or authorised customer-management system;
• short or medium validity periods combined with re-issuance, where appropriate for the operational model.

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 loyalty card is cancelled, replaced, or suspended, the issuer SHOULD 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 Loyalty Card 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 customer-management system;
• 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_loyalty_card: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;
• the organisation information disclosed in the credential is consistent with the issuer's authorisation scope.

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