Aruba Airport — operational decarbonisation#

Profile owner: FHC Corp (with Qwihi) · LDT-UC-03 · Status: 🟠 skeleton pre-filled

1–2 · Identity, problem & context#

Aruba Airport's operational twin optimises passenger flows and resource use to cut emissions in a commercial setting — demonstrating that the same trust framework serves public city twins and commercial operational twins alike. Jurisdiction note: Aruba is outside the EU — this profile is the scheme's test case for non-EU participation.

3 · Objectives & KPIs#

Decided Metrics: operational efficiency measures; estimated € and CO₂ savings from interventions.

Needs owner — FHC Corp.** Baseline, target and measurement window per metric. Two things specific to a commercial site: say which figures are commercially confidential and therefore restricted-tier, and which derived indicators may go cross-site — this profile already commits to derived KPIs crossing while operational data does not, and the scheme needs to know which is which before the licence tiers can be written.

4 · Stakeholders#

Airport operator, FHC/Qwihi (twin and wallet services), staff (credential holders), LogiNex (emission analytics).

Aruba Airport's own status matters for this profile and is settled: the signed application lists Aruba Airport as a Government / Public Authority stakeholder engaged through a Letter of Support, as an unfunded contributor, which "will provide noise pollution, low carbon operations and mobility use cases to pilot from their LDT". That is the same position as Hamburg Port Authority — a supporting stakeholder, not a partner — so per-site commitments need that party's own confirmation, and FHC coordinates rather than speaks for it. (Source: EUTwinLink LDT4SSC WS1 Application Form §1.3, Annex 4 to the Pilot Grant Agreement.)

Needs owner — FHC Corp.** Confirm whether airlines and ground handlers participate. This is not a list-completion detail: if they do, they are third-country commercial participants holding credentials issued under this scheme, which multiplies the non-EU transfer question across several organisations instead of one. If they do not, state that their data reaches the twin through the airport operator, under what terms.

5 · Data needs & sources#

Passenger-flow sensors (privacy: aggregate only), operational systems (gates, energy), flight schedules.

The signed application names the dynamic sources: ADS-B flight tracks and Airport Operational System milestones, IoT sensors for ground equipment and energy use, LCMM mobility data for landside traffic, and CO₂ and noise models (ECAC Doc 29), with the twin aligned to ACA Level 4 reporting and ISO 23795-1. (Source: EUTwinLink LDT4SSC WS1 Application Form §1.7, Annex 4 to the Pilot Grant Agreement.)

Needs owner — FHC Corp.** Source inventory: format, frequency, quality, and personal-data status per source.

The point needing an explicit answer rather than an assumption: at what point passenger-flow data is aggregated. "Aggregate only" is stated as a property of what is shared; the scheme needs to know whether aggregation happens at the sensor, in the twin, or at the point of exchange. If raw flow data exists anywhere in the chain, the privacy position rests on a policy rather than on the architecture, and that changes what the scheme must enforce.

Non-EU transfer clauses in the data-sharing terms (applicable law, transfer mechanism) — input to Regulatory compliance.
Commercial confidentiality tiers: operational data restricted to named participants; only derived KPIs go cross-site.
Wallet/VC-based credentials for operational roles — the LDT's pioneer implementation (see Identity & attestation).

7 · Architecture (building blocks used)#

Operational twin ↔ EDC + iSHARE extension; OpenID4VC wallet flows for staff/process credentials; ITB-S-validated exchange paths.

8 · Timeline & maturity#

Decided Maturity: the operational twin exists; wallet flows are to be piloted per the WP4 and WP2 plans, gated by the WP4 T4.1 baseline.

Needs owner — FHC Corp, with iLabs.** Milestones with dates: wallet and VC issuance ceremony defined, first operational-role credential issued, ITB-S identity-module validation passed, first cross-site derived indicator exchanged. The dependency to state alongside: this profile is the scheme's pioneer implementation of wallet-based credentials, so its milestones gate the worked example that Identity & attestation owes every other site.

9–12 · Value, risks, EU alignment, materials#

Decided Value: a commercial replication case, and proof that the scheme travels beyond the EU — which is a claim about the governance framework rather than about the airport.

Proposed Risks and mitigations:

Risk	Mitigation
Transfer-law complexity (EU ↔ Aruba)	transfer mechanism and applicable-law clauses as an annex module; the mechanism is now named — see below
Commercial sensitivity	restricted tier for operational data; only derived KPIs cross sites; confidentiality in the accession annex
eIDAS does not reach Aruba	iSHARE-anchored credentials accepted in place of eIDAS — see Identity & attestation section 1. This is the scheme's deliberate answer, not a workaround
Wallet flows unproven, and other sites depend on them	ITB-S identity-module validation before production; the WP4 T4.1 baseline gates it

Decided EU alignment: Green Deal aviation goals; GDPR-equivalence considerations.

Decided The transfer mechanism is named in PD4 §5, which this profile previously left open. Aruba is not on the European Commission's list of adequacy decisions, so any transfer of personal data from the EU/EEA is assessed against GDPR Chapter V before it is enabled. The approach is to share approved operational outputs and anonymised summaries wherever possible and keep identifiable source records under the source operator's control; pseudonymised data remain personal data. Where Chapter V safeguards are needed, the stated basis is the Commission's Standard Contractual Clauses with a transfer assessment, agreed before the flow is activated. The parties record purpose, legal basis, controller and processor roles, recipients, hosting and remote-access locations, retention and onward transfers. FHC coordinates the local information and Qwihi the technical details; the responsible controllers approve the arrangements. PD4 is explicit that these steps are not yet completed and do not represent an existing legal sign-off — executing them is PD4 Table 3, "National legal sign-offs (ES, NL); Aruba transfer arrangements", owner FHC with the controllers, target M12. (Source: PD4 v1.0 §5 and Table 3 — text as in PD4 v0.96, 29 Oct 2026.)