Skip to content

Guiding questions — Identity & attestation management#

Fork notice. The questions below are reproduced from the iSHARE Data Space Template page Identity & attestation management → Guiding questions — © iSHARE Foundation, used under the EUTwinLink Consortium Agreement (see Legal notices). The template's question text is carried over unchanged so this fork stays comparable to its upstream.

Everything between the LDT answer markers is the EUTwinLink instantiation — that is what partners fill in. Decisions already taken live on the block page: Identity & attestation management.

Building block T4 · owner(s) iSHARE + FHC Corp + iLabs · due 26 Sep 2026 · block status DRAFTED · see the Building-block register.

Answer provenance. Every answer below is tagged with where it comes from, because a governance scheme that cannot be traced is not a governance scheme:

  • Decided — already fixed by the Grant Agreement, the Consortium Agreement or a recorded decision elsewhere in this scheme. Change it only through the change procedure.
  • Proposed — a defensible default, derived from the iSHARE Trust Framework, the DSSC Blueprint and the decisions this scheme has already taken. Drafted for the owner to confirm, correct or reject at TIPS. It is not an agreed position until TIPS approves it.
  • Needs owner — cannot be answered without the named owner: a fact about their systems, their legal position or their commercial intent. The text states what is needed and why.

Open points across the whole scheme are collected in Open questions for partners.

1. Participant Identification#

