idnits 2.17.1 draft-ietf-appsawg-acct-uri-05.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 (June 17, 2013) is 3956 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-14 -- 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 June 17, 2013 5 Expires: December 19, 2013 7 The 'acct' URI Scheme 8 draft-ietf-appsawg-acct-uri-05 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 December 19, 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 . . . . . . . . . . . . . . . . . . 8 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 A common scenario is for a user to register with a service provider 126 using an identifier (such as an email address) that is associated 127 with some other service provider. For example, a user with the email 128 address "juliet@capulet.example" might register with a commerce 129 website whose domain name is "shoppingsite.example". In order to use 130 her email address as the localpart of the 'acct' URI, the at-sign 131 character (U+0040) needs to be percent-encoded as described in 132 [RFC3986]. Thus the resulting 'acct' URI would be 133 "juliet%40capulet.example@shoppingsite.example.com". 135 It is not assumed that an entity will necessarily be able to interact 136 with a user's account using any particular application protocol, such 137 as email; to enable such interaction, an entity would need to use the 138 appropriate URI scheme for such a protocol, such as the 'mailto' 139 scheme. While it might be true that the 'acct' URI minus the scheme 140 name (e.g., "user@example.com" derived from "acct:user@example.com") 141 can be reached via email or some other application protocol, that 142 fact would be purely contingent and dependent upon the deployment 143 practices of the provider. 145 Because an 'acct' URI enables abstract identification only and not 146 interaction, this specification provides no method for dereferencing 147 an 'acct' URI on its own, e.g., as the value of the 'href' attribute 148 of an HTML anchor element. For example, there is no behavior 149 specified in this document for an 'acct' URI used as follows: 151 find out more 153 Instead, an 'acct' URI is employed indirectly and typically is passed 154 around as a parameter in the background within a protocol flow so 155 that an entity can interact with a resource related to that 156 identified by the 'acct' URI in a particular way or for a particular 157 purpose. For example, in the WebFinger protocol 158 [I-D.ietf-appsawg-webfinger] an 'acct' URI is used to identify the 159 resource about which an entity would like to discover metadata 160 expressed as "web links" [RFC5988]; the relevant HTTP request passes 161 an 'acct' URI (or some other URI) as the value of a "resource" 162 parameter, as shown in the following example: 164 GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1 166 Therefore, any protocol that uses 'acct' URIs, such as the WebFinger 167 protocol [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery 168 protocol [I-D.jones-simple-web-discovery], is responsible for 169 specifying how an 'acct' URI is employed in the context of that 170 protocol (in particular, how it is dereferenced or resolved; see 171 [RFC3986]). As a concrete example, in the WebFinger protocol an 172 'acct' URI is passed as a parameter in an HTTP request for metadata 173 (i.e., web links) about the resource; the service retrieves the 174 metadata associated with the account identified by that URI and then 175 provides that metadata to the requesting entity in an HTTP response 176 (see [I-D.ietf-appsawg-webfinger] for details). Similar 177 functionality is envisioned for other uses of 'acct' URIs. 179 If an application needs to compare two 'acct' URIs (e.g., for 180 purposes of authentication and authorization), it MUST do so using 181 case normalization and percent-encoding normalization as specified in 182 Sections 6.2.2.1 and 6.2.2.2 of [RFC3986]. 184 5. IANA Considerations 186 In accordance with the guidelines and registration procedures for new 187 URI schemes [RFC4395], this section provides the information needed 188 to register the 'acct' URI scheme. 190 5.1. URI Scheme Name 192 acct 194 5.2. Status 196 permanent 198 5.3. URI Scheme Syntax 200 The 'acct' URI syntax is defined here in Augmented Backus-Naur Form 201 (ABNF) [RFC5234], borrowing the 'host', 'pct-encoded', 'sub-delims', 202 'unreserved' rules from [RFC3986]: 204 acctURI = "acct" ":" userpart "@" host 205 userpart = (unreserved / sub-delims) 206 0*( unreserved / pct-encoded / sub-delims ) 208 5.4. URI Scheme Semantics 210 The 'acct' URI scheme identifies accounts hosted at service 211 providers. It is used only for identification, not interaction. A 212 protocol that employs the 'acct' URI scheme is responsible for 213 specifying how an 'acct' URI is dereferenced in the context of that 214 protocol. There is no media type associated with the 'acct' URI 215 scheme. 217 5.5. Encoding Considerations 219 As specified in [RFC3986], the 'acct' URI scheme allows any character 220 from the Unicode repertoire [UNICODE] encoded as UTF-8 [RFC3629] and 221 then percent-encoded into valid ASCII [RFC20]. Note that domain 222 labels need to be encoded as A-labels (see [RFC5890]) in order to 223 support internationalized domain names (IDNs). 225 5.6. Applications/Protocols That Use This URI Scheme Name 227 At the time of this writing, only the WebFinger protocol uses the 228 'acct' URI scheme. However, use is not restricted to the WebFinger 229 protocol, and the scheme might be considered for use in other 230 protocols, such as Simple Web Discovery. 232 5.7. Interoperability Considerations 234 There are no known interoperability concerns related to use of the 235 'acct' URI scheme. 237 5.8. Security Considerations 239 See Section 5 of RFC XXXX. [Note to RFC Editor: please replace XXXX 240 with the number issued to this document.] 242 5.9. Contact 244 Peter Saint-Andre, psaintan@cisco.com 246 5.10. Author/Change Controller 248 This scheme is registered under the IETF tree. As such, the IETF 249 maintains change control. 251 5.11. References 253 None. 255 6. Security Considerations 257 Because the 'acct' URI scheme does not directly enable interaction 258 with a user's account at a service provider, direct security concerns 259 are minimized. 261 However, an 'acct' URI does provide proof of existence of the 262 account; this implies that harvesting published 'acct' URIs could 263 prove useful to spammers and similar attackers, for example if they 264 can use an 'acct' URI to leverage more information about the account 265 (e.g., via WebFinger) or if they can interact with protocol-specific 266 URIs (such as 'mailto' URIs) whose user@host portion is the same as 267 that of the 'acct' URI. 269 In addition, protocols that make use of 'acct' URIs are responsible 270 for defining security considerations related to such usage, e.g., the 271 risks involved in dereferencing an 'acct' URI, the authentication and 272 authorization methods that could be used to control access to 273 personal data associated with a user's account at a service, and 274 methods for ensuring the confidentiality of such information. 276 The use of percent-encoding allows a wider range of characters in 277 account names, but introduces some additional risks. Implementers 278 are advised to disallow percent-encoded characters or sequences that 279 would (1) result in space, null, control, or other characters that 280 are otherwise forbidden, (2) allow unauthorized access to private 281 data, or (3) lead to other security vulnerabilities. 283 7. References 285 7.1. Normative References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 291 Resource Identifier (URI): Generic Syntax", STD 66, 292 RFC 3986, January 2005. 294 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 295 Specifications: ABNF", STD 68, RFC 5234, January 2008. 297 7.2. Informative References 299 [I-D.ietf-appsawg-webfinger] 300 Jones, P., Salgueiro, G., and J. Smarr, "WebFinger", 301 draft-ietf-appsawg-webfinger-14 (work in progress), 302 May 2013. 304 [I-D.jones-simple-web-discovery] 305 Jones, M. and Y. Goland, "Simple Web Discovery (SWD)", 306 draft-jones-simple-web-discovery-04 (work in progress), 307 November 2012. 309 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 310 October 1969. 312 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 313 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 314 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 316 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 317 10646", STD 63, RFC 3629, November 2003. 319 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 320 Registration Procedures for New URI Schemes", BCP 35, 321 RFC 4395, February 2006. 323 [RFC5890] Klensin, J., "Internationalized Domain Names for 324 Applications (IDNA): Definitions and Document Framework", 325 RFC 5890, August 2010. 327 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 329 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' 330 URI Scheme", RFC 6068, October 2010. 332 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 333 6.1", 2012, 334 . 336 Appendix A. Acknowledgements 338 The 'acct' URI scheme was originally proposed during work on the 339 WebFinger protocol; special thanks are due to Blaine Cook, Brad 340 Fitzpatrick, and Eran Hammer-Lahav for their early work on the 341 concept (which in turn was partially inspired by work on Extensible 342 Resource Indentifiers at OASIS). The scheme was first formally 343 specified in [I-D.ietf-appsawg-webfinger]; the authors of that 344 specification (Paul Jones, Gonzalo Salgueiro, and Joseph Smarr) are 345 gratefully acknowledged. Thanks are also due to Melvin Carvalho, 346 Martin Duerst, Graham Klyne, Barry Leiba, Subramanian Moonesamy, Evan 347 Prodromou, James Snell, and other participants in the IETF APPSAWG 348 for their feedback. Meral Shirazipour completed a Gen-ART review. 349 Dave Cridland completed an AppsDir review, and is gratefully 350 acknowledged for providing proposed text that was incorporated into 351 Section 3 and Section 5. IESG comments from Richard Barnes, Adrian 352 Farrel, Stephen Farrell, Barry Leiba, Pete Resnick, and Sean Turner 353 also led to improvements in the specification. 355 Author's Address 357 Peter Saint-Andre 358 Cisco Systems, Inc. 359 1899 Wynkoop Street, Suite 600 360 Denver, CO 80202 361 USA 363 Email: psaintan@cisco.com