ENUM Service Registration for acct URI
draft-goix-appsawg-enum-acct-uri-01

Abstract

This document registers a Telephone Number Mapping (ENUM) service for 'acct:' URIs (Uniform Resource Identifiers).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

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."

This Internet-Draft will expire on July 30, 2013.

Copyright Notice

Copyright (c) 2013 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 Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Use cases
• 3.1. Routing of mobile social communications
• 3.2. Reverse phone lookup
• 4. IANA Registration
• 5. Examples
• 6. DNS Considerations
• 7. Security Considerations
• 8. IANA Considerations
• 9. Acknowledgements
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Authors' Addresses

1. Introduction

ENUM (E.164 Number Mapping, [RFC6116]) is a system that uses DNS (Domain Name Service, [RFC1034]) to translate telephone numbers, such as '+44 1632 960123', into URIs (Uniform Resource Identifiers, [RFC3986]), such as 'acct:user@example.com'. ENUM exists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to identify resources.

[I-D.ietf-appsawg-webfinger] is proposing a generic mechanism to discover information about resources, including those identified through an account based on the 'acct:' URI scheme. [I-D.ietf-appsawg-acct-uri] defines the 'acct' URI scheme as a way to identify a user's account at a service provider.

This document registers an enumservice for advertising acct URI information associated with an E.164 number.

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 [RFC2119].

3. Use cases

3.1. Routing of mobile social communications

The Open Mobile Alliance (OMA) Social Network Web (SNeW) Enabler Release [OMA-SNeW-ER] has introduced a number of Social Networking functionalities to mobile subscribers identified by their MSISDN, amongst which the ability of following each other's social activities across service providers. Such functionality requires the global resolution of the MSISDN to the corresponding account and provider, in an analogous way as MMS routing, to identify the target endpoint for the related messages. Although alternatives solutions exist (e.g. based on mobile network operations and/or proprietary lookup techniques), ENUM provides a globally accessible mechanism for enabling resolution from network entities on behalf of an endpoint, or from an endpoint itself.

For example, a user of a service provider could request to follow the social activities of user '+44 1632 960123', triggering a network entity to perform an ENUM query, eventually followed by a Webfinger query, to route this request to the appropriate target provider and endpoint.

A similar mechanism can apply to other types of social networking-related messages or other communications targeted to a mobile subscriber.

3.2. Reverse phone lookup

Yet in another example, an address book endpoint could issue an ENUM query looking for a user's account to discover additional personal information about that user given his phone number, such as avatar and full name.

Similarly, an endpoint could trigger this resolution process during inbound and/or outbound calls to discover additional personal information about the remote party.

The provision of an ENUM record to map a phone number into an account may be useful for businesses or professional workers to identify themselves publicly (in a similar way as vCard enum records), or be used in conjunction with privacy policies to provide a more controlled view on some personal details.

4. IANA Registration

As defined in [RFC6117], the following is a template covering information needed for the registration of the enumservice specified in this document:

           <record>
             <class>Application-Based, Common</class>
             <type>acct</type>
             <urischeme>acct</urischeme>
             <functionalspec>
               <paragraph>
                 This enumservice indicates that the resource
                 can be addressed by the associated URI enabling the 
				 use of 
<xref target='I-D.ietf-appsawg-webfinger' /> 
				 to discover additional information.
               </paragraph>
             </functionalspec>
             <security>
               See <xref target="security" />.
             </security>
             <usage>COMMON</usage>
             <registrationdocs>
               This document.
             </registrationdocs>
             <requesters>
               <xref type="person" data="Laurent_Walter_Goix"/>
             </requesters>
           </record>

           <people>
             <person id="Laurent_Walter_Goix">
               <name>Laurent-Walter Goix</name>
               <org>Telecom Italia</org>
               <uri>mailto:laurentwalter.goix@telecomitalia.it</uri>
               <updated>2013-01-25</updated>
             </person>
           </people>      
        

5. Examples

The following is an example of the use of the enumservice registered by this document in a NAPTR resource record for phone number +44 1632 960123.

$ORIGIN 3.2.1.0.6.9.2.3.6.1.4.4.e164.arpa.

IN NAPTR 10 100 "u" "E2U+acct" "!^.*$!acct:441632960123@foo.com!" .

IN NAPTR 10 101 "u" "E2U+acct" "!^.*$!acct:john.doe@example.com!" .

Note that in the first record, the revealed information is limited to the domain of the service provider serving that user a the userpart of the acct URI simply replicates the phone number.

6. DNS Considerations

If no "E2U+acct" NAPTR record exist for the requested number, the resolution process over issuing ENUM queries may be recursively performed over E.164 numbers identified by other NAPTR records for the requested number pointing to "tel" URIs [RFC3966]. Whilst this process is useful to support, amongst others, number portability as per [RFC4769], Section 4, this may also create potential loops in this resolution process. As such ENUM clients performing such ENUM queries over "tel" URIs to identify "acct" URIs SHOULD understand the "enumdi" indicator defined in [RFC4759]. In particular, if the result of the query does not include "E2U+acct" NAPTR records, and includes a NAPTR resource record containing a "tel" URI that has the same E.164 number, or a "tel" URI with the "enumdi" parameter set, that client SHOULD NOT perform subsequent ENUM queries over such numbers and SHOULD consider that the original requested number cannot be mapped.

Furthermore the client MAY stop performing subsequent ENUM queries after the fifth recursive query as suggested in [RFC6116] section 5.2.1.

7. Security Considerations

DNS, as used by ENUM, is a global, distributed database. Should implementers of this specification use e164.arpa or any other publicly available domain as the tree for maintaining PSTN enumservice data, this information would be visible to anyone anonymously.

As noted earlier, carriers, service providers, and other users may choose not to publish such information in the public e164.arpa tree. They may instead simply publish this in an internal ENUM infrastructure that is only able to be queried by trusted elements of their network, thus limiting threats.

Per se, this enumservice does not introduce specific security considerations beyond [RFC6116], section 7. However, it has to be acknowledged that the proposed enumservice could lead to the discovery or disclosure of Personally Identifiable Information (PII) when used in combination with the WebFinger protocol. Please see [I-D.ietf-appsawg-webfinger] , section 10 for additional information regarding WebFinger security.

Linking telephone numbers to Personally Identifiable Information (PII) is a very sensitive topic, because it provides a "reverse lookup" from the phone number to its owner. Publication of such PII is covered by data-protection law in many legislations. In most cases, the explicit consent of the affected individual is required.

Users MUST therefore carefully consider the information provided in the resource identified by the ENUM record as well as in the record itself. Considerations SHOULD include serving information only to entities of the user's choice and/or limiting the comprehension of the information provided based on the identity of the requestor.

It is important to remind that the ENUM record itself does not need to contain any personal information but only contains a pointer to an account identifier. This identifier may be queried through the Webfinger protocol to discover pointers to personal information (e.g. social network information) and an authorisation mechanism may be in place in that context with any level of granularity although it is out of scope of this document.

Technically, ENUM records themselves could contain pointers to the same endpoints discoverable through Webfinger. However the visibility of ENUM records cannot be controlled based on the requesting entity. In that context the simple mapping of the phone number to the account identifier, notwithstanding the disclosure of the association itself, still enables the reuse of more advanced access policies.

8. IANA Considerations

This document requests the IANA registration of the enumservice with Type "acct" according to the definitions in this document, [RFC6116] and [RFC6117].

Details of the registration are given in Section 4.

9. Acknowledgements

The authors would like to thank Gonzalo Salgueiro, Paul Jones, Lawrence Conroy, Enrico Marocco and Bert Greevenbosch for their valuable feedback to improve this document.

10. References

10.1. Normative References

10.2. Informative References

Authors' Addresses