1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
|
<pre>Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7565 May 2015
Category: Standards Track
ISSN: 2070-1721
<span class="h1">The 'acct' URI Scheme</span>
Abstract
This document defines the 'acct' Uniform Resource Identifier (URI)
scheme as a way to identify a user's account at a service provider,
irrespective of the particular protocols that can be used to interact
with the account.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7565">http://www.rfc-editor.org/info/rfc7565</a>.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Saint-Andre Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7565">RFC 7565</a> The 'acct' URI Scheme May 2015</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology .....................................................<a href="#page-2">2</a>
<a href="#section-3">3</a>. Rationale .......................................................<a href="#page-2">2</a>
<a href="#section-4">4</a>. Definition ......................................................<a href="#page-3">3</a>
<a href="#section-5">5</a>. Security Considerations .........................................<a href="#page-4">4</a>
<a href="#section-6">6</a>. Internationalization Considerations .............................<a href="#page-5">5</a>
<a href="#section-7">7</a>. IANA Considerations .............................................<a href="#page-5">5</a>
<a href="#section-8">8</a>. References ......................................................<a href="#page-6">6</a>
<a href="#section-8.1">8.1</a>. Normative References .......................................<a href="#page-6">6</a>
<a href="#section-8.2">8.2</a>. Informative References .....................................<a href="#page-7">7</a>
Acknowledgements ...................................................<a href="#page-8">8</a>
Author's Address ...................................................<a href="#page-8">8</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Existing Uniform Resource Identifier (URI) schemes that enable
interaction with, or that identify resources associated with, a
user's account at a service provider are tied to particular services
or application protocols. Two examples are the 'mailto' scheme
(which enables interaction with a user's email account) and the
'http' scheme (which enables retrieval of web files controlled by a
user or interaction with interfaces providing information about a
user). However, there exists no URI scheme that generically
identifies a user's account at a service provider without specifying
a particular protocol to use when interacting with the account. This
specification fills that gap.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Rationale</span>
During formalization of the WebFinger protocol [<a href="./rfc7033" title=""WebFinger"">RFC7033</a>], much
discussion occurred regarding the appropriate URI scheme to include
when specifying a user's account as a web link [<a href="./rfc5988" title=""Web Linking"">RFC5988</a>]. Although
both the 'mailto' [<a href="./rfc6068" title=""The 'mailto' URI Scheme"">RFC6068</a>] and 'http' [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>] schemes were
proposed, not all service providers offer email services or web
interfaces on behalf of user accounts (e.g., a microblogging or
instant messaging provider might not offer email services, or an
enterprise might not offer HTTP interfaces to information about its
employees). Therefore, the participants in the discussion recognized
that it would be helpful to define a URI scheme that could be used to
<span class="grey">Saint-Andre Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7565">RFC 7565</a> The 'acct' URI Scheme May 2015</span>
generically identify a user's account at a service provider,
irrespective of the particular application protocols used to interact
with the account. The result was the 'acct' URI scheme defined in
this document.
(Note that a user is not necessarily a human; it could be an
automated application such as a bot, a role-based alias, etc.
However, an 'acct' URI is always used to identify something that has
an account at a service, not the service itself.)
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Definition</span>
The syntax of the 'acct' URI scheme is defined under <a href="#section-7">Section 7</a> of
this document. Although 'acct' URIs take the form "user@host", the
scheme is designed for the purpose of identification instead of
interaction (regarding this distinction, see <a href="./rfc3986#section-1.2.2">Section 1.2.2 of
[RFC3986]</a>). The "Internet resource" identified by an 'acct' URI is a
user's account hosted at a service provider, where the service
provider is typically associated with a DNS domain name. Thus, a
particular 'acct' URI is formed by setting the "user" portion to the
user's account name at the service provider and by setting the "host"
portion to the DNS domain name of the service provider.
Consider the case of a user with an account name of "foobar" on a
microblogging service "status.example.net". It is taken as
convention that the string "foobar@status.example.net" designates
that account. This is expressed as a URI using the 'acct' scheme as
"acct:foobar@status.example.net".
A common scenario is for a user to register with a service provider
using an identifier (such as an email address) that is associated
with some other service provider. For example, a user with the email
address "juliet@capulet.example" might register with a commerce
website whose domain name is "shoppingsite.example". In order to use
her email address as the localpart of the 'acct' URI, the at-sign
character (U+0040) needs to be percent-encoded as described in
[<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>]. Thus, the resulting 'acct' URI would be
"acct:juliet%40capulet.example@shoppingsite.example".
It is not assumed that an entity will necessarily be able to interact
with a user's account using any particular application protocol, such
as email; to enable such interaction, an entity would need to use the
appropriate URI scheme for such a protocol, such as the 'mailto'
scheme. While it might be true that the 'acct' URI minus the scheme
name (e.g., "user@example.com" derived from "acct:user@example.com")
can be reached via email or some other application protocol, that
fact would be purely contingent and dependent upon the deployment
practices of the provider.
<span class="grey">Saint-Andre Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7565">RFC 7565</a> The 'acct' URI Scheme May 2015</span>
Because an 'acct' URI enables abstract identification only and not
interaction, this specification provides no method for dereferencing
an 'acct' URI on its own, e.g., as the value of the 'href' attribute
of an HTML anchor element. For example, there is no behavior
specified in this document for an 'acct' URI used as follows:
<a href='acct:bob@example.com'>find out more</a>
Any protocol that uses 'acct' URIs is responsible for specifying how
an 'acct' URI is employed in the context of that protocol (in
particular, how it is dereferenced or resolved; see [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>]). As a
concrete example, an "Account Information" application of the
WebFinger protocol [<a href="./rfc7033" title=""WebFinger"">RFC7033</a>] might take an 'acct' URI, resolve the
host portion to find a WebFinger server, and then pass the 'acct' URI
as a parameter in a WebFinger HTTP request for metadata (i.e., web
links [<a href="./rfc5988" title=""Web Linking"">RFC5988</a>]) about the resource. For example:
GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1
The service retrieves the metadata associated with the account
identified by that URI and then provides that metadata to the
requesting entity in an HTTP response.
If an application needs to compare two 'acct' URIs (e.g., for
purposes of authentication and authorization), it MUST do so using
case normalization and percent-encoding normalization as specified in
Sections <a href="#section-6.2.2.1">6.2.2.1</a> and <a href="#section-6.2.2.2">6.2.2.2</a> of [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
Because the 'acct' URI scheme does not directly enable interaction
with a user's account at a service provider, direct security concerns
are minimized.
However, an 'acct' URI does provide proof of existence of the
account; this implies that harvesting published 'acct' URIs could
prove useful to spammers and similar attackers -- for example, if
they can use an 'acct' URI to leverage more information about the
account (e.g., via WebFinger) or if they can interact with protocol-
specific URIs (such as 'mailto' URIs) whose user@host portion is the
same as that of the 'acct' URI.
In addition, protocols that make use of 'acct' URIs are responsible
for defining security considerations related to such usage, e.g., the
risks involved in dereferencing an 'acct' URI, the authentication and
authorization methods that could be used to control access to
personal data associated with a user's account at a service, and
methods for ensuring the confidentiality of such information.
<span class="grey">Saint-Andre Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7565">RFC 7565</a> The 'acct' URI Scheme May 2015</span>
The use of percent-encoding allows a wider range of characters in
account names but introduces some additional risks. Implementers are
advised to disallow percent-encoded characters or sequences that
would (1) result in space, null, control, or other characters that
are otherwise forbidden, (2) allow unauthorized access to private
data, or (3) lead to other security vulnerabilities.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Internationalization Considerations</span>
As specified in [<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>], the 'acct' URI scheme allows any character
from the Unicode repertoire [<a href="#ref-Unicode" title=""The Unicode Standard"">Unicode</a>] encoded as UTF-8 [<a href="./rfc3629" title=""UTF-8, a transformation format of ISO 10646"">RFC3629</a>] and
then percent-encoded into valid ASCII [<a href="./rfc20" title=""ASCII format for network interchange"">RFC20</a>]. Before applying any
percent-encoding, an application MUST ensure the following about the
string that is used as input to the URI-construction process:
o The userpart consists only of Unicode code points that conform to
the PRECIS IdentifierClass specified in [<a href="./rfc7564" title=""PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols"">RFC7564</a>].
o The host consists only of Unicode code points that conform to the
rules specified in [<a href="./rfc5892" title=""The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)"">RFC5892</a>].
o Internationalized domain name (IDN) labels are encoded as A-labels
[<a href="./rfc5890" title=""Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"">RFC5890</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
In accordance with the guidelines and registration procedures for new
URI schemes [<a href="./rfc4395" title=""Guidelines and Registration Procedures for New URI Schemes"">RFC4395</a>], this section provides the information needed
to register the 'acct' URI scheme.
URI Scheme Name: acct
Status: permanent
URI Scheme Syntax: The 'acct' URI syntax is defined here in
Augmented Backus-Naur Form (ABNF) [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>], borrowing the 'host',
'pct-encoded', 'sub-delims', and 'unreserved' rules from
[<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>]:
acctURI = "acct" ":" userpart "@" host
userpart = unreserved / sub-delims
0*( unreserved / pct-encoded / sub-delims )
Note that additional rules regarding the strings that are used as
input to construction of 'acct' URIs further limit the characters
that can be percent-encoded; see the Encoding Considerations as
well as <a href="#section-6">Section 6</a> of this document.
<span class="grey">Saint-Andre Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7565">RFC 7565</a> The 'acct' URI Scheme May 2015</span>
URI Scheme Semantics: The 'acct' URI scheme identifies accounts
hosted at service providers. It is used only for identification,
not interaction. A protocol that employs the 'acct' URI scheme is
responsible for specifying how an 'acct' URI is dereferenced in
the context of that protocol. There is no media type associated
with the 'acct' URI scheme.
Encoding Considerations: See <a href="#section-6">Section 6</a> of this document.
Applications/Protocols That Use This URI Scheme Name: At the time of
this writing, only the WebFinger protocol uses the 'acct' URI
scheme. However, use is not restricted to the WebFinger protocol,
and the scheme might be considered for use in other protocols.
Interoperability Considerations: There are no known interoperability
concerns related to use of the 'acct' URI scheme.
Security Considerations: See <a href="#section-5">Section 5</a> of this document.
Contact: Peter Saint-Andre, peter@andyet.com
Author/Change Controller: This scheme is registered under the IETF
tree. As such, the IETF maintains change control.
References: None.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3629">RFC3629</a>] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, <a href="./rfc3629">RFC 3629</a>, DOI 10.17487/RFC3629,
November 2003, <<a href="http://www.rfc-editor.org/info/rfc3629">http://www.rfc-editor.org/info/rfc3629</a>>.
[<a id="ref-RFC3986">RFC3986</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
<a href="./rfc3986">RFC 3986</a>, DOI 10.17487/RFC3986, January 2005,
<<a href="http://www.rfc-editor.org/info/rfc3986">http://www.rfc-editor.org/info/rfc3986</a>>.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>,
DOI 10.17487/RFC5234, January 2008,
<<a href="http://www.rfc-editor.org/info/rfc5234">http://www.rfc-editor.org/info/rfc5234</a>>.
<span class="grey">Saint-Andre Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7565">RFC 7565</a> The 'acct' URI Scheme May 2015</span>
[<a id="ref-RFC5890">RFC5890</a>] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
<a href="./rfc5890">RFC 5890</a>, DOI 10.17487/RFC5890, August 2010,
<<a href="http://www.rfc-editor.org/info/rfc5890">http://www.rfc-editor.org/info/rfc5890</a>>.
[<a id="ref-RFC5892">RFC5892</a>] Faltstrom, P., Ed., "The Unicode Code Points and
Internationalized Domain Names for Applications (IDNA)",
<a href="./rfc5892">RFC 5892</a>, DOI 10.17487/RFC5892, August 2010,
<<a href="http://www.rfc-editor.org/info/rfc5892">http://www.rfc-editor.org/info/rfc5892</a>>.
[<a id="ref-RFC7564">RFC7564</a>] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols",
<a href="./rfc7564">RFC 7564</a>, DOI 10.17487/RFC7564, May 2015,
<<a href="http://www.rfc-editor.org/info/rfc7564">http://www.rfc-editor.org/info/rfc7564</a>>.
[<a id="ref-Unicode">Unicode</a>] The Unicode Consortium, "The Unicode Standard",
<<a href="http://www.unicode.org/versions/latest/">http://www.unicode.org/versions/latest/</a>>.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-RFC20">RFC20</a>] Cerf, V., "ASCII format for network interchange", STD 80,
<a href="./rfc20">RFC 20</a>, DOI 10.17487/RFC0020, October 1969,
<<a href="http://www.rfc-editor.org/info/rfc20">http://www.rfc-editor.org/info/rfc20</a>>.
[<a id="ref-RFC4395">RFC4395</a>] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", <a href="https://www.rfc-editor.org/bcp/bcp35">BCP 35</a>,
<a href="./rfc4395">RFC 4395</a>, DOI 10.17487/RFC4395, February 2006,
<<a href="http://www.rfc-editor.org/info/rfc4395">http://www.rfc-editor.org/info/rfc4395</a>>.
[<a id="ref-RFC5988">RFC5988</a>] Nottingham, M., "Web Linking", <a href="./rfc5988">RFC 5988</a>,
DOI 10.17487/RFC5988, October 2010,
<<a href="http://www.rfc-editor.org/info/rfc5988">http://www.rfc-editor.org/info/rfc5988</a>>.
[<a id="ref-RFC6068">RFC6068</a>] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
URI Scheme", <a href="./rfc6068">RFC 6068</a>, DOI 10.17487/RFC6068, October 2010,
<<a href="http://www.rfc-editor.org/info/rfc6068">http://www.rfc-editor.org/info/rfc6068</a>>.
[<a id="ref-RFC7033">RFC7033</a>] Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
"WebFinger", <a href="./rfc7033">RFC 7033</a>, DOI 10.17487/RFC7033,
September 2013, <<a href="http://www.rfc-editor.org/info/rfc7033">http://www.rfc-editor.org/info/rfc7033</a>>.
[<a id="ref-RFC7230">RFC7230</a>] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
<a href="./rfc7230">RFC 7230</a>, DOI 10.17487/RFC7230, June 2014,
<<a href="http://www.rfc-editor.org/info/rfc7230">http://www.rfc-editor.org/info/rfc7230</a>>.
<span class="grey">Saint-Andre Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7565">RFC 7565</a> The 'acct' URI Scheme May 2015</span>
Acknowledgements
The 'acct' URI scheme was originally proposed during work on the
WebFinger protocol; special thanks are due to Blaine Cook, Brad
Fitzpatrick, and Eran Hammer-Lahav for their early work on the
concept (which in turn was partially inspired by work on Extensible
Resource Identifiers at OASIS). The scheme was first formally
specified in [<a href="./rfc7033" title=""WebFinger"">RFC7033</a>]; the authors of that specification (Paul
Jones, Gonzalo Salgueiro, and Joseph Smarr) are gratefully
acknowledged. Thanks are also due to Stephane Bortzmeyer, Melvin
Carvalho, Martin Duerst, Graham Klyne, Barry Leiba, Subramanian
Moonesamy, Evan Prodromou, James Snell, and various participants in
the IETF APPSAWG for their feedback. Meral Shirazipour completed a
Gen-ART review. Dave Cridland completed an AppsDir review and is
gratefully acknowledged for providing proposed text that was
incorporated into Sections <a href="#section-3">3</a> and <a href="#section-5">5</a>. IESG comments from Richard
Barnes, Adrian Farrel, Stephen Farrell, Barry Leiba, Pete Resnick,
and Sean Turner also led to improvements in the specification.
Author's Address
Peter Saint-Andre
EMail: peter@andyet.com
URI: <a href="https://andyet.com/">https://andyet.com/</a>
Saint-Andre Standards Track [Page 8]
</pre>
|
