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 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
2.  Terminology
3.  URI syntax
4.  Examples
5.  Rationale
    5.1.  Privacy policies
    5.2.  Cookie support
    5.3.  Sharing identity
    5.4.  Relation to SIP
6.  Acknowledgements
7.  IANA Considerations
8.  Security Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Authors' Addresses

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [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 (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.) [RFC2234] and uses elements from the core definitions (appendix A of RFC 2234).

The syntax definition follows RFC 2396 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax,” August 1998.) [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 (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax,” August 1998.) [RFC2396] ) are equivalent to their "% HEX HEX" percent encoding.

The "acr" URI has the following syntax:

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"

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 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 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 (Peterson, J., “A Privacy Mechanism for the Session Initiation Protocol (SIP),” November 2002.) [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 (Schulzrinne, H., “The tel URI for Telephone Numbers,” December 2004.) [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 (Schulzrinne, H., “The tel URI for Telephone Numbers,” December 2004.) [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

   <a href="acr:123456">Find free information here</a>
   <a href="acr:123456">Call RFC organization for help</a>

"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

9.2. Informative References

Authors' Addresses