From: http://www.ietf.org/id/draft-uri-acr-extension-00.txt Title: The acr URI for Anonymous Users Reference: IETF Network Working Group, Internet Draft 'draft-uri-acr-extension-00' Date: January 21, 2010 I-D Tracker: http://ietfreport.isoc.org/idref/draft-uri-acr-extension/ Tools: http://tools.ietf.org/html/draft-uri-acr-extension-00 (HTML) Announced: http://www.ietf.org/mail-archive/web/i-d-announce/current/msg29103.html ============================================================================== Network Working Group S. Jakobsson, Ed. Internet-Draft Telenor ASA GBD&R Intended status: Informational K. Smith, Ed. Expires: July 25, 2010 Vodafone-Group (R&D) January 21, 2010 The acr URI for anonymous users draft-uri-acr-extension-00 Abstract This document specifies the URI (Uniform Resource Identifier) scheme "acr". The "acr" URI describes an anonymous reference, that can be mapped to a resource or user. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 25, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Jakobsson & Smith Expires July 25, 2010 [Page 1] Internet-Draft Abbreviated Title January 2010 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. URI syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Privacy policies . . . . . . . . . . . . . . . . . . . . . 5 5.2. Cookie support . . . . . . . . . . . . . . . . . . . . . . 5 5.3. Sharing identity . . . . . . . . . . . . . . . . . . . . . 5 5.4. Relation to SIP . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Jakobsson & Smith Expires July 25, 2010 [Page 2] Internet-Draft Abbreviated Title January 2010 1. Introduction This document specifies the URI (Uniform Resource Identifier) scheme "acr". The "acr" URI describes an anonymous reference, that can be mapped to a resource or 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. 2. Terminology 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 [RFC2119] and indicate the requirements levels for compliant implementations. 3. URI syntax The URI is defined using AB-NF (Augmented Backus-Naur Form) as described in RFC 2234 [RFC2234] and uses elements from the core definitions (appendix A of RFC 2234). The syntax definition follows RFC 2396 [RFC2396], 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 2396 [RFC2396] ) are equivalent to their "% HEX HEX" percent encoding. The "acr" URI has the following syntax: Jakobsson & Smith Expires July 25, 2010 [Page 3] Internet-Draft Abbreviated Title January 2010 acr-uri = "acr:" anonymous-subscriber-identifier anonymous-subscriber-identifier = 1*alphanum *par par = parameter / network-code / domainname network-code = ";ncc=" 1*uric 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" Figure 1 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 lookup reference or otherwise obfuscated. The issuing provider is responsible for dereferencing 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 identifier the Network Code or domain Jakobsson & Smith Expires July 25, 2010 [Page 4] Internet-Draft Abbreviated Title January 2010 name MUST be included, for cross-operator identification and to ensure it is known which entity can dereference 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 metadata, or to list the service endpoints which can consume the ACR. 4. Examples 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=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 5. Rationale 5.1. Privacy policies Existing privacy policies and legislation restrict the sharing of certain user identifiers, such as the MSISDN, since it may be used to broach a user' s privacy (unauthorized location lookup, cold calling, SMS Spam etc.). An ACR prevents such identifiers from being circulated. 5.2. Cookie support 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. 5.3. Sharing identity Mobile, broadband and other access networks do not typically share a user identifier. The acr is not bound to a particular access network Jakobsson & Smith Expires July 25, 2010 [Page 5] Internet-Draft Abbreviated Title January 2010 and can hence be used to provision user identifiers between networks. 5.4. Relation to SIP The ACR can help the implementation of SIP privacy considerations, as detailed in RFC3323 [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]. 6. Acknowledgements This document is built on top of RFC3966 [RFC3966], written by Henning Schulzerinne The editors of this document wishes to thank the GSMA ACCESS project members, Gautam Hazari and Douglas Robb for their comments and suggestions. We also would like to thank Frode Kileng for IETF guidance. 7. IANA Considerations This document includes a request to IANA. The editors of this draft request the protocol scheme name "acr" to be reserved for this RFC. 8. Security Considerations 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 [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: Jakobsson & Smith Expires July 25, 2010 [Page 6] Internet-Draft Abbreviated Title January 2010 o Calls or messages may incur costs. o The URI may be used to place malicious or annoying calls. o A call will take the user's phone line off-hook, thus preventing its use. o 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. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. 9.2. Informative References [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Jakobsson & Smith Expires July 25, 2010 [Page 7] Internet-Draft Abbreviated Title January 2010 Authors' Addresses Sune Jakobsson (editor) Telenor ASA GBD&R Otto Nielsens vei 12 Trondheim, 7004 Norway Phone: +47 995 17 017 Email: sune.jakobsson@telenor.com Kevin Smith (editor) Vodafone-Group (R&D) One Kingdom Street London, WC2R 0RJ UK Phone: +44 78 251 06 554 Email: kevin.smith@vodafone.com Jakobsson & Smith Expires July 25, 2010 [Page 8]