Skip to content

Identity & attestation management#

Part of the LDT Governance and Trust Framework — instantiates the iSHARE Data Space Template block Identity & attestation management (© iSHARE Foundation, see Legal notices).

Purpose#

Establish who participants are and what may be claimed about them: identifiers, credentials, issuance, verification and lifecycle.

LDT instantiation — drafted by iSHARE (with FHC, iLabs)#

  • Legal-entity identifiers: the Satellite verifies legal entities by a registered identifier (EORI, or EUID where no EORI exists); DIDs supported where wallet flows require them. Open: the party-identifier decision (iSHARE DID as key, EUID/EORI associated) is open with TIPS (PD4 Table 3, target M8).
  • Credential format: W3C Verifiable Credentials with OpenID4VC issuance/presentation — aligned with eIDAS 2.0; JSON-LD data models; iSHARE credential schemas (schemas.ishare.eu) as the base.
  • Wallets: organisational wallets for participants; the Aruba Airport flows (FHC/Qwihi) pioneer wallet-based credentials for operational staff/processes; ITB-S identity modules (WP2) validate all flows — note: gated by the WP4 T4.1 baseline.
  • Issuance & trust anchors: the Satellite (iSHARE Foundation) issues the Participant Credential into the participant’s own wallet; CO₂ evidence credentials are issued by accredited issuers per credential type (see below); the iSHARE Participant Registry is the scheme’s only authoritative trust anchor; revocation via IETF Token Status Lists + Participant Registry state.
  • PKI: iSHARE-recognised eIDAS trust lists / PKI profiles for transport security.

Credential issuers and wallets (PD4 §3–4)#

Each accredited issuer operates its own issuance service, or uses issuance infrastructure provided by iLabs as technical operator (processor) while remaining the issuer of record. Wallets are organisational wallets held and controlled by the participants; there is no central wallet infrastructure. iLabs tests and does not certify; it issues no CO₂ or Participant Credentials and provides no organisational wallets, so that its testing stays neutral.

Multiple credential issuers. The scheme keeps a register of accredited issuers per credential type and methodology version, under TIPS change control. An issuer is listed after a passing ITB-S conformance report and a methodology review, and is suspended or delisted through the same procedure. Initial issuers each cover their own credential type: LogiNex for transport-chain emissions, FHC Corp for Aruba Airport operations, Almelo Energie for Positive Energy District energy and avoided emissions, and the cities for public-sector attestations. Five rules apply to all issuers:

  1. No double counting: every CO₂ credential carries a unique measurement identifier, references the credentials it builds on, and may not cover emissions already covered in its own chain.
  2. Published types: credential types, schemas and methodology versions are published in the scheme’s type registry.
  3. Liability and revocation: each issuer is liable for the content of its credentials and follows the scheme’s revocation and key-compromise procedure.
  4. Status lists: each issuer publishes an IETF Token Status List meeting the scheme’s availability requirement.
  5. Evidence class: every credential states its evidence class (self-declared, measured, third-party verified).

Relying parties accept any accredited issuer for the credential type they require; the Marketplace publishes accepted credential types, not named issuers. A Marketplace badge states exactly what was verified. A verified emissions reduction is evidence, not a certified or tradable carbon credit; any ownership, transfer or retirement of credits would require its own agreed process and legal conditions.

Multiple wallets. Participants choose their own organisational wallet. Any wallet is accepted that passes the ITB-S suite for the pinned wallet profile (HAIP: SD-JWT VC, OpenID4VCI 1.0, OpenID4VP 1.0 with DCQL, holder key binding, wallet attestation). The scheme publishes a list of conformance-tested wallets; during the pilot this includes the FHC/Qwihi wallet for Aruba, the EUDI reference wallet and a conformant test holder, and participants without an organisational wallet are supplied with one of these. Once the proposed European Business Wallet regulation is adopted and applies, conformant business wallets are accepted on the same basis. Issuers must support every listed wallet.

Wallet and verification process. The Participant Credential establishes scheme participation; the CO₂ evidence credential is signed by the accredited issuer and presented by the holder, in full or as selected claims, to an authorised recipient. A verifier checks issuer accreditation, credential type, signature, validity, relevant claims and status under the agreed refresh policy; once an accepted status check has expired, a failed refresh is not treated as successful verification. The parties document who may issue, present, verify, correct, revoke or replace credentials and how these actions are logged.

ITB-S identity test profile (PD4 §3)#

iLabs operates an instance of the EC Interoperability Test Bed with test suites for credential issuance (OpenID4VCI 1.0), presentation (OpenID4VP 1.0 with DCQL), SD-JWT VC validation (ES256, holder key binding), status checking (IETF Token Status List) and iSHARE machine-to-machine token flows. A passing conformance report is required before a component moves to APPROVED and before a participant goes live, and is re-run on every release. Reports are stored per component in the governance repository.

Test environment. Testing uses synthetic organisational participants on test domains, test identifiers, a conformant test holder wallet and multi-factor authentication for human users. Test and production keys are strictly separated; no production or personal data is used in the sandbox. Status on 14 October 2026: the issuer side of the pilot profile was live on the iLabs test environment, publishing OpenID4VCI 1.0 issuer metadata with a test credential configuration (dc+sd-jwt, ES256, holder key binding).

Source: PD4 v1.0 §3 and §4 — text as in PD4 v0.95_merged (28 Oct 2026).

🧩 Building block requested — Owner: FHC Corp (with Qwihi)#

What we need: the Aruba wallet & VC issuance flows: credential types for airport roles, issuance ceremony, verification points in the operational process, and revocation handling — as a worked example other sites can replicate.

Format: Markdown section in this page (merge request) · Due: 26 Sep 2026 (v0.5) · Status: OPEN

🧩 Building block requested — Owner: iLabs#

What we need: the ITB-S identity-module test profile: which credential exchanges are tested, pass criteria, and how conformance evidence is published to the registry.

Format: Markdown section in this page (merge request) · Due: 26 Sep 2026 (v0.5) · Status: OPEN

Guiding questions#

All 23 of the template's questions for this block, with the 5 LDT answer slots to fill, are on identity-and-attestation-management/guiding-questions.md. The digest below is the subset that most shapes this block.

  • Which identifiers (EORI, VAT, DID) are accepted; is eIDAS-compliance mandatory or one of several schemes; is PKI relied upon?
  • Which credential types are needed for onboarding (identity, membership, compliance) and how are validity, renewal and revocation managed?
  • Centralised or federated issuance; how does verification align with eIDAS/ETSI trust lists with automated status checks?
  • How are mergers/closures reflected in credential records, and what is the escalation path for identity disputes?

PD4 mapping#

Feeds PD4 v1.0 §3 (Satellite, ITB-S, issuance infrastructure) and §4 (multiple credential issuers, multiple wallets, verification process).