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