[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 Case 1: Secure Cash-in-Transit Handover
During armored vehicle loading at a bank branch, NAA verifies that:

The driver's mobile phone
The security guard's mobile phone
The branch manager's mobile phone
The vehicle's cellular IoT tracker
are all co-present in the loading zone. On co_present, the system authorizes the cash transfer and logs the verified handover

Use Case 2: Field Service Authorization
Before a technician performs maintenance on critical infrastructure, NAA checks that:

The technician's work phone
The supervisor's mobile phone
The equipment's cellular monitoring device
are co-located at the site. On co_present, the system unlocks digital work permits and starts time tracking

@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).

[abd-abhisek]

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).
Hello @albertoramosmonagas

Thanks for your review comments. Most of my colleagues and I are travelling to attend LFN Summit India on 26th, hence may not be able to join this backlog call. But, will surely join next call and discuss. In the meantime, please see the response below-
For Point 1:
Device Location Verification: Single device, requires exact latitude/longitude input
Geofencing: Subscription-based, individual device monitoring
NAA (redefined): Batch co-presence check, returns relational verdict about device groups, not individual locations

For Point 2:
We went more specific for a use case we are trying to implement. Use cases updated with broader, generic considerations
@bishnu-infy @hemantagogoi-infy @vijaymurthyn

[albertoramosmonagas]

Hi @abd-abhisek,

Thanks for your reply, but it doesn’t remove the core concern: the capability is still “presence in an area within a recent time window”, which overlaps strongly with Device Location Verification. The “NAA redefined” delta seems mainly batching + server-side aggregation (k-of-n) into a group verdict, which fits better as an enhancement inside the DeviceLocation subproject rather than a new API family. I need some clarifications:

1. Device eligibility: are cluster members restricted to operator-addressable (SIM/eSIM/line-based) devices? The proposal still mentions tags/beacons/gateways/carts — that breaks interoperability.
2. “Continuous checks” claim: if “continuous at scale” remains in scope, we need a subscription/lifecycle model aligned with existing CAMARA patterns (e.g., Geofencing Subscriptions).

[gmuratk]

@abd-abhisek @albertoramosmonagas
I didn't make the connection at first, but "group management' as service management API was suggested in camaraproject/Commonalities#568. If there is agreement having group management will allow for keeping the existing atomic APIs (e.g. geofencing, verify device location) to be leveraged for groups of devices and meet the goals of NAA (this proposal), then it will be good to bring it as another example case in support of the Group Management API.

[albertoramosmonagas]

Hi @gmuratk, thanks for the pointer. I agree a cross-cutting Group Management API could help standardize how consumers define and reuse device collections across CAMARA APIs, and NAA is a good concrete example to motivate that work. That said, Group Management alone would mainly address “how to reference/manage the group membership”. NAA is still proposing verification semantics on top (k-of-n co-presence verdict, bounded evaluation window, and optionally an attestation token). So I’d suggest we treat Group Management as a complementary/optional enabler (e.g., allowing a groupId input in future), but avoid making NAA dependent on it for v0.x.

If the WG agrees, we can also reference NAA as an example use case in the Group Management discussion, while continuing to evaluate whether the verification semantics belong as a new family or as an enhancement within DeviceLocation.