PAL NFC Resolution and Validation Process

The validation component of the PAL chip resolution flow involves two main data components:

Data Components

1. PEA Entries: Represents the count of PEA entries in the array. Each entry corresponds to a project enrollment and includes all necessary data to validate the NFC chip's enrollment in the project, like the Project Merkle tree and certificates. Ideally, there should be one PEA entry per chip, but as gateways aren't fully trusted, all entries need validation.

2. Entries: This array holds all data blobs for processing. The length should match PEA Entries + 1, with the final entry being the Manufacturer Merkle tree data blob.

Validation Steps

1. Integrity Checks: First, confirm the entries array length matches expectations.

2. Cycle Through Entries: Process each entry in the array:

   • If a valid PEA Entry is found, extract the serviceId and use it to retrieve Service Records from the ServiceRegistry.

   • If no valid PEA Entry is found, check the Manufacturer Merkle tree entry. If valid, it returns the bootloader app address.

3. Reversion on Invalid Data: If no valid PEA or Manufacturer entries are found, the process reverts, and the chip remains unresolved.

Validation Step	Description
Integrity Checks	Confirm the entries array length matches expectations.
Cycle Through Entries	Process each entry in the array.
If a valid PEA Entry is found	Extract the serviceId and use it to retrieve Service Records from the ServiceRegistry.
If no valid PEA Entry is found	Check the Manufacturer Merkle tree entry. If valid, it returns the bootloader app address.
Reversion on Invalid Data	If no valid PEA or Manufacturer entries are found, the process reverts, and the chip remains unresolved.