Network Working Group P. Saint-Andre
Internet-Draft
Intended status: Standards Track January 23, 2014
Expires: July 27, 2014
The 'acct' URI Schemedraft-ietf-appsawg-acct-uri-07
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 27, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) 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.
Saint-Andre Expires July 27, 2014 [Page 1]

Internet-Draft The 'acct' URI Scheme January 2014
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.)
4. Definition
The syntax of the 'acct' URI scheme is defined under Section 7 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 Section 1.2.2 of
[RFC3986]). 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
[RFC3986]. 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.
Saint-Andre Expires July 27, 2014 [Page 3]

Internet-Draft The 'acct' URI Scheme January 2014
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 [RFC3986]). As a
concrete example, an "Account Information" application of the
WebFinger protocol [RFC7033] 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 [RFC5988]) 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 6.2.2.1 and 6.2.2.2 of [RFC3986].
5. Security Considerations
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
Saint-Andre Expires July 27, 2014 [Page 4]

Internet-Draft The 'acct' URI Scheme January 2014
personal data associated with a user's account at a service, and
methods for ensuring the confidentiality of such information.
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.
6. Internationalization Considerations
As specified in [RFC3986], the 'acct' URI scheme allows any character
from the Unicode repertoire [UNICODE] encoded as UTF-8 [RFC3629] and
then percent-encoded into valid ASCII [RFC20]. 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
[I-D.ietf-precis-framework].
o The host consists only of Unicode code points that conform to the
rules specified in [RFC5892].
o Internationalized domain name (IDN) labels are encoded as A-labels
[RFC5890].
7. IANA Considerations
In accordance with the guidelines and registration procedures for new
URI schemes [RFC4395], this section provides the information needed
to register the 'acct' URI scheme.
7.1. URI Scheme Name
acct
7.2. Status
permanent
7.3. URI Scheme Syntax
The 'acct' URI syntax is defined here in Augmented Backus-Naur Form
(ABNF) [RFC5234], borrowing the 'host', 'pct-encoded', 'sub-delims',
'unreserved' rules from [RFC3986]:
Saint-Andre Expires July 27, 2014 [Page 5]

Internet-Draft The 'acct' URI Scheme January 2014
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 Section 6 of RFC XXXX. [Note to RFC Editor: please replace XXXX
with the number issued to this document.]
7.4. 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.
7.5. Encoding Considerations
See Section 6 of RFC XXXX. [Note to RFC Editor: please replace XXXX
with the number issued to this document.]
7.6. 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.
7.7. Interoperability Considerations
There are no known interoperability concerns related to use of the
'acct' URI scheme.
7.8. Security Considerations
See Section 5 of RFC XXXX. [Note to RFC Editor: please replace XXXX
with the number issued to this document.]
7.9. Contact
Peter Saint-Andre, psaintan@cisco.com
7.10. Author/Change ControllerSaint-Andre Expires July 27, 2014 [Page 6]