The acr URI for anonymous users

This document specifies the URI (Uniform Resource Identifier) scheme "acr". This URI scheme is intended as an extension to the "tel:" scheme but without disclosing the true identity of a reference or a user. The "acr" URI describes an anonymous reference, that can be mapped to a resource or a user. There are multiple situations where the true identity of a user or a resources can not be disclosed. The "acr" URI is a globally unique identifier ( "name" ) only; it does not describe the steps necessary to reach the user or the device. However it can contain a parameter indication what body or organisation that could resolve it. It is intended for privacy protection, where a user trusts a translating party, that can route or forward the request or message to the true user or resource.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and indicate the requirements levels for compliant implementations.

The URI is defined using AB-NF (Augmented Backus-Naur Form) as described in RFC 5234 and uses elements from the core definitions (appendix A of RFC 5234). The syntax definition follows RFC 3986, indicating the actual characters contained in the URI. If the reserved characters "+", ";", "=", and "?" are used as delimiters between components of the "tel" URI, they MUST NOT be percent encoded. These characters MUST be percent encoded if they appear in tel URI parameter values. Characters other than those in the "reserved" and "unsafe" sets (see RFC 3986 ) are equivalent to their "% HEX HEX" percent encoding. The "acr" URI has the following syntax:

acr-uri = "acr:" anonymous-customer-reference anonymous-customer-reference = 1*alphanum *par par = parameter / network-code / acr-type / domainname network-code = ";ncc=" 1*uric acr-type = ";type=" 1*( "DYNA" / "STAT" ) domainname = ";domain=" *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum parameter = ";" pname [ "=" pvalue ] pname = 1*( alphanum / "-" ) pvalue = 1*paramchar paramchar = param-unreserved / unreserved / pct-encoded unreserved = alphanum / mark mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" pct-encoded = "%" HEXDIG HEXDIG param-unreserved= "[" / "]" / "/" / ":" / "&" / "+" / "$" alphanum = ALPHA / DIGIT reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / "," uric = reserved / unreserved / pct-encoded DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" / "a" / "b" / "c" / "d" / "e" / "f" ALPHA = lowalpha / upalpha lowalpha = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" upalpha = "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" The "anonymous-subscriber-identifier" can be created from some suitable user or customer data such as, phone number, and validation date. In order to provide anonymisation, this data MUST not be included unchanged within the ACR. Rather it MUST be encrypted, hashed, represented by a look-up reference or otherwise obfuscated. The issuing provider is responsible for unreferencing the ACR to the user or resource. For example the SHA-256 algorithm can hash the sensitive data: SHA256("")= e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c a495991b 7852b855 In order to know who issued the "acr" identifier, the Network Code or domain name MUST be included, for cross-operator identification and to ensure it is known which entity can deference the ACR. In addition a network country identifier MUST be provided (either as part of the network code, or separately) to avoid confusion where networks operate in multiple countries. A URI for ACR documentation MAY be included; for example, to discover further meta-data, or to list the service endpoints which can consume the ACR. The "network code" (ncc) is for mobile networks a concatenation of "mobile country code" (MCC) and "mobile network code" (MNC) as defined in ITU-T RECOMMENDATION E.212 As an example of ncc for Vodafone in UK, consists of MCC=234 and MNC=15 would concatenate to ncc=23415 The acr-type indicates if the ACR is a static type or a temporary type.

acr:0123456890123456789 This URI points to a user. for network internal use only since the network code is not provided acr:0123456890123456789;ncc=123 This URI points to a user belonging to network 123 acr:0123456890123456789;ncc=23415;type=DYNA This temporal URI points to a user or group of users and can be resolved by the Vodafone mobile network in UK. acr:0123456890123456789;ncc=123 This URI points to a group of users belonging to network 123. Note that the fact that more than one user is represented is not intrinsic to the acr but only known to the issuing network. acr:0123456890123456789;domain=example.com This URI points to a user belonging in domain "example.com"

Existing privacy policies and legislation restrict the sharing of certain user identifiers, such as the MSISDN, since it may be used to breach a user's privacy (unauthorized location look-up, cold calling, SMS Spam etc.). An "acr" prevents such identifiers from being circulated.

Cookie support is inconsistent across mobile devices. An "acr" can help identify a returning mobile user to a Website, and hence facilitate the provisioning of a personalized service based on previous preferences and activity.

Mobile, broadband and other access networks do not typically share a user identifier. The "acr" is not bound to a particular access network and can hence be used to provision user identifiers between networks.

The "acr" can help the implementation of SIP privacy considerations, as detailed in RFC3323, ‘A Privacy Mechanism for the Session Initiation Protocol’. Specifically the "acr" can be used as the value for the ‘anonymous from’ header field [section 4.1], and is consistent with the recommendation to remove Subject, Call-info, Organization, User Agent, Reply-To, In-Reply-To in [section 5.3].

This document is built on top of RFC3966, written by Henning Schulzerinne The editors of this document wishes to thank the GSMA ACCESS project members for their comments and suggestions.

This document includes a request to IANA. The editors of this draft request the protocol scheme name "acr" to be reserved for this RFC.

Since the "acr" is used to protect the identity of a user or a device the forwarding party must not disclose information that would or can be used to reveal the identity of the user. However the network code or domain name will reveal some information of the the "acr" affiliation. The security considerations parallel those for the "tel" URI RFC3966. Web clients and similar tools MUST NOT use the "acr" URI to place telephone calls or send messages without the explicit consent of the user of that client. Placing calls or sending messages automatically without appropriate user confirmation may incur a number of risks, such as those described below: Calls or messages may incur costs. The URI may be used to place malicious or annoying calls. A call will take the user's phone line off-hook, thus preventing its use. A call may reveal the user's possibly unlisted phone number to the remote host in the caller identification data and may allow the attacker to correlate the user's phone number with other information, such as an e-mail or IP address. This is particularly important for "acr" URIs embedded in HTML links, as a malicious party may hide the true nature of the URI in the link text, as in

Find free information here Call RFC organization for help ]]> "acr" URIs may reveal private information, similar to including phone numbers as text. However, the presence of the "acr" schema identifier may make it easier for an adversary using a search engine to discover these numbers, and hence search engines should avoid indexing these identifiers.