



Network Working Group                                     P. Saint-Andre
Internet-Draft
Intended status: Standards Track                        January 23, 2014
Expires: July 27, 2014


                         The 'acct' URI Scheme
                     draft-ietf-appsawg-acct-uri-07

Abstract

   This document defines the 'acct' Uniform Resource Identifier (URI)
   scheme as a way to identify a user's account at a service provider,
   irrespective of the particular protocols that can be used to interact
   with the account.

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 27, 2014.

Copyright Notice

   Copyright (c) 2014 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.




Saint-Andre               Expires July 27, 2014                 [Page 1]

Internet-Draft            The 'acct' URI Scheme             January 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  Definition  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Internationalization Considerations . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Existing Uniform Resource Identifier (URI) schemes that enable
   interaction with, or that identify resources associated with, a
   user's account at a service provider are tied to particular services
   or application protocols.  Two examples are the 'mailto' scheme
   (which enables interaction with a user's email account) and the
   'http' scheme (which enables retrieval of web files controlled by a
   user or interaction with interfaces providing information about a
   user).  However, there exists no URI scheme that generically
   identifies a user's account at a service provider without specifying
   a particular protocol to use when interacting with the account.  This
   specification fills that gap.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

3.  Rationale

   During formalization of the WebFinger protocol [RFC7033], much
   discussion occurred regarding the appropriate URI scheme to include
   when specifying a user's account as a web link [RFC5988].  Although
   both the 'mailto' [RFC6068] and 'http' [RFC2616] schemes were
   proposed, not all service providers offer email services or web
   interfaces on behalf of user accounts (e.g., a microblogging or
   instant messaging provider might not offer email services, or an
   enterprise might not offer HTTP interfaces to information about its
   employees).  Therefore, the participants in the discussion recognized
   that it would be helpful to define a URI scheme that could be used to
   generically identify a user's account at a service provider,
   irrespective of the particular application protocols used to interact



Saint-Andre               Expires July 27, 2014                 [Page 2]

Internet-Draft            The 'acct' URI Scheme             January 2014


   with the account.  The result was the 'acct' URI scheme defined in
   this document.

   (Note that a user is not necessarily a human; it could be an
   automated application such as a bot, a role-based alias, etc.
   However, an 'acct' URI is always used to identify something that has
   an account at a service, not the service itself.)

4.  Definition

   The syntax of the 'acct' URI scheme is defined under Section 7 of
   this document.  Although 'acct' URIs take the form "user@host", the
   scheme is designed for the purpose of identification instead of
   interaction (regarding this distinction, see Section 1.2.2 of
   [RFC3986]).  The "Internet resource" identified by an 'acct' URI is a
   user's account hosted at a service provider, where the service
   provider is typically associated with a DNS domain name.  Thus a
   particular 'acct' URI is formed by setting the "user" portion to the
   user's account name at the service provider and by setting the "host"
   portion to the DNS domain name of the service provider.

   Consider the case of a user with an account name of "foobar" on a
   microblogging service "status.example.net".  It is taken as
   convention that the string "foobar@status.example.net" designates
   that account.  This is expressed as a URI using the 'acct' scheme as
   "acct:foobar@status.example.net".

   A common scenario is for a user to register with a service provider
   using an identifier (such as an email address) that is associated
   with some other service provider.  For example, a user with the email
   address "juliet@capulet.example" might register with a commerce
   website whose domain name is "shoppingsite.example".  In order to use
   her email address as the localpart of the 'acct' URI, the at-sign
   character (U+0040) needs to be percent-encoded as described in
   [RFC3986].  Thus the resulting 'acct' URI would be
   "acct:juliet%40capulet.example@shoppingsite.example".

   It is not assumed that an entity will necessarily be able to interact
   with a user's account using any particular application protocol, such
   as email; to enable such interaction, an entity would need to use the
   appropriate URI scheme for such a protocol, such as the 'mailto'
   scheme.  While it might be true that the 'acct' URI minus the scheme
   name (e.g., "user@example.com" derived from "acct:user@example.com")
   can be reached via email or some other application protocol, that
   fact would be purely contingent and dependent upon the deployment
   practices of the provider.





Saint-Andre               Expires July 27, 2014                 [Page 3]

Internet-Draft            The 'acct' URI Scheme             January 2014


   Because an 'acct' URI enables abstract identification only and not
   interaction, this specification provides no method for dereferencing
   an 'acct' URI on its own, e.g., as the value of the 'href' attribute
   of an HTML anchor element.  For example, there is no behavior
   specified in this document for an 'acct' URI used as follows:

   <a href='acct:bob@example.com'>find out more</a>


   Any protocol that uses 'acct' URIs is responsible for specifying how
   an 'acct' URI is employed in the context of that protocol (in
   particular, how it is dereferenced or resolved; see [RFC3986]).  As a
   concrete example, an "Account Information" application of the
   WebFinger protocol [RFC7033] might take an 'acct' URI, resolve the
   host portion to find a WebFinger server, and then pass the 'acct' URI
   as a parameter in a WebFinger HTTP request for metadata (i.e., web
   links [RFC5988]) about the resource.  For example:

   GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1


   The service retrieves the metadata associated with the account
   identified by that URI and then provides that metadata to the
   requesting entity in an HTTP response.

   If an application needs to compare two 'acct' URIs (e.g., for
   purposes of authentication and authorization), it MUST do so using
   case normalization and percent-encoding normalization as specified in
   Sections 6.2.2.1 and 6.2.2.2 of [RFC3986].

5.  Security Considerations

   Because the 'acct' URI scheme does not directly enable interaction
   with a user's account at a service provider, direct security concerns
   are minimized.

   However, an 'acct' URI does provide proof of existence of the
   account; this implies that harvesting published 'acct' URIs could
   prove useful to spammers and similar attackers, for example if they
   can use an 'acct' URI to leverage more information about the account
   (e.g., via WebFinger) or if they can interact with protocol-specific
   URIs (such as 'mailto' URIs) whose user@host portion is the same as
   that of the 'acct' URI.

   In addition, protocols that make use of 'acct' URIs are responsible
   for defining security considerations related to such usage, e.g., the
   risks involved in dereferencing an 'acct' URI, the authentication and
   authorization methods that could be used to control access to



Saint-Andre               Expires July 27, 2014                 [Page 4]

Internet-Draft            The 'acct' URI Scheme             January 2014


   personal data associated with a user's account at a service, and
   methods for ensuring the confidentiality of such information.

   The use of percent-encoding allows a wider range of characters in
   account names, but introduces some additional risks.  Implementers
   are advised to disallow percent-encoded characters or sequences that
   would (1) result in space, null, control, or other characters that
   are otherwise forbidden, (2) allow unauthorized access to private
   data, or (3) lead to other security vulnerabilities.

6.  Internationalization Considerations

   As specified in [RFC3986], the 'acct' URI scheme allows any character
   from the Unicode repertoire [UNICODE] encoded as UTF-8 [RFC3629] and
   then percent-encoded into valid ASCII [RFC20].  Before applying any
   percent-encoding, an application MUST ensure the following about the
   string that is used as input to the URI-construction process:

   o  The userpart consists only of Unicode code points that conform to
      the PRECIS IdentifierClass specified in
      [I-D.ietf-precis-framework].

   o  The host consists only of Unicode code points that conform to the
      rules specified in [RFC5892].

   o  Internationalized domain name (IDN) labels are encoded as A-labels
      [RFC5890].

7.  IANA Considerations

   In accordance with the guidelines and registration procedures for new
   URI schemes [RFC4395], this section provides the information needed
   to register the 'acct' URI scheme.

7.1.  URI Scheme Name

   acct

7.2.  Status

   permanent

7.3.  URI Scheme Syntax

   The 'acct' URI syntax is defined here in Augmented Backus-Naur Form
   (ABNF) [RFC5234], borrowing the 'host', 'pct-encoded', 'sub-delims',
   'unreserved' rules from [RFC3986]:




Saint-Andre               Expires July 27, 2014                 [Page 5]

Internet-Draft            The 'acct' URI Scheme             January 2014


   acctURI      =  "acct" ":" userpart "@" host
   userpart     =  unreserved / sub-delims
                   0*( unreserved / pct-encoded / sub-delims )


   Note that additional rules regarding the strings that are used as
   input to construction of 'acct' URIs further limit the characters
   that can be percent-encoded; see the Encoding Considerations as well
   as Section 6 of RFC XXXX.  [Note to RFC Editor: please replace XXXX
   with the number issued to this document.]

7.4.  URI Scheme Semantics

   The 'acct' URI scheme identifies accounts hosted at service
   providers.  It is used only for identification, not interaction.  A
   protocol that employs the 'acct' URI scheme is responsible for
   specifying how an 'acct' URI is dereferenced in the context of that
   protocol.  There is no media type associated with the 'acct' URI
   scheme.

7.5.  Encoding Considerations

   See Section 6 of RFC XXXX.  [Note to RFC Editor: please replace XXXX
   with the number issued to this document.]

7.6.  Applications/Protocols That Use This URI Scheme Name

   At the time of this writing, only the WebFinger protocol uses the
   'acct' URI scheme.  However, use is not restricted to the WebFinger
   protocol, and the scheme might be considered for use in other
   protocols.

7.7.  Interoperability Considerations

   There are no known interoperability concerns related to use of the
   'acct' URI scheme.

7.8.  Security Considerations

   See Section 5 of RFC XXXX.  [Note to RFC Editor: please replace XXXX
   with the number issued to this document.]

7.9.  Contact

   Peter Saint-Andre, psaintan@cisco.com

7.10.  Author/Change Controller




Saint-Andre               Expires July 27, 2014                 [Page 6]

Internet-Draft            The 'acct' URI Scheme             January 2014


   This scheme is registered under the IETF tree.  As such, the IETF
   maintains change control.

7.11.  References

   None.

8.  References

8.1.  Normative References

   [I-D.ietf-precis-framework]
              Saint-Andre, P. and M. Blanchet, "Precis Framework:
              Handling Internationalized Strings in Protocols", draft-
              ietf-precis-framework-13 (work in progress), December
              2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, August 2010.

   [RFC5892]  Faltstrom, P., "The Unicode Code Points and
              Internationalized Domain Names for Applications (IDNA)",
              RFC 5892, August 2010.

   [UNICODE]  The Unicode Consortium, "The Unicode Standard, Version
              6.1", 2012,
              <http://www.unicode.org/versions/Unicode6.1.0/>.

8.2.  Informative References

   [RFC20]    Cerf, V., "ASCII format for network interchange", RFC 20,
              October 1969.





Saint-Andre               Expires July 27, 2014                 [Page 7]

Internet-Draft            The 'acct' URI Scheme             January 2014


   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", BCP 35, RFC
              4395, February 2006.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988, October 2010.

   [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
              URI Scheme", RFC 6068, October 2010.

   [RFC7033]  Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
              "WebFinger", RFC 7033, September 2013.

Appendix A.  Acknowledgements

   The 'acct' URI scheme was originally proposed during work on the
   WebFinger protocol; special thanks are due to Blaine Cook, Brad
   Fitzpatrick, and Eran Hammer-Lahav for their early work on the
   concept (which in turn was partially inspired by work on Extensible
   Resource Indentifiers at OASIS).  The scheme was first formally
   specified in [RFC7033]; the authors of that specification (Paul
   Jones, Gonzalo Salgueiro, and Joseph Smarr) are gratefully
   acknowledged.  Thanks are also due to Stephane Bortzmeyer, Melvin
   Carvalho, Martin Duerst, Graham Klyne, Barry Leiba, Subramanian
   Moonesamy, Evan Prodromou, James Snell, and various participants in
   the IETF APPSAWG for their feedback.  Meral Shirazipour completed a
   Gen-ART review.  Dave Cridland completed an AppsDir review, and is
   gratefully acknowledged for providing proposed text that was
   incorporated into Section 3 and Section 5.  IESG comments from
   Richard Barnes, Adrian Farrel, Stephen Farrell, Barry Leiba, Pete
   Resnick, and Sean Turner also led to improvements in the
   specification.

Author's Address

   Peter Saint-Andre

   Email: ietf@stpeter.im










Saint-Andre               Expires July 27, 2014                 [Page 8]