Purpose: Define how legal entities and representatives will be uniquely and reliably identified.

  • What identifiers (EORI, VAT ID, DUNS, DID, etc.) will be accepted for legal entities?
  • How will natural persons be identified and cryptographically bound to their role as authorised representatives of legal entities (e.g., Verifiable Credentials such as W3C/OpenID?
  • Will eIDAS-compliant solutions be mandatory, optional, or one of several supported schemes?
  • Will authentication rely on PKI?

LDT answer DRAFTED · owner: iSHARE + FHC Corp + iLabs · due 26 Sep 2026

Decided Legal entities are identified by a registered identifier — EORI, or EUID where no EORI exists — with DIDs supported where wallet flows require them; the party-identifier decision (iSHARE DID as key, EUID/EORI associated) is open with TIPS (PD4 Table 3, target M8). DUNS is not adopted — it adds a commercial dependency for no gain over EORI/EUID in this scheme's jurisdictions.

Decided Natural persons are bound to their role as authorised representatives through W3C Verifiable Credentials issued over OpenID4VC — the organisation's credential attests the entity, a representative credential attests the person's authority to act for it, and the cryptographic binding is the credential holder's key. The Aruba Airport flows (FHC with Qwihi) are the LDT's pioneer implementation of exactly this, for operational staff and processes.

Proposed eIDAS is mandatory where it applies and one of several schemes where it does not. For EU participants, eIDAS 2.0 alignment is the baseline. Aruba is outside the EU, so the scheme cannot require eIDAS of it and must accept an equivalent anchored by iSHARE Foundation — which is precisely why the Aruba case is the scheme's test rather than its exception.

Decided PKI is relied upon for transport security, using iSHARE-recognised eIDAS trust lists and PKI profiles. Credential trust is VC-based, not PKI-based; the two layers are separate and PD4 should not merge them.

2. Credential Types & Attestations#

Purpose: Establish the credentials and attestations required for onboarding, compliance, and sector-specific participation.

  • Which credential types are required for onboarding (identity, membership, compliance)?
  • Will W3C/OpenID Verifiable Credentials be the primary format for organisational identity and representative roles?
  • What sector-specific or regulation-driven attestations will participants need to provide?
  • Will conformity assessments based on ISO/IEC 17000 be recognised for certain claims/attestations?
  • How will validity periods, renewals, and revocations be managed?

LDT answer DRAFTED · owner: iSHARE + FHC Corp + iLabs · due 26 Sep 2026

Proposed Credential types the LDT needs at onboarding and in operation:

Credential Attests Issued by
Organisational identity the legal entity (EORI, or EUID where no EORI exists) iSHARE-anchored issuance
Participant / membership a valid accession agreement and current status registry operator
Role Data Provider, Consumer, Service Provider, Operator, Observer registry operator
Representative a natural person's authority to act for the entity the entity, anchored upstream
Conformance ITB-S evidence for a tested exchange path ITB-S (iLabs)
Operational role (Aruba pattern) a staff or process role inside a participant the participant

Decided W3C VC with JSON-LD data models is the primary format, over OpenID4VC, using iSHARE credential schemas (schemas.ishare.eu) as the base.

Proposed Sector-driven attestations: energy-market role for PED grid interaction, public-authority status for the municipalities, and the emission-methodology attestation underpinning LogiNex's claims. ISO/IEC 17000-based conformity assessments are recognised where a participant already holds them — the scheme should accept an existing accredited attestation rather than re-testing what a competent body has certified.

Proposed Validity: credentials are short-lived and renewed rather than long-lived and revoked, because revocation propagation is the fragile path. Renewal on a fixed cycle plus revocation for cause.

Needs owner iSHARE: actual validity periods. None are set.

3. Credential Issuance & Verification#

Purpose: Determine who issues credentials, how trust anchors are structured, and how verification will operate.

  • Who acts as the Trust Anchor(s) for credential issuance?
  • Will credential issuance be centralised under DSGA or federated across multiple accredited providers?
  • How will the verification process be implemented (centralised compliance service vs. distributed verification)?
  • How are credential issuance, renewal, and revocation managed (trust anchors, revocation lists/registries)?
  • Will verification align with eIDAS/ETSI trust lists and support automated status/revocation checks?

LDT answer DRAFTED · owner: iSHARE + FHC Corp + iLabs · due 26 Sep 2026

Decided iSHARE Foundation is the trust anchor, with eIDAS trust lists alongside it. The Trusted List and certification of parties are performed exclusively by iSHARE Foundation under the Consortium Agreement, and nothing in this repository changes that.

Decided Issuance is anchored centrally and operated through the iSHARE credential-issuer components; revocation is through status lists plus Participant Registry state. Verification is distributed, not centralised: each verifier checks the presented credential and consults the registry and status list. There is no central compliance service that every transaction must pass through — the same reasoning that rules out a central policy engine in Access & usage policies.

Proposed Federation of issuance beyond iSHARE-anchored issuers is not adopted for the pilot. The one case that pushes against this is operational-role credentials, which a participant issues within its own organisation (the Aruba pattern) — those are issued by the participant under its own organisational credential, which is delegation rather than a second trust anchor.

Decided Verification aligns with eIDAS/ETSI trust lists and supports automated status and revocation checks — the registry is machine-readable precisely so that checking is automatic rather than procedural.

Needs owner FHC with Qwihi — the open 🧩: the Aruba issuance ceremony, verification points in the operational process, and revocation handling, written up as a pattern other sites can copy.

4. Standards & Interoperability#

Purpose: Adopt interoperable standards to ensure credentials are machine-readable and compatible across data spaces.

  • Which technical standards (W3C VC, DIDs, OIDC4VC, SHACL, ETSI Trusted Lists) will be adopted
  • Will JSON-LD be used for credential data models and metadata?
  • How will interoperability with other data spaces and trust frameworks be ensured?
  • Will machine-readable rulebooks be published for automated compliance checks?
  • Will PKI profiles and secure-channel requirements be defined for credential transport?

LDT answer DRAFTED · owner: iSHARE + FHC Corp + iLabs · due 26 Sep 2026

Decided Adopted: W3C Verifiable Credentials, DIDs where wallet flows require them, OpenID4VC for issuance and presentation, JSON-LD as the credential data model, SHACL for validation, ETSI/eIDAS trust lists, and iSHARE credential schemas as the base. PKI profiles and secure-channel requirements come from the iSHARE-recognised eIDAS profiles.

Proposed Interoperability with other data spaces and trust frameworks: by construction, since the LDT adopted the iSHARE Trust Framework rather than building its own — an iSHARE-compliant counterparty interoperates without arrangement. For a non-iSHARE framework (Gaia-X, IDSA, a sectoral scheme) interoperability requires a recognition arrangement, which is a governance decision for iSHARE Foundation and TIPS and not something this block can grant.

Proposed Machine-readable rulebooks for automated compliance checking: partially, and the honest statement matters. The scheme's enforceable parts are already machine-readable — ODRL policies, credential schemas, registry entries, SHACL shapes. The governance text is not, and publishing a machine-readable rulebook in the full sense is not a LDT deliverable. PD4 should claim the former and not the latter.

Decided The ITB-S identity test profile, which this block previously carried as an open request to iLabs, is set by PD4 §3. Exchanges tested: 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. Pass criteria: 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. Where the evidence goes: reports are stored per component in this governance repository, and the Scheme Owner — not the testing party — decides on listing. (Source: PD4 v1.0 §3 — text as in PD4 v0.96, 29 Oct 2026.)

5. Governance & Lifecycle Management#

Purpose: Set rules for managing credential changes, revocations, and disputes to maintain trustworthiness.

  • How will credential revocation, suspension, and reinstatement processes be triggered and managed?
  • How will changes in participant status (mergers, closures, ownership changes) be handled in credential records?
  • What is the escalation process for identity disputes or fraudulent credential usage?
  • Where and how will conformance evidence (certificates, manifests, audits) be published for discovery (e.g., in catalogs/registries)?

LDT answer DRAFTED · owner: iSHARE + FHC Corp + iLabs · due 26 Sep 2026

Decided Revocation, suspension and reinstatement run through the same two mechanisms as participation status: a registry status change and a status-list entry, both propagating automatically to policy enforcement. Suspension is reversible and fast; termination is final — the distinction drawn in Participation management section 4.1, and the credential layer is where it is actually implemented.

Triggers: expiry (automatic), participant request, non-compliance per the sanction ladder, failed or lapsed conformance, and compromise.

Proposed Participant status changes — mergers, closures, ownership changes — are not handled by editing a credential record. The credential attests a legal entity at a point in time; when the entity changes, the old credential is revoked and a new one issued against the new identity, with the registry retaining both and the audit trail showing the transition. Mutating a credential in place would destroy the evidence that a past transaction was validly authorised.

Proposed Identity disputes and fraudulent credential use: immediate suspension by the WP4 lead (acting without convening anyone, because the harm is ongoing), investigation using the audit trail, decision at TIPS, escalation per the Consortium Agreement ladder.

Decided Conformance evidence is published to the Participant Registry and surfaces in the Marketplace of the EU LDT Toolbox, where it gates certified badges.

Needs owner iSHARE legal: confirm unilateral suspension authority — assumed throughout this scheme and agreed nowhere.