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