Anonymised Subscriber Identifier API Proposal

[eric-murray]

A proposal for an Anonymised Subscriber Identifier API has been uploaded here. Please add any comments you may have.

Unfortunately, I don't have permissions to add labels to this issue, so maybe somebody could do that for me.

[jordonezlucena]

@eric-murray: in the notes clause, you state that "the API will not work if the route between the network and the web service includes proxies, VPNs or other network elements that NAT the source IP address". However, this is not an uncommon scenario in commercial deployments, right?

[dawid86]

Hi! I recommend having a look at Mobile Connect specifications, which describes Pseudonymous Customer Reference (PCR) that identifies MNO subscribers.

https://mobileconnect.io/specifications/

[eric-murray]

Hi @dawid86

Mobile Connect and the PCR could be used for the type of use case being considered here, but there are important differences which would make this a better option for this specific scenario:

• The identifier that will be provided to the application server is truly anonymised. There is no possibility to use it as a key to determine the true identity of the client contacting the application server.
• The client identifiers used to generate the anonymised identifier are limited to public IP and port. The reasons for this are two fold:
  • These parameters are anyway sent to the application server in the IP protocol header, so no additional requirements at all are placed on the client implementation by this proposal
  • The application server can request the anonymised identifier from the communications service provider the moment the first SYN packet is received from the client
• Generation of the anonymised identifier can be very fast, in which case the application server can have the identifier before it needs to generate any response (HTML or otherwise) to the client request. So the initial response to the client can be customised based on knowledge of the anonymised identifier.

So whilst Mobile Connect could be used for this type of use case, the idea here is to create something more lightweight and much faster to support this specific scenario. User consent would be handled separately via terms of service with an opt-in / opt-out option. If a particular client has opted out, no identifier will be generated.

The drawback, as noted in the API proposal, is that if there is any sort of proxy or gateway between the CSP network and the application server that is SNATing, then the CSP will not be able to identify the client from the IP address / port. However, clients that route their traffic through such proxies or gateways generally don't want to be tracked anyway.

[jordonezlucena]

Hi, PR https://github.com/camaraproject/WorkingGroups/pull/78 has been merged together with the rest of API proposals. It will be sent out for SC approval by 13/10. If not approved, I will reopen this PR. If approved (the API proposal is allocated into a new or existing Sub-Project), you can create an issue within that Sub-Project and continue discussion there, if and when needed.