Optional Extension: Secure Entity Alignment for Vertical FL

The main path in this guide assumes horizontal FL, where participants have similar feature spaces but different records. Some use cases require vertical FL, where participants hold different features about overlapping entities. In those cases, the parties must first determine which records overlap without revealing their entire datasets to one another.

Figure 6. Example secure entity alignment flow for VFL. Parties align entities through PSI and train only over the aligned set.

8.1 When this applies

Question	Guidance
When is entity alignment needed?	When participants need to train on overlapping entities but hold different feature sets.
What identifiers may be used?	Use the minimum necessary identifiers and apply identifier hygiene before matching. Avoid casual use of direct identifiers where safer alternatives exist.
Should this be in the main tutorial?	Only if the repository has a working and tested PSI module. Otherwise, present it as an advanced extension.

8.2 Identifier hygiene

• Use only identifiers approved for the matching purpose.

• Normalise identifiers consistently before matching, for example trimming, casing, format checks, or salt handling where applicable.

• Avoid retaining raw identifiers in logs or exported artefacts.

• Record the approved purpose, participants, matching date, and match-count outputs.

8.3 PSI approach and execution

Private Set Intersection (PSI) is a common approach for privacy-preserving entity alignment. The exact protocol should be selected based on the repository implementation, participant capabilities, identifier sensitivity, and performance requirements.

Step	Operator action
Prepare identifiers	Confirm approval, normalise locally, and validate format.
Run PSI protocol	Execute the approved PSI runner, such as ECDH-PSI or KKRT where supported.
Review match counts	Check whether overlap is sufficient for the VFL task.
Approve aligned set	Record governance decision for using the aligned entity set.
Proceed to VFL training	Train only over approved aligned records and log the protocol output.

8.4 Audit and evidence

Evidence	Why it matters
Protocol and version	Supports reproducibility and security review.
Participants and purpose	Shows that alignment was performed only for an approved collaboration.
Identifier preparation method	Documents normalisation and hygiene steps.
Match counts and error conditions	Shows whether the aligned set is viable.
Approval decision	Shows whether aligned outputs may be used for training.

8.5 Failure modes

Failure mode	Response
Low overlap	Review whether the VFL use case remains viable or should be redesigned.
Unexpected high overlap	Check identifier preparation and whether matching inputs were correct.
Protocol failure	Inspect local logs, participant configuration, and version compatibility.
Identifier-quality issue	Fix local identifier preparation before re-running alignment.
Governance objection	Do not proceed until the participant agreement and approval basis are resolved.

Note

For deployments that also need to protect inference queries (not only training data), see Appendix E on secure inference with FHE and Nitro Enclaves.