idnits 2.17.1 draft-ietf-appsawg-acct-uri-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 1, 2013) is 4012 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-appsawg-webfinger-13 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track May 1, 2013 5 Expires: November 2, 2013 7 The 'acct' URI Scheme 8 draft-ietf-appsawg-acct-uri-04 10 Abstract 12 This document defines the 'acct' Uniform Resource Identifier (URI) 13 scheme as a way to identify a user's account at a service provider, 14 irrespective of the particular protocols that can be used to interact 15 with the account. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 2, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 59 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 60 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 1. Introduction 65 Existing Uniform Resource Identifier (URI) schemes that enable 66 interaction with, or that identify resources associated with, a 67 user's account at a service provider are tied to particular services 68 or application protocols. Two examples are the 'mailto' scheme 69 (which enables interaction with a user's email account) and the 70 'http' scheme (which enables retrieval of web files controlled by a 71 user or interaction with interfaces providing information about a 72 user). However, there exists no URI scheme that generically 73 identifies a user's account at a service provider without specifying 74 a particular protocol to use when interacting with the account. This 75 specification fills that gap. 77 2. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 81 "OPTIONAL" in this document are to be interpreted as described in 82 [RFC2119]. 84 3. Rationale 86 During formalization of the WebFinger protocol 87 [I-D.ietf-appsawg-webfinger], much discussion occurred regarding the 88 appropriate URI scheme to include when specifying a user's account as 89 a web link [RFC5988]. Although both the 'mailto' [RFC6068] and 90 'http' [RFC2616] schemes were proposed, not all service providers 91 offer email services or web interfaces on behalf of user accounts 92 (e.g., a microblogging or instant messaging provider might not offer 93 email services, or an enterprise might not offer HTTP interfaces to 94 information about its employees). Therefore, the participants in the 95 discussion recognized that it would be helpful to define a URI scheme 96 that could be used to generically identify a user's account at a 97 service provider, irrespective of the particular application 98 protocols used to interact with the account. The result was the 99 'acct' URI scheme defined in this document. 101 (Note that a user is not necessarily a human; it could be an 102 automated application such as a bot, a role-based alias, etc. 103 However, an 'acct' URI is always used to identify something that has 104 an account at a service, not the service itself.) 106 4. Definition 108 The syntax of the 'acct' URI scheme is defined under Section 5 of 109 this document. Although 'acct' URIs take the form "user@host", the 110 scheme is designed for the purpose of identification instead of 111 interaction (regarding this distinction, see Section 1.2.2 of 112 [RFC3986]). The "Internet resource" identified by an 'acct' URI is a 113 user's account hosted at a service provider, where the service 114 provider is typically associated with a DNS domain name. Thus a 115 particular 'acct' URI is formed by setting the "user" portion to the 116 user's account name at the service provider and by setting the "host" 117 portion to the DNS domain name of the service provider. 119 Consider the case of a user with an account name of "foobar" on a 120 microblogging service "status.example.net". It is taken as 121 convention that the string "foobar@status.example.net" designates 122 that account. This is expressed as a URI using the 'acct' scheme as 123 "acct:foobar@status.example.net". 125 It is not assumed that an entity will necessarily be able to interact 126 with a user's account using any particular application protocol, such 127 as email; to enable such interaction, an entity would need to use the 128 appropriate URI scheme for such a protocol, such as the 'mailto' 129 scheme. While it might be true that the 'acct' URI minus the scheme 130 name (e.g., "user@example.com" derived from "acct:user@example.com") 131 can be reached via email or some other application protocol, that 132 fact would be purely contingent and dependent upon the deployment 133 practices of the provider. 135 Because an 'acct' URI enables abstract identification only and not 136 interaction, this specification provides no method for dereferencing 137 an 'acct' URI on its own, e.g., as the value of the 'href' attribute 138 of an HTML anchor element. For example, there is no behavior 139 specified in this document for an 'acct' URI used as follows: 141 find out more 143 Instead, an 'acct' URI is employed indirectly and typically is passed 144 around as a parameter in the background within a protocol flow so 145 that an entity can interact with a resource related to that 146 identified by the 'acct' URI in a particular way or for a particular 147 purpose. For example, in the WebFinger protocol 148 [I-D.ietf-appsawg-webfinger] an 'acct' URI is used to identify the 149 resource about which an entity would like to discover metadata 150 expressed as "web links" [RFC5988]; the relevant HTTP request passes 151 an 'acct' URI (or some other URI) as the value of a "resource" 152 parameter, as shown in the following example: 154 GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1 156 Therefore, any protocol that uses 'acct' URIs, such as the WebFinger 157 protocol [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery 158 protocol [I-D.jones-simple-web-discovery], is responsible for 159 specifying how an 'acct' URI is employed in the context of that 160 protocol (in particular, how it is dereferenced or resolved; see 161 [RFC3986]). As a concrete example, in the WebFinger protocol an 162 'acct' URI is passed as a parameter in an HTTP request for metadata 163 (i.e., web links) about the resource; the service retrieves the 164 metadata associated with the account identified by that URI and then 165 provides that metadata to the requesting entity in an HTTP response 166 (see [I-D.ietf-appsawg-webfinger] for details). Similar 167 functionality is envisioned for other uses of 'acct' URIs. 169 If an application needs to compare two 'acct' URIs (e.g., for 170 purposes of authentication and authorization), it MUST do so using 171 case normalization and percent-encoding normalization as specified in 172 Sections 6.2.2.1 and 6.2.2.2 of [RFC3986]. 174 5. IANA Considerations 176 In accordance with the guidelines and registration procedures for new 177 URI schemes [RFC4395], this section provides the information needed 178 to register the 'acct' URI scheme. 180 5.1. URI Scheme Name 182 acct 184 5.2. Status 186 permanent 188 5.3. URI Scheme Syntax 190 The 'acct' URI syntax is defined here in Augmented Backus-Naur Form 191 (ABNF) [RFC5234], borrowing the 'host', 'pct-encoded', 'sub-delims', 192 'unreserved' rules from [RFC3986]: 194 acctURI = "acct" ":" userpart "@" host 195 userpart = unreserved / sub-delims 196 0*( unreserved / pct-encoded / sub-delims ) 198 5.4. URI Scheme Semantics 200 The 'acct' URI scheme identifies accounts hosted at service 201 providers. It is used only for identification, not interaction. A 202 protocol that employs the 'acct' URI scheme is responsible for 203 specifying how an 'acct' URI is dereferenced in the context of that 204 protocol. There is no media type associated with the 'acct' URI 205 scheme. 207 5.5. Encoding Considerations 209 As specified in [RFC3986], the 'acct' URI scheme allows any character 210 from the Unicode repertoire [UNICODE] encoded as UTF-8 [RFC3629] and 211 then percent-encoded into valid ASCII [RFC20]. Note that domain 212 labels need to be encoded as A-labels (see [RFC5890]) in order to 213 support internationalized domain names (IDNs). 215 5.6. Applications/Protocols That Use This URI Scheme Name 217 At the time of this writing, only the WebFinger protocol uses the 218 'acct' URI scheme. However, use is not restricted to the WebFinger 219 protocol, and the scheme might be considered for use in other 220 protocols, such as Simple Web Discovery. 222 5.7. Interoperability Considerations 224 There are no known interoperability concerns related to use of the 225 'acct' URI scheme. 227 5.8. Security Considerations 229 See Section 5 of RFC XXXX. [Note to RFC Editor: please replace XXXX 230 with the number issued to this document.] 232 5.9. Contact 234 Peter Saint-Andre, psaintan@cisco.com 236 5.10. Author/Change Controller 238 This scheme is registered under the IETF tree. As such, the IETF 239 maintains change control. 241 5.11. References 243 None. 245 6. Security Considerations 247 Because the 'acct' URI scheme does not directly enable interaction 248 with a user's account at a service provider, direct security concerns 249 are minimized. 251 However, an 'acct' URI does provide proof of existence of the 252 account; this implies that harvesting published 'acct' URIs could 253 prove useful to spammers and similar attackers, for example if they 254 can use an 'acct' URI to leverage more information about the account 255 (e.g., via WebFinger) or if they can interact with protocol-specific 256 URIs (such as 'mailto' URIs) whose user@host portion is the same as 257 that of the 'acct' URI. 259 In addition, protocols that make use of 'acct' URIs are responsible 260 for defining security considerations related to such usage, e.g., the 261 risks involved in dereferencing an 'acct' URI, the authentication and 262 authorization methods that could be used to control access to 263 personal data associated with a user's account at a service, and 264 methods for ensuring the confidentiality of such information. 266 The use of percent-encoding allows a wider range of characters in 267 account names, but introduces some additional risks. Implementers 268 are advised to disallow percent-encoded characters or sequences that 269 would (1) result in space, null, control, or other characters that 270 are otherwise forbidden, (2) allow unauthorized access to private 271 data, or (3) lead to other security vulnerabilities. 273 7. References 275 7.1. Normative References 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, March 1997. 280 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 281 Resource Identifier (URI): Generic Syntax", STD 66, 282 RFC 3986, January 2005. 284 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 285 Specifications: ABNF", STD 68, RFC 5234, January 2008. 287 7.2. Informative References 289 [I-D.ietf-appsawg-webfinger] 290 Jones, P., Salgueiro, G., and J. Smarr, "WebFinger", 291 draft-ietf-appsawg-webfinger-13 (work in progress), 292 April 2013. 294 [I-D.jones-simple-web-discovery] 295 Jones, M. and Y. Goland, "Simple Web Discovery (SWD)", 296 draft-jones-simple-web-discovery-04 (work in progress), 297 November 2012. 299 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 300 October 1969. 302 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 303 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 304 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 306 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 307 10646", STD 63, RFC 3629, November 2003. 309 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 310 Registration Procedures for New URI Schemes", BCP 35, 311 RFC 4395, February 2006. 313 [RFC5890] Klensin, J., "Internationalized Domain Names for 314 Applications (IDNA): Definitions and Document Framework", 315 RFC 5890, August 2010. 317 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 319 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 320 URI Scheme", RFC 6068, October 2010. 322 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 323 6.1", 2012, 324 . 326 Appendix A. Acknowledgements 328 The 'acct' URI scheme was originally proposed during work on the 329 WebFinger protocol; special thanks are due to Blaine Cook, Brad 330 Fitzpatrick, and Eran Hammer-Lahav for their early work on the 331 concept (which in turn was partially inspired by work on Extensible 332 Resource Indentifiers at OASIS). The scheme was first formally 333 specified in [I-D.ietf-appsawg-webfinger]; the authors of that 334 specification (Paul Jones, Gonzalo Salgueiro, and Joseph Smarr) are 335 gratefully acknowledged. Thanks are also due to Melvin Carvalho, 336 Martin Duerst, Graham Klyne, Barry Leiba, Subramanian Moonesamy, Evan 337 Prodromou, James Snell, and other participants in the IETF APPSAWG 338 for their feedback. Meral Shirazipour completed a Gen-ART review. 340 Dave Cridland completed an AppsDir review, and is gratefully 341 acknowledged for providing proposed text that was incorporated into 342 Section 3 and Section 5. IESG comments from Richard Barnes, Adrian 343 Farrel, Stephen Farrell, Pete Resnick, and Sean Turner also led to 344 improvements in the specification. 346 Author's Address 348 Peter Saint-Andre 349 Cisco Systems, Inc. 350 1899 Wynkoop Street, Suite 600 351 Denver, CO 80202 352 USA 354 Email: psaintan@cisco.com