From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7565.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc7565.txt (limited to 'doc/rfc/rfc7565.txt') 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: + + find out more + + 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, + . + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of + ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, + November 2003, . + + [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, + . + + [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + + +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, + . + + [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and + Internationalized Domain Names for Applications (IDNA)", + RFC 5892, DOI 10.17487/RFC5892, August 2010, + . + + [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, + . + + [Unicode] The Unicode Consortium, "The Unicode Standard", + . + +8.2. Informative References + + [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, + RFC 20, DOI 10.17487/RFC0020, October 1969, + . + + [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, + . + + [RFC5988] Nottingham, M., "Web Linking", RFC 5988, + DOI 10.17487/RFC5988, October 2010, + . + + [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' + URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, + . + + [RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, + "WebFinger", RFC 7033, DOI 10.17487/RFC7033, + September 2013, . + + [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, + . + + + + + +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] + -- cgit v1.2.3