idnits 2.17.00 (12 Aug 2021) /tmp/idnits2397/draft-uri-acr-extension-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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: -- The document date (March 1, 2012) is 3733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Jakobsson, Ed. 3 Internet-Draft Telenor ASA Digital Services 4 Intended status: Informational K. Smith, Ed. 5 Expires: September 2, 2012 Vodafone-Group (R&D) 6 March 1, 2012 8 The acr URI for anonymous users 9 draft-uri-acr-extension-04 11 Abstract 13 This document specifies the URI (Uniform Resource Identifier) scheme 14 "acr". The "acr" URI describes an anonymous reference, that can be 15 mapped to a resource or user. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 2, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. URI syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5.1. Privacy policies . . . . . . . . . . . . . . . . . . . . . 5 57 5.2. Cookie support . . . . . . . . . . . . . . . . . . . . . . 6 58 5.3. Sharing identity . . . . . . . . . . . . . . . . . . . . . 6 59 5.4. Relation to SIP . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 65 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 This document specifies the URI (Uniform Resource Identifier) scheme 71 "acr". This URI scheme is intended as an extension to the "tel:" 72 scheme but without disclosing the true identity of a reference or a 73 user. The "acr" URI describes an anonymous reference, that can be 74 mapped to a resource or a user. There are multiple situations where 75 the true identity of a user or a resources can not be disclosed. The 76 "acr" URI is a globally unique identifier ( "name" ) only; it does 77 not describe the steps necessary to reach the user or the device. 78 However it can contain a parameter indication what body or 79 organisation that could resolve it. It is intended for privacy 80 protection, where a user trusts a translating party, that can route 81 or forward the request or message to the true user or resource. 83 2. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119] and 88 indicate the requirements levels for compliant implementations. 90 3. URI syntax 92 The URI is defined using AB-NF (Augmented Backus-Naur Form) as 93 described in RFC 5234 [RFC5234] and uses elements from the core 94 definitions (appendix A of RFC 5234). 96 The syntax definition follows RFC 3986 [RFC3986], indicating the 97 actual characters contained in the URI. If the reserved characters 98 "+", ";", "=", and "?" are used as delimiters between components of 99 the "tel" URI, they MUST NOT be percent encoded. These characters 100 MUST be percent encoded if they appear in tel URI parameter values. 102 Characters other than those in the "reserved" and "unsafe" sets (see 103 RFC 3986 [RFC3986] ) are equivalent to their "% HEX HEX" percent 104 encoding. 106 The "acr" URI has the following syntax: 108 acr-uri = "acr:" anonymous-customer-reference 109 anonymous-customer-reference = 1*alphanum *par 110 par = parameter / network-code / acr-type / domainname 111 network-code = ";ncc=" 1*uric 112 acr-type = ";type=" 1*( "DYNA" / "STAT" ) 113 domainname = ";domain=" *( domainlabel "." ) toplabel [ "." ] 114 domainlabel = alphanum 115 / alphanum *( alphanum / "-" ) alphanum 116 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 117 parameter = ";" pname [ "=" pvalue ] 118 pname = 1*( alphanum / "-" ) 119 pvalue = 1*paramchar 120 paramchar = param-unreserved / unreserved / pct-encoded 121 unreserved = alphanum / mark 122 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" 123 pct-encoded = "%" HEXDIG HEXDIG 124 param-unreserved= "[" / "]" / "/" / ":" / "&" / "+" / "$" 125 alphanum = ALPHA / DIGIT 126 reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" 127 / "," 128 uric = reserved / unreserved / pct-encoded 129 DIGIT = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" 130 / "9" 131 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" / "a" 132 / "b" / "c" / "d" / "e" / "f" 133 ALPHA = lowalpha / upalpha 134 lowalpha = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" 135 / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" 136 / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" 137 upalpha = "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" 138 / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" 139 / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" 141 Figure 1 143 The "anonymous-subscriber-identifier" can be created from some 144 suitable user or customer data such as, phone number, and validation 145 date. In order to provide anonymisation, this data MUST not be 146 included unchanged within the ACR. Rather it MUST be encrypted, 147 hashed, represented by a look-up reference or otherwise obfuscated. 148 The issuing provider is responsible for unreferencing the ACR to the 149 user or resource. For example the SHA-256 algorithm can hash the 150 sensitive data: 152 SHA256("")= e3b0c442 98fc1c14 9afbf4c8 996fb924 27ae41e4 649b934c 153 a495991b 7852b855 154 In order to know who issued the "acr" identifier, the Network Code or 155 domain name MUST be included, for cross-operator identification and 156 to ensure it is known which entity can deference the ACR. In 157 addition a network country identifier MUST be provided (either as 158 part of the network code, or separately) to avoid confusion where 159 networks operate in multiple countries. A URI for ACR documentation 160 MAY be included; for example, to discover further meta-data, or to 161 list the service endpoints which can consume the ACR. 163 The "network code" (ncc) is for mobile networks a concatenation of 164 "mobile country code" (MCC) and "mobile network code" (MNC) as 165 defined in ITU-T RECOMMENDATION E.212 167 As an example of ncc for Vodafone in UK, consists of MCC=234 and 168 MNC=15 would concatenate to ncc=23415 170 The acr-type indicates if the ACR is a static type or a temporary 171 type. 173 4. Examples 175 acr:0123456890123456789 This URI points to a user. for network 176 internal use only since the network code is not provided 178 acr:0123456890123456789;ncc=123 This URI points to a user belonging 179 to network 123 181 acr:0123456890123456789;ncc=23415;type=DYNA This temporal URI points 182 to a user or group of users and can be resolved by the Vodafone 183 mobile network in UK. 185 acr:0123456890123456789;ncc=123 This URI points to a group of users 186 belonging to network 123. 188 Note that the fact that more than one user is represented is not 189 intrinsic to the acr but only known to the issuing network. 191 acr:0123456890123456789;domain=example.com This URI points to a user 192 belonging in domain "example.com" 194 5. Rationale 196 5.1. Privacy policies 198 Existing privacy policies and legislation restrict the sharing of 199 certain user identifiers, such as the MSISDN, since it may be used to 200 breach a user's privacy (unauthorized location look-up, cold calling, 201 SMS Spam etc.). An "acr" prevents such identifiers from being 202 circulated. 204 5.2. Cookie support 206 Cookie support is inconsistent across mobile devices. An "acr" can 207 help identify a returning mobile user to a Website, and hence 208 facilitate the provisioning of a personalized service based on 209 previous preferences and activity. 211 5.3. Sharing identity 213 Mobile, broadband and other access networks do not typically share a 214 user identifier. The "acr" is not bound to a particular access 215 network and can hence be used to provision user identifiers between 216 networks. 218 5.4. Relation to SIP 220 The "acr" can help the implementation of SIP privacy considerations, 221 as detailed in RFC3323 [RFC3323], 'A Privacy Mechanism for the 222 Session Initiation Protocol'. Specifically the "acr" can be used as 223 the value for the 'anonymous from' header field [section 4.1], and is 224 consistent with the recommendation to remove Subject, Call-info, 225 Organization, User Agent, Reply-To, In-Reply-To in [section 5.3]. 227 6. Acknowledgements 229 This document is built on top of RFC3966 [RFC3966], written by 230 Henning Schulzerinne 232 The editors of this document wishes to thank the GSMA ACCESS project 233 members for their comments and suggestions. 235 7. IANA Considerations 237 This document includes a request to IANA. 239 The editors of this draft request the protocol scheme name "acr" to 240 be reserved for this RFC. 242 8. Security Considerations 244 Since the "acr" is used to protect the identity of a user or a device 245 the forwarding party must not disclose information that would or can 246 be used to reveal the identity of the user. However the network code 247 or domain name will reveal some information of the the "acr" 248 affiliation. 250 The security considerations parallel those for the "tel" URI RFC3966 251 [RFC3966]. 253 Web clients and similar tools MUST NOT use the "acr" URI to place 254 telephone calls or send messages without the explicit consent of the 255 user of that client. Placing calls or sending messages automatically 256 without appropriate user confirmation may incur a number of risks, 257 such as those described below: 259 o Calls or messages may incur costs. 261 o The URI may be used to place malicious or annoying calls. 263 o A call will take the user's phone line off-hook, thus preventing 264 its use. 266 o A call may reveal the user's possibly unlisted phone number to the 267 remote host in the caller identification data and may allow the 268 attacker to correlate the user's phone number with other 269 information, such as an e-mail or IP address. 271 This is particularly important for "acr" URIs embedded in HTML links, 272 as a malicious party may hide the true nature of the URI in the link 273 text, as in 275 Find free information here 276 Call RFC organization for help 278 "acr" URIs may reveal private information, similar to including phone 279 numbers as text. However, the presence of the "acr" schema 280 identifier may make it easier for an adversary using a search engine 281 to discover these numbers, and hence search engines should avoid 282 indexing these identifiers. 284 9. References 286 9.1. Normative References 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 292 Initiation Protocol (SIP)", RFC 3323, November 2002. 294 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 295 RFC 3966, December 2004. 297 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 298 Specifications: ABNF", STD 68, RFC 5234, January 2008. 300 9.2. Informative References 302 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 303 Resource Identifier (URI): Generic Syntax", STD 66, 304 RFC 3986, January 2005. 306 Authors' Addresses 308 Sune Jakobsson (editor) 309 Telenor ASA Digital Services 310 Otto Nielsens vei 12 311 Trondheim, 7004 312 Norway 314 Phone: +47 995 17 017 315 Email: sune.jakobsson@telenor.com 317 Kevin Smith (editor) 318 Vodafone-Group (R&D) 319 One Kingdom Street 320 London, WC2R 0RJ 321 UK 323 Phone: +44 78 251 06 554 324 Email: kevin.smith@vodafone.com