Movatterモバイル変換

Internet Engineering Task Force (IETF)                    P. Saint-AndreRequest for Comments: 7565                                      May 2015Category: Standards TrackISSN: 2070-1721The 'acct' URI SchemeAbstract   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 is an Internet Standards Track document.   This document is a product of the Internet Engineering Task Force   (IETF).  It represents the consensus of the IETF community.  It has   received public review and has been approved for publication by the   Internet Engineering Steering Group (IESG).  Further information on   Internet Standards is available inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7565.Copyright Notice   Copyright (c) 2015 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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                  Standards Track                    [Page 1]

RFC 7565                  The 'acct' URI Scheme                 May 2015Table of Contents1. Introduction ....................................................22. Terminology .....................................................23. Rationale .......................................................24. Definition ......................................................35. Security Considerations .........................................46. Internationalization Considerations .............................57. IANA Considerations .............................................58. References ......................................................68.1. Normative References .......................................68.2. Informative References .....................................7   Acknowledgements ...................................................8   Author's Address ...................................................81.  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' [RFC7230] 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 toSaint-Andre                  Standards Track                    [Page 2]

RFC 7565                  The 'acct' URI Scheme                 May 2015   generically identify a user's account at a service provider,   irrespective of the particular application protocols used to interact   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 underSection 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, seeSection 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                  Standards Track                    [Page 3]

RFC 7565                  The 'acct' URI Scheme                 May 2015   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   Sections6.2.2.1 and6.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   personal data associated with a user's account at a service, and   methods for ensuring the confidentiality of such information.Saint-Andre                  Standards Track                    [Page 4]

RFC 7565                  The 'acct' URI Scheme                 May 2015   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 [RFC7564].   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.   URI Scheme Name:  acct   Status:  permanent   URI Scheme Syntax:  The 'acct' URI syntax is defined here in      Augmented Backus-Naur Form (ABNF) [RFC5234], borrowing the 'host',      'pct-encoded', 'sub-delims', and 'unreserved' rules from      [RFC3986]:      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 asSection 6 of this document.Saint-Andre                  Standards Track                    [Page 5]

RFC 7565                  The 'acct' URI Scheme                 May 2015   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.   Encoding Considerations:  SeeSection 6 of this document.   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.   Interoperability Considerations:  There are no known interoperability      concerns related to use of the 'acct' URI scheme.   Security Considerations:  SeeSection 5 of this document.   Contact:  Peter Saint-Andre, peter@andyet.com   Author/Change Controller:  This scheme is registered under the IETF      tree.  As such, the IETF maintains change control.   References:  None.8.  References8.1.  Normative References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119,              DOI 10.17487/RFC2119, March 1997,              <http://www.rfc-editor.org/info/rfc2119>.   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of              ISO 10646", STD 63,RFC 3629, DOI 10.17487/RFC3629,              November 2003, <http://www.rfc-editor.org/info/rfc3629>.   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform              Resource Identifier (URI): Generic Syntax", STD 66,RFC 3986, DOI 10.17487/RFC3986, January 2005,              <http://www.rfc-editor.org/info/rfc3986>.   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for              Syntax Specifications: ABNF", STD 68,RFC 5234,              DOI 10.17487/RFC5234, January 2008,              <http://www.rfc-editor.org/info/rfc5234>.Saint-Andre                  Standards Track                    [Page 6]

RFC 7565                  The 'acct' URI Scheme                 May 2015   [RFC5890]  Klensin, J., "Internationalized Domain Names for              Applications (IDNA): Definitions and Document Framework",RFC 5890, DOI 10.17487/RFC5890, August 2010,              <http://www.rfc-editor.org/info/rfc5890>.   [RFC5892]  Faltstrom, P., Ed., "The Unicode Code Points and              Internationalized Domain Names for Applications (IDNA)",RFC 5892, DOI 10.17487/RFC5892, August 2010,              <http://www.rfc-editor.org/info/rfc5892>.   [RFC7564]  Saint-Andre, P. and M. Blanchet, "PRECIS Framework:              Preparation, Enforcement, and Comparison of              Internationalized Strings in Application Protocols",RFC 7564, DOI 10.17487/RFC7564, May 2015,              <http://www.rfc-editor.org/info/rfc7564>.   [Unicode]  The Unicode Consortium, "The Unicode Standard",              <http://www.unicode.org/versions/latest/>.8.2.  Informative References   [RFC20]    Cerf, V., "ASCII format for network interchange", STD 80,RFC 20, DOI 10.17487/RFC0020, October 1969,              <http://www.rfc-editor.org/info/rfc20>.   [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and              Registration Procedures for New URI Schemes",BCP 35,RFC 4395, DOI 10.17487/RFC4395, February 2006,              <http://www.rfc-editor.org/info/rfc4395>.   [RFC5988]  Nottingham, M., "Web Linking",RFC 5988,              DOI 10.17487/RFC5988, October 2010,              <http://www.rfc-editor.org/info/rfc5988>.   [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'              URI Scheme",RFC 6068, DOI 10.17487/RFC6068, October 2010,              <http://www.rfc-editor.org/info/rfc6068>.   [RFC7033]  Jones, P., Salgueiro, G., Jones, M., and J. Smarr,              "WebFinger",RFC 7033, DOI 10.17487/RFC7033,              September 2013, <http://www.rfc-editor.org/info/rfc7033>.   [RFC7230]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext              Transfer Protocol (HTTP/1.1): Message Syntax and Routing",RFC 7230, DOI 10.17487/RFC7230, June 2014,              <http://www.rfc-editor.org/info/rfc7230>.Saint-Andre                  Standards Track                    [Page 7]

RFC 7565                  The 'acct' URI Scheme                 May 2015Acknowledgements   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 Identifiers 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 Sections3 and5.  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: peter@andyet.com   URI:https://andyet.com/Saint-Andre                  Standards Track                    [Page 8]