API-proposal-Network‑Authenticated-Assembly

[abd-abhisek]

#300

What type of PR is this?

Add one of the following kinds:

• enhancement/feature
• documentation

What this PR does / why we need it:

This PR introduces a new API proposal https://github.com/camaraproject/APIBacklog/issues/300

Which issue(s) this PR fixes:

https://github.com/camaraproject/APIBacklog/issues/300

Fixes #

Special notes for reviewers:

This PR provides the initial proposal for discussion in the API Backlog Working Group.
Feedback from the community is welcome regarding scope, alignment with existing CAMARA APIs, and potential collaboration

Changelog input

 release-note

Additional documentation

This section can be blank.

docs

[albertoramosmonagas]

Can you add this diagram to the actual PR?

[abd-abhisek]

I don’t know why can’t I upload any diagram/ document today. May be a security update from my organization. I have the deck ready for tomorrow discussion, unfortunately figuring out how do I upload /push and generate PR.

-- Regards Abhisek From: Alberto Ramos Monagas ***@***.***> Sent: Wednesday, March 11, 2026 4:55 PM To: camaraproject/APIBacklog ***@***.***> Cc: Abhisek Das ***@***.***>; Author ***@***.***> Subject: Re: [camaraproject/APIBacklog] API-proposal-Network‑Authenticated-Assembly (PR #305) [**EXTERNAL EMAIL**] Please verify sender address and exercise caution before clicking on any link. @albertoramosmonagas commented on this pull request.

________________________________ In documentation/API proposals/API-proposal-Network‑Authenticated-Assembly.md<#305 (comment)>:

+

+### Technical viability +Identify the underlying network/cloud capabilities which are needed for the support of this API or API family, relating these capabilities to standards maturity. +- Relies on **operator network-level device location capabilities** (e.g., 3GPP NEF/SCEF location services, Rel-15+). +- k-of-n threshold evaluation and group verdict aggregation are performed server-side by the NAA Group Evaluator component. +- Subscription/event model aligns with existing CAMARA CloudEvent patterns (same lifecycle as Geofencing Subscriptions). +- Attestation token provides a tamper-evident, privacy-preserving proof of co-presence for downstream workflow consumption. +- **Scope clarification:** cluster members are restricted to operator-addressable (SIM/eSIM/line-based) devices to ensure interoperability; non-SIM beacons/tags are out of scope. + +### Commercial viability +- No proprietary components required beyond standard network APIs already consumed by CAMARA Device Location +- Open-source reference: CAMARA DeviceLocation API implementation available in the CAMARA GitHub organization + +### YAML code available? +NO +Sequence diagram is available in deck Can you add this diagram to the actual PR? — Reply to this email directly, view it on GitHub<#305 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BBVOLGDTXIRTICXEM5YCTML4QFEIVAVCNFSM6AAAAACWOE35ZCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTSMRYHEYDENJWGA>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[albertoramosmonagas]

Hi @abd-abhisek, thanks for the PR. When you have the diagram and the PowerPoint presentation, can you attach them to this PR? Here are some points we can discuss in the backlog session:

1. Overlap: batch + k-of-n is not a new capability
   The underlying signal is still “presence in an area within a recent time window”. The proposed delta is mainly batching plus server-side aggregation into a group verdict. Please justify why this must be a new API family instead of a DeviceLocation scope enhancement (group co-presence) reusing existing area/time/error semantics.

2. Weak differentiation vs Location Verification
   “Location Verification requires exact lat/long” is not a strong differentiator: both approaches rely on a zone definition and return a verification outcome. Please restate the differentiation in normative terms: what cannot be achieved by Location Verification per device plus client-side aggregation, and why this must be standardized server-side for interoperability.

3. Consent/privacy is underspecified (multi-device inference)
   Group co-presence enables relationship inference (“who was with whom, where, when”). Please specify the authorization/consent model: enterprise-controlled fleet only (single tenant) vs multi-user clusters (user consent / 3-legged), and the data-minimization safeguards.

4. Subscriptions claim is too vague
   If “continuous checks” remain in scope, “aligns with CloudEvents” is not enough. Please specify the subscription resource model (endpoints, event types/payload, callback behavior, expiry/cancellation, quotas and lifecycle states).

[abd-abhisek]

Hi @abd-abhisek, thanks for the PR. When you have the diagram and the PowerPoint presentation, can you attach them to this PR? Here are some points we can discuss in the backlog session:

1. Overlap: batch + k-of-n is not a new capability
   The underlying signal is still “presence in an area within a recent time window”. The proposed delta is mainly batching plus server-side aggregation into a group verdict. Please justify why this must be a new API family instead of a DeviceLocation scope enhancement (group co-presence) reusing existing area/time/error semantics.
2. Weak differentiation vs Location Verification
   “Location Verification requires exact lat/long” is not a strong differentiator: both approaches rely on a zone definition and return a verification outcome. Please restate the differentiation in normative terms: what cannot be achieved by Location Verification per device plus client-side aggregation, and why this must be standardized server-side for interoperability.
3. Consent/privacy is underspecified (multi-device inference)
   Group co-presence enables relationship inference (“who was with whom, where, when”). Please specify the authorization/consent model: enterprise-controlled fleet only (single tenant) vs multi-user clusters (user consent / 3-legged), and the data-minimization safeguards.
4. Subscriptions claim is too vague
   If “continuous checks” remain in scope, “aligns with CloudEvents” is not enough. Please specify the subscription resource model (endpoints, event types/payload, callback behavior, expiry/cancellation, quotas and lifecycle states).

My challenge is I am unable to attach Deck, due to change in security policy possibly at my end. I really appreciate your review comments.
Let me try out add slides for each of the questions. I believe we have taken these into account, however keen to understand your and community perspective and refine as needed.
Thanks again