Repository navigation
Review Request for new API: See if it is a New Use case vs new API within DV group #394
Description
Hello Team,
we proposed a new API (NAA) , PR goes below. You may refer to the attached deck 0.2 in the PR/ here attached
Network‑Authenticated Assembly_v0.2.pptx
We were advised in last backlog WG call that we should review with you, whether " if we’re proposing a new API inside the current group or a new use case" Could you please advise accordingly? We can join the next/your suggested WG call and clarify questions. Together we can review the next course of action and take it back to Backlog WG
Activity
[-]Review Request for new API to validate[/-][+]Review Request for new API: See if it is a New Use case vs new API within DV group[/+]jlurien commentedon Apr 30, 2026
Hi @abd-abhisek,
While the concept of verifying that devices are 'together' is a unique use case, the current requirement for the caller to provide a specific Area (specific lat/long) makes this feel like a batch version of the existing Location Verification API. If the 'zone' were instead treated as a proximity threshold (e.g., 'are these N devices within X meters of each other, regardless of coordinates'), it would be a completely new abstraction. As currently defined, how does this provide more value than a client-side aggregation of Location Verification calls, other than atomicity?.
Another thought is that the existing location-verification API already faces significant implementation challenges regarding accuracy, often requiring PARTIAL results or matchRate to handle precision margins. By moving to a group API, we elevate this complexity to the N-th power. If each of the N devices carries its own margin of error, guaranteeing a reliable 'atomic' group verdict becomes exponentially more difficult for the operator to standardize and for the developer to trust.
abd-abhisek commentedon May 2, 2026
Hi @jlurien , thank you for the thoughtful and detailed feedback — these are exactly the right questions to stress-test the proposal.
On the "batch Location Verification" concern: you're right that the per-device check shares DNA with Location Verification. The key difference is that NAA evaluates all devices against a shared moment and produces a single group verdict — calling Location Verification N times gives N independent answers from N different instants, with no atomicity and no unified proof. That temporal consistency is the core value.
On what NAA adds beyond LV: Location Verification answers "is this one device in this zone?" NAA answers "are enough of these devices here, right now, together?" — with a k-of-n threshold, a bounded evaluation window, and a single signed token as proof, without exposing individual locations. Those three things aren't possible by aggregating LV calls client-side.
On the accuracy and complexity concern — this is a fair and genuinely useful observation, and we don't want to dismiss it. The per-device margin-of-error challenge is real. Our position is that the operator resolves complexity server-side, so the developer receives one clean verdict. The partial result and the k-of-n threshold are designed precisely to avoid binary perfection — the caller declares their own tolerance (e.g., "3-of-4 is good enough"). A client aggregating N LV calls faces the same per-device accuracy issue, plus race conditions and no unified token — NAA moves that complexity to where it can be handled more reliably.
On the proximity-threshold idea — that's brilliant direction and we'd welcome exploring it in WG as a future mode. For v0.x, the Area-based approach keeps us aligned with existing CAMARA patterns and makes the first implementation tractable. Then we propose we further enhance it with this excellent idea. Please share your thoughts. @albertoramosmonagas @bishnu-infy @gmuratk
albertoramosmonagas commentedon May 4, 2026
Thanks @abd-abhisek — this is a much clearer positioning. I think the key distinction is now well framed: NAA v0.x is not claiming a new underlying location capability, but a server-side group verification abstraction on top of existing location capabilities: bounded evaluation window, k-of-n group verdict, and a single signed proof.
That said, since v0.x remains Area-based and the caller still provides a standard Area object, I think @jlurien’s point remains important for the governance decision: this may still fit naturally as an evolution within DeviceLocation rather than as a separate API family. The proximity-threshold mode (“are these devices within X meters of each other regardless of coordinates?”) would indeed look like a stronger new abstraction, but that seems future-scope rather than v0.x.
For the next step, I suggest we ask the @camaraproject/device-location_codeowners & @camaraproject/device-location_maintainers to provide guidance on the onboarding path:
bigludo7 commentedon May 18, 2026
Hello
Ffor my view the rational for this API is fair. I remind a couple of real-life UC from previous discussions with devs:
For these UCs, the app did not care where the people are but just want to be sure that they are "close".
I fully understand @jlurien point about complexity and this is the challenge for this new request but as UC are fair....
As such, @albertoramosmonagas, my preference is to have a new API within the DeviceLocation Subproject
Why?
albertoramosmonagas commentedon May 18, 2026
Thanks @bigludo7, this is very helpful guidance. I think this gives a clear potential onboarding direction: if the proposal progresses, it should likely be handled as a new API within the DeviceLocation subproject, rather than as a separate API family. That would keep consistency with existing location APIs and allow the DeviceLocation WG to manage the accuracy/privacy/consent implications. Next, the plan is to review this proposal and send it to TSC if there are no objections.
jlurien commentedon May 18, 2026
@bigludo7 We can discuss further on this in the next meeting. We already had some discussion during the last one
The use cases you list are in line with my comment above "If the 'zone' were instead treated as a proximity threshold (e.g., 'are these N devices within X meters of each other, regardless of coordinates'), it would be a completely new abstraction."
but we have first to clarify the proposal regarding the requirement to add an area as input, which is what would make the new API as batch version of location-verification
ShyamGeek-77 commentedon Jun 1, 2026
Aligned with @abd-abhisek @jlurien @bigludo7 and @albertoramosmonagas on the proximity threshold approach, while this is s great idea, could we explore this in the next round, one other reason is, we may have to have some hardware enhancement to be able to realise that functionality, while the current approach is more generic and could be implemented without any added complexity. We shall continue enhancing this as we go along as an enhancement.
albertoramosmonagas commentedon Jun 1, 2026
Thanks @bigludo7, @jlurien and @ShyamGeek-77 for the discussion and the useful feedback.
From the API Backlog perspective, the main point to clarify is the appropriate onboarding path. Based on the discussion so far, the current direction seems to be:
Could the DeviceLocation maintainers/codeowners please confirm whether this reflects the group’s recommendation? If the DeviceLocation group agrees with this direction, my understanding is that no additional API onboarding process, tracker, or TSC review would be required, since the work would continue within the existing DeviceLocation repository and governance. In that case, the next steps would be for the DeviceLocation group to decide how they would like to progress the proposal and any related work items.
If this is okay, we can close the issue in the backlog, and the work will remain with the team and be handled by @abd-abhisek
jlurien commentedon Jun 1, 2026
@ShyamGeek-77, @abd-abhisek please consider joining our bi-weekly meetings, next one tomorrow June, 2nd at 7:00 UCT for better a interaction with the group
Meetings are held virtually
Schedule: bi-weekly (odd weeks), Tuesday, 7:00 AM UTC (9:00 CEST)
Meeting link: Registration / Join
abd-abhisek commentedon Jun 2, 2026
Hello @jlurien sorry, today it may not be possible for I and Shyam[pre-scheduled appointments]. But we plan to join next one. If there are offline points, kindly feel free to shoot @ShyamGeek-77 @bishnu-infy
jlurien commentedon Jun 29, 2026
@albertoramosmonagas We have decided to let promoters of this potential new API to continue the work in a separate sandbox repo, within the umbrella of Device Location WG.
albertoramosmonagas commentedon Jun 29, 2026
Thanks @jlurien, I'm going to gather all the information to send to the TSC the 16th of July. As far as I'm concerned, we can close this issue.