Proposal: CAMARA Location APIs Functional Differences Whitepaper

[albertoramosmonagas]

Summary

Following the discussion in TSC, the understanding is that each Sub Project can decide whether and when to pick up possible whitepaper-related topics, with the current priority remaining Sync26.

Based on that, I' opening this issue to check whether the Device Location Sub Project sees value in a future API-consumer-facing whitepaper explaining the functional differences between the main Device Location APIs:

• Location Retrieval
• Location Verification
• Geofencing Subscriptions

The goal would be to help API consumers understand when to use each API and how they differ functionally. You can see an example here from CAMARA last whitepaper.

Request

This issue is only intended to confirm whether the topic and scope make sense from the Device Location repository perspective. No immediate drafting, review, API change, semantic change, or Sync26-related action is expected from maintainers. If the group sees value in the topic, it can be picked up after the current release priorities, at the pace decided by the Sub Project.

Questions

1. Does the group see value in this topic from an API-consumer perspective?
2. Is the proposed scope correct?
3. Should any API be added or explicitly excluded?
4. Are there semantic differences, limitations, or edge cases that should be captured if this topic is eventually drafted?

CC: @camaraproject/marketing_codeowners, @camaraproject/marketing_maintainers, @camaraproject/device-location_codeowners, @camaraproject/device-location_maintainers

[bigludo7]

Hello Alberto,
The 3 APIs are easy to explain but having a WP or a FAQ will be always helpful.
I'm wondering if we shouldn't extend the white paper to location based API like Region Device Count and in a larger extend Population Density Data.

We have for a long time a discussion about the accuracy for the geofencing API - indeed depending on the operator rule the behavious can be different (reduce the chance the miss a device inside the zone but increase chance to false notif vs reduce false notif but increase chance to miss real "intrusion") - we haven't be able to find a common rule here. Ir should probably listed as limitation.

[albertoramosmonagas]

Hi @bigludo7,

• On Region Device Count and Population Density Data: these are already proposed as a separate whitepaper (P3 in Marketing#61), precisely because they operate on aggregated non-personal data and serve a different developer audience. Keeping them separate from the device-level location paper avoids mixing two very different consent models and use case narratives. So the plan already accounts for them, just in a dedicated document.
• On the Geofencing accuracy trade-off: you're identifying exactly the kind of known interoperability limitation this paper should document explicitly. Where operators may tune behaviour differently depending on whether they prioritise reducing missed detections or reducing false notifications. This is a real implementation variance that the spec does not currently normalise. We will include it as a documented limitation, with a clear explanation of what it means for application developers.

It would just be a matter of seeing if it makes sense to propose a similar activity in these groups.