idnits 2.17.1
draft-ietf-appsawg-acct-uri-06.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 (July 2, 2013) is 3944 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 (-23) exists of
draft-ietf-precis-framework-08
-- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE'
== 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 (~~), 3 warnings (==), 5 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 July 2, 2013
5 Expires: January 3, 2014
7 The 'acct' URI Scheme
8 draft-ietf-appsawg-acct-uri-06
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 January 3, 2014.
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. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
56 6. Internationalization Considerations . . . . . . . . . . . . . . 6
57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
59 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
60 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 9
62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
64 1. Introduction
66 Existing Uniform Resource Identifier (URI) schemes that enable
67 interaction with, or that identify resources associated with, a
68 user's account at a service provider are tied to particular services
69 or application protocols. Two examples are the 'mailto' scheme
70 (which enables interaction with a user's email account) and the
71 'http' scheme (which enables retrieval of web files controlled by a
72 user or interaction with interfaces providing information about a
73 user). However, there exists no URI scheme that generically
74 identifies a user's account at a service provider without specifying
75 a particular protocol to use when interacting with the account. This
76 specification fills that gap.
78 2. Terminology
80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
82 "OPTIONAL" in this document are to be interpreted as described in
83 [RFC2119].
85 3. Rationale
87 During formalization of the WebFinger protocol
88 [I-D.ietf-appsawg-webfinger], much discussion occurred regarding the
89 appropriate URI scheme to include when specifying a user's account as
90 a web link [RFC5988]. Although both the 'mailto' [RFC6068] and
91 'http' [RFC2616] schemes were proposed, not all service providers
92 offer email services or web interfaces on behalf of user accounts
93 (e.g., a microblogging or instant messaging provider might not offer
94 email services, or an enterprise might not offer HTTP interfaces to
95 information about its employees). Therefore, the participants in the
96 discussion recognized that it would be helpful to define a URI scheme
97 that could be used to generically identify a user's account at a
98 service provider, irrespective of the particular application
99 protocols used to interact with the account. The result was the
100 'acct' URI scheme defined in this document.
102 (Note that a user is not necessarily a human; it could be an
103 automated application such as a bot, a role-based alias, etc.
104 However, an 'acct' URI is always used to identify something that has
105 an account at a service, not the service itself.)
107 4. Definition
109 The syntax of the 'acct' URI scheme is defined under Section 7 of
110 this document. Although 'acct' URIs take the form "user@host", the
111 scheme is designed for the purpose of identification instead of
112 interaction (regarding this distinction, see Section 1.2.2 of
113 [RFC3986]). The "Internet resource" identified by an 'acct' URI is a
114 user's account hosted at a service provider, where the service
115 provider is typically associated with a DNS domain name. Thus a
116 particular 'acct' URI is formed by setting the "user" portion to the
117 user's account name at the service provider and by setting the "host"
118 portion to the DNS domain name of the service provider.
120 Consider the case of a user with an account name of "foobar" on a
121 microblogging service "status.example.net". It is taken as
122 convention that the string "foobar@status.example.net" designates
123 that account. This is expressed as a URI using the 'acct' scheme as
124 "acct:foobar@status.example.net".
126 A common scenario is for a user to register with a service provider
127 using an identifier (such as an email address) that is associated
128 with some other service provider. For example, a user with the email
129 address "juliet@capulet.example" might register with a commerce
130 website whose domain name is "shoppingsite.example". In order to use
131 her email address as the localpart of the 'acct' URI, the at-sign
132 character (U+0040) needs to be percent-encoded as described in
133 [RFC3986]. Thus the resulting 'acct' URI would be
134 "juliet%40capulet.example@shoppingsite.example.com".
136 It is not assumed that an entity will necessarily be able to interact
137 with a user's account using any particular application protocol, such
138 as email; to enable such interaction, an entity would need to use the
139 appropriate URI scheme for such a protocol, such as the 'mailto'
140 scheme. While it might be true that the 'acct' URI minus the scheme
141 name (e.g., "user@example.com" derived from "acct:user@example.com")
142 can be reached via email or some other application protocol, that
143 fact would be purely contingent and dependent upon the deployment
144 practices of the provider.
146 Because an 'acct' URI enables abstract identification only and not
147 interaction, this specification provides no method for dereferencing
148 an 'acct' URI on its own, e.g., as the value of the 'href' attribute
149 of an HTML anchor element. For example, there is no behavior
150 specified in this document for an 'acct' URI used as follows:
152 find out more
154 Any protocol that uses 'acct' URIs is responsible for specifying how
155 an 'acct' URI is employed in the context of that protocol (in
156 particular, how it is dereferenced or resolved; see [RFC3986]). As a
157 concrete example, an "Account Information" application of the
158 WebFinger protocol [I-D.ietf-appsawg-webfinger] might take an 'acct'
159 URI, resolve the host portion to find a WebFinger server, and then
160 pass the 'acct' URI as a parameter in a WebFinger HTTP request for
161 metadata (i.e., web links [RFC5988]) about the resource. For
162 example:
164 GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1
166 The service retrieves the metadata associated with the account
167 identified by that URI and then provides that metadata to the
168 requesting entity in an HTTP response.
170 If an application needs to compare two 'acct' URIs (e.g., for
171 purposes of authentication and authorization), it MUST do so using
172 case normalization and percent-encoding normalization as specified in
173 Sections 6.2.2.1 and 6.2.2.2 of [RFC3986].
175 5. Security Considerations
177 Because the 'acct' URI scheme does not directly enable interaction
178 with a user's account at a service provider, direct security concerns
179 are minimized.
181 However, an 'acct' URI does provide proof of existence of the
182 account; this implies that harvesting published 'acct' URIs could
183 prove useful to spammers and similar attackers, for example if they
184 can use an 'acct' URI to leverage more information about the account
185 (e.g., via WebFinger) or if they can interact with protocol-specific
186 URIs (such as 'mailto' URIs) whose user@host portion is the same as
187 that of the 'acct' URI.
189 In addition, protocols that make use of 'acct' URIs are responsible
190 for defining security considerations related to such usage, e.g., the
191 risks involved in dereferencing an 'acct' URI, the authentication and
192 authorization methods that could be used to control access to
193 personal data associated with a user's account at a service, and
194 methods for ensuring the confidentiality of such information.
196 The use of percent-encoding allows a wider range of characters in
197 account names, but introduces some additional risks. Implementers
198 are advised to disallow percent-encoded characters or sequences that
199 would (1) result in space, null, control, or other characters that
200 are otherwise forbidden, (2) allow unauthorized access to private
201 data, or (3) lead to other security vulnerabilities.
203 6. Internationalization Considerations
205 As specified in [RFC3986], the 'acct' URI scheme allows any character
206 from the Unicode repertoire [UNICODE] encoded as UTF-8 [RFC3629] and
207 then percent-encoded into valid ASCII [RFC20]. Before applying any
208 percent-encoding, an application MUST ensure the following about the
209 string that is used as input to the URI-construction process:
211 o The userpart consists only of Unicode code points that conform to
212 the PRECIS IdentifierClass specified in
213 [I-D.ietf-precis-framework].
214 o The host consists only of Unicode code points that conform to the
215 rules specified in [RFC5892].
216 o Internationalized domain name (IDN) labels are encoded as A-labels
217 [RFC5890].
219 7. IANA Considerations
221 In accordance with the guidelines and registration procedures for new
222 URI schemes [RFC4395], this section provides the information needed
223 to register the 'acct' URI scheme.
225 7.1. URI Scheme Name
227 acct
229 7.2. Status
231 permanent
233 7.3. URI Scheme Syntax
235 The 'acct' URI syntax is defined here in Augmented Backus-Naur Form
236 (ABNF) [RFC5234], borrowing the 'host', 'pct-encoded', 'sub-delims',
237 'unreserved' rules from [RFC3986]:
239 acctURI = "acct" ":" userpart "@" host
240 userpart = unreserved / sub-delims
241 0*( unreserved / pct-encoded / sub-delims )
243 Note that additional rules regarding the strings that are used as
244 input to construction of 'acct' URIs further limit the characters
245 that can be percent-encoded; see the Encoding Considerations as well
246 as Section 6 of RFC XXXX. [Note to RFC Editor: please replace XXXX
247 with the number issued to this document.]
249 7.4. URI Scheme Semantics
251 The 'acct' URI scheme identifies accounts hosted at service
252 providers. It is used only for identification, not interaction. A
253 protocol that employs the 'acct' URI scheme is responsible for
254 specifying how an 'acct' URI is dereferenced in the context of that
255 protocol. There is no media type associated with the 'acct' URI
256 scheme.
258 7.5. Encoding Considerations
260 See Section 6 of RFC XXXX. [Note to RFC Editor: please replace XXXX
261 with the number issued to this document.]
263 7.6. Applications/Protocols That Use This URI Scheme Name
265 At the time of this writing, only the WebFinger protocol uses the
266 'acct' URI scheme. However, use is not restricted to the WebFinger
267 protocol, and the scheme might be considered for use in other
268 protocols.
270 7.7. Interoperability Considerations
272 There are no known interoperability concerns related to use of the
273 'acct' URI scheme.
275 7.8. Security Considerations
277 See Section 5 of RFC XXXX. [Note to RFC Editor: please replace XXXX
278 with the number issued to this document.]
280 7.9. Contact
282 Peter Saint-Andre, psaintan@cisco.com
284 7.10. Author/Change Controller
286 This scheme is registered under the IETF tree. As such, the IETF
287 maintains change control.
289 7.11. References
291 None.
293 8. References
294 8.1. Normative References
296 [I-D.ietf-precis-framework]
297 Saint-Andre, P. and M. Blanchet, "Precis Framework:
298 Handling Internationalized Strings in Protocols",
299 draft-ietf-precis-framework-08 (work in progress),
300 March 2013.
302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
303 Requirement Levels", BCP 14, RFC 2119, March 1997.
305 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
306 10646", STD 63, RFC 3629, November 2003.
308 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
309 Resource Identifier (URI): Generic Syntax", STD 66,
310 RFC 3986, January 2005.
312 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
313 Specifications: ABNF", STD 68, RFC 5234, January 2008.
315 [RFC5890] Klensin, J., "Internationalized Domain Names for
316 Applications (IDNA): Definitions and Document Framework",
317 RFC 5890, August 2010.
319 [RFC5892] Faltstrom, P., "The Unicode Code Points and
320 Internationalized Domain Names for Applications (IDNA)",
321 RFC 5892, August 2010.
323 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
324 6.1", 2012,
325 .
327 8.2. Informative References
329 [I-D.ietf-appsawg-webfinger]
330 Jones, P., Salgueiro, G., and J. Smarr, "WebFinger",
331 draft-ietf-appsawg-webfinger-14 (work in progress),
332 May 2013.
334 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
335 October 1969.
337 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
338 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
339 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
341 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
342 Registration Procedures for New URI Schemes", BCP 35,
343 RFC 4395, February 2006.
345 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
347 [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
348 URI Scheme", RFC 6068, October 2010.
350 Appendix A. Acknowledgements
352 The 'acct' URI scheme was originally proposed during work on the
353 WebFinger protocol; special thanks are due to Blaine Cook, Brad
354 Fitzpatrick, and Eran Hammer-Lahav for their early work on the
355 concept (which in turn was partially inspired by work on Extensible
356 Resource Indentifiers at OASIS). The scheme was first formally
357 specified in [I-D.ietf-appsawg-webfinger]; the authors of that
358 specification (Paul Jones, Gonzalo Salgueiro, and Joseph Smarr) are
359 gratefully acknowledged. Thanks are also due to Melvin Carvalho,
360 Martin Duerst, Graham Klyne, Barry Leiba, Subramanian Moonesamy, Evan
361 Prodromou, James Snell, and other participants in the IETF APPSAWG
362 for their feedback. Meral Shirazipour completed a Gen-ART review.
363 Dave Cridland completed an AppsDir review, and is gratefully
364 acknowledged for providing proposed text that was incorporated into
365 Section 3 and Section 5. IESG comments from Richard Barnes, Adrian
366 Farrel, Stephen Farrell, Barry Leiba, Pete Resnick, and Sean Turner
367 also led to improvements in the specification.
369 Author's Address
371 Peter Saint-Andre
372 Cisco Systems, Inc.
373 1899 Wynkoop Street, Suite 600
374 Denver, CO 80202
375 USA
377 Email: psaintan@cisco.com