summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7565.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7565.txt')
-rw-r--r--doc/rfc/rfc7565.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc7565.txt b/doc/rfc/rfc7565.txt
new file mode 100644
index 0000000..273c125
--- /dev/null
+++ b/doc/rfc/rfc7565.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) P. Saint-Andre
+Request for Comments: 7565 May 2015
+Category: Standards Track
+ISSN: 2070-1721
+
+
+ The 'acct' URI Scheme
+
+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 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 in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://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 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 Standards Track [Page 1]
+
+RFC 7565 The 'acct' URI Scheme May 2015
+
+
+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 ......................................................6
+ 8.1. Normative References .......................................6
+ 8.2. Informative References .....................................7
+ 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' [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 to
+
+
+
+Saint-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 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 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
+ 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
+ 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 as Section 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: See Section 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: See Section 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. References
+
+8.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 2015
+
+
+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 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 Sections 3 and 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: peter@andyet.com
+ URI: https://andyet.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 8]
+