PD4 v1.0 ↔ repository#
PD4 v1.0 is the TIPS-approved snapshot of this repository at tag
v1.0-PD4. Changes after M6 follow the change procedure in PD4 section 2 rather than re-opening the deliverable. The tag is created by the Scheme Owner after this page is merged and TIPS approval is recorded.The tag is a fixed point in a repository that carries on past it. It is what PD4 cites and what reviewers can rely on; it is not the end of the work. Fifteen actions in PD4 Table 3 are still open, with owners and target months, and 113 guiding questions are still assigned to partners. A reader who wants the agreed position reads the tag; a partner who wants to move it forward opens a merge request against
main.
PD4 is the EUTwinLink PD4 Governance Scheme (Pilot Deliverable 4, due 30 October 2026, M6). This page maps each PD4 section to the repository pages that carry the same content, and lists the remaining actions from PD4 Table 3. Text in the repository that is quoted from PD4 carries a line Source: PD4 v1.0 §x, with the drafting version it was taken from. Most pages were aligned against v0.95_merged (28 October 2026); Table 3, the §4 Table 2 rows, the observability retention rule and the trust-anchor statements were re-checked against v0.96 (29 October 2026, the version circulated for ERTICO review). Where a page still cites v0.95_merged, nothing in v0.96 changed that passage.
Section mapping#
| PD4 section | What it fixes | Repository pages |
|---|---|---|
| Document information · §1 Introduction | PD4 is the TIPS-approved snapshot of this repository at M6; later changes follow the change procedure | Home · Scheme overview · this page |
| §2 Overview — main actors, Table 1 (component operators), Figure 1 | Scheme Owner, TIPS, one accountable operator per component; listing decided by the Scheme Owner, testing by iLabs | Organisational form & governance authority · Governance design layers · Intermediaries & operators · Building-block register |
| §2 Decision-making and coordination | OPEN → DRAFTED → REVIEWED → APPROVED, TIPS as final gate | Building-block register · How to contribute |
| §2 ERTICO — Hamburg traffic-management use case (Figures 2–4) | Decision support for Hamburg Port Authority traffic management; traffic flow and emission layers; embedding in the iSHARE framework | Hamburg Port — logistics twin (not yet reflected; question to the profile owner) |
| §3 Operating conditions — Satellite, ITB-S, trust gateway, issuers, sites | Satellite admits by EORI, or EUID where no EORI exists; iSHARE Participant Registry as only trust anchor; ITB-S suites; issuance infrastructure as processor; observability; test environment; maintenance | Intermediaries & operators · Data exchange · Provenance, traceability & observability · Identity & attestation management |
| §3 Public-private partnership per site | Local partners keep the operational LDT prototype under a PPP agreement | Cartagena · Almelo/Aadorp · Aruba Airport · Hamburg Port (not yet reflected; question to the profile owners) |
| §4 Data governance and sharing — access, Commons controls, Table 2 | Data access, not hand-over; ODRL policies under DataRights; data sharing model per dataset | Data space offerings · Access & usage policies enforcement · Data models · use-case profiles |
| §4 Marketplace catalogue | TM Forum catalogue; DCAT-AP 3.0 and OGC API – Records, read-only | Publication & discovery · Data, services & offerings descriptions |
| §4 Multiple credential issuers, multiple wallets, verification process | Accredited-issuer register with five rules; HAIP wallet profile on the ITB-S; tested-wallet list; status-refresh rule | Identity & attestation management |
| §4 ISO 23795 floating-car data (Figures 5–6) | ISO 23795-1 based architecture and dashboard | Data models · Hamburg Port · Aruba Airport (not yet reflected; question to the owners) |
| §5 Legal and contractual framework | Legal layers; RFC066 licence headers; Marketplace Terms of Use; app-store terms of use; regulatory perimeter; Aruba and GDPR Chapter V | Contractual framework · Regulatory compliance · Aruba Airport · Legal notices |
| §6 Sustainability and continuity | Governance, operational and financial continuity; Marketplace hosted by Nunsys for the project duration, with transfer proposed at project end; iLabs interoperability-layer revenue model; Aruba continuation | Business model · Intermediaries & operators · Aruba Airport |
| §7 Replication and scalability | Public template; replication kit; same admission procedure for every participant | Scheme overview · Use case development · Data, services & offerings descriptions |
| §8 Conclusions and next steps — Table 3 | Remaining actions with owner and target | the table below · Building-block register · Open questions for partners |
Remaining actions (PD4 Table 3)#
| Action | Owner | Target |
|---|---|---|
| Wire the Satellite’s Participant Credential check into the credential issuers and the trust seam of the Marketplace of the EU LDT Toolbox (self-asserted → scheme-verified legal-entity trust) | iSHARE, iLabs, Nunsys, issuers | M9 |
| First ITB-S conformance runs for issuers, wallets and verifiers; publish the tested-wallet list | iLabs; Scheme Owner decides listing | M9 |
| Decide the party identifier (iSHARE DID as key, EUID/EORI associated), including Marketplace registration | TIPS | M8 |
| National legal sign-offs (ES, NL); Aruba transfer arrangements | Cartagena; Almelo; FHC with controllers | M12 |
| Regulatory perimeter check of the CO₂ credential (PD4 section 5) | LogiNex with iSHARE legal | M9 |
| Production Marketplace Terms of Use aligned with iSHARE accession | Nunsys | M9 |
| Agree Marketplace transfer at project end with the Contracting Authority and CitiVERSE EDIC | Nunsys, ERTICO | M15 |
| German data-protection input for Hamburg trip and floating-car data | ERTICO with Hamburg Port Authority 1 | M9 |
| Map Marketplace compliance levels to the PD4 evidence classes (self-declared / third-party verified, with ITB conformance reports as evidence) | Nunsys, iLabs | M9 |
| Test wallet-based login (OpenID4VP with an organisation or member credential) alongside the federated identity providers of the Marketplace | iLabs, Nunsys | M8 |
| Federation restriction presets for the pilot to include Aruba (OCT), with the Chapter V safeguards of PD4 section 5 | Nunsys, FHC | M9 |
| Map identity and trust between DOME federation and the iSHARE trust anchor | Nunsys, iSHARE | M9 |
| Confirm the Ayra work-order scope; Hamburg profile owner | iLabs; consortium | M7 |
| All building blocks to APPROVED via TIPS; DataRights processes (onboarding, change, dispute) into the run phase (T4.3, T4.4) | WP4; all partners | M12 |
| Record exploitation arrangements per component within the background-IP boundary | All operators | M18 |
Source: PD4 v1.0 §8, Table 3 — text as in PD4 v0.96 (29 Oct 2026), all fifteen actions. The targets are proposed by iLabs from the pilot work plan (M1 = 14 May 2026) and are still to be confirmed by TIPS. The Marketplace-transfer action was added on 28 Oct 2026 following Nunsys, e-mail of 26 Oct 2026. Five actions were added in v0.96: the German data-protection input follows from the location-data safeguards in PD4 §4, and the four Marketplace actions from the Nunsys Marketplace demo at the LDT4SSC WP6 Task 1 technical meeting of 28 Oct 2026.
-
Flagged for the Scheme Owner rather than resolved here. PD4 §2 states that Hamburg Port Authority "is not a funded partner, and this deliverable records no obligations for it beyond its letter of support", while this action in PD4 Table 3 assigns it a joint action with a target month. One of the two has to give before the snapshot is tagged: either the action names ERTICO alone, or §2 is qualified. The same section proposes ERTICO as the accountable operator of the Hamburg use case (Table 1, marked "proposed"), which the Hamburg Port profile does not yet carry — it still records the profile owner as to be confirmed. ↩