[API Proposal] Network‑Authenticated Assembly

[abd-abhisek]

Description
NAA is a lightweight API that verifies whether a defined group of devices is physically together within a specific zone and recent time window. It accepts flexible device clusters—such as phones, terminals, ID tags, or IoT trackers—and provides a simple verdict like co_present, partial, or not_co_present. Each result can include a privacy‑preserving attestation so workflows can act on trusted presence without revealing exact locations. NAA operates at large scale, allowing thousands of clusters to be checked continuously or on demand. Developers define the zone, time tolerance, and minimum required devices for each cluster. The API fits cleanly into security‑sensitive physical processes in banking, education, logistics, transportation, and controlled‑access environments. NAA brings real‑world trust automation into any workflow that depends on people, devices, or assets being together in the right place.

Use cases
Before delivering a critical treatment, NAA checks that the nurse’s device, patient’s bedside tag, and authorized medication cart are all co‑present in the same room. On co_present, the system green‑lights medication administration, ensuring safe and verified bedside care without extra steps.

Use cases
During loading, the RFID gateway detects all tagged goods in the bay and reports them to NAA. NAA verifies that the gateway, the vehicle’s IoT device, the dock beacon, and the driver’s phone are co‑present in the loading zone. On co_present, the system confirms the full load assembly and marks the shipment ready for dispatch

@bishnu-infy @hemantagogoi-infy @vijaymurthyn

Related to

Supporting material

[albertoramosmonagas]

Hi @abd-abhisek,

Thanks for submitting the API proposal. First, I would like to ask you for some clarifications on the proposal:

• Scope and possible overlap: the API verifies presence in an area and in a recent time window—it overlaps heavily with Device Location Verification, and the claim of continuous checks smacks of subscriptions, which already exists as a pattern in the Geofencing Subscriptions API. This API seems more like an enhancement of the Device Location subproject.
• Is the operator able to verify the device clusters you mention? I am concerned about interoperability.

I believe the rest of the points can be clarified once the PR is uploaded, but this API has been added to the agenda for the next backlog session (February 26, 2026 API Backlog Minutes).