The 'acct' URI Schemepeter@andyet.comhttps://andyet.com/Uniform Resource IdentifierURIThis 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.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.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 .During formalization of the WebFinger protocol , much discussion occurred regarding the appropriate
URI scheme to include when specifying a user's account as a web link
. Although both the 'mailto' and 'http' 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 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.)The syntax of the 'acct' URI scheme is defined under 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 ). 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 . 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.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: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 ). As a concrete example, an "Account Information"
application of the WebFinger protocol 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 ) about the
resource. For example: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 .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.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.As specified in , the 'acct' URI scheme
allows any character from the Unicode repertoire encoded as UTF-8 and then
percent-encoded into valid ASCII . Before
applying any percent-encoding, an application MUST ensure the following
about the string that is used as input to the URI-construction
process:The userpart consists only of Unicode code points that conform to
the PRECIS IdentifierClass specified in .The host consists only of Unicode code points that conform to the
rules specified in .Internationalized domain name (IDN) labels are encoded as
A-labels .In accordance with the guidelines and registration procedures for new
URI schemes , this section provides the
information needed to register the 'acct' URI scheme.acctpermanentThe 'acct' URI syntax is
defined here in Augmented Backus-Naur Form
(ABNF) , borrowing the 'host', 'pct-encoded',
'sub-delims', and 'unreserved' rules from :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.See
of this document.
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.There are no known
interoperability concerns related to use of the 'acct' URI scheme.See of
this document.Peter Saint-Andre, peter@andyet.comThis scheme is registered
under the IETF tree. As such, the IETF maintains change control.None.Key words for use in RFCs to Indicate Requirement LevelsUTF-8, a transformation format of ISO 10646Uniform Resource Identifier (URI): Generic SyntaxAugmented BNF for Syntax Specifications: ABNFInternationalized Domain Names for Applications (IDNA): Definitions and Document FrameworkThe Unicode Code Points and Internationalized Domain Names for Applications (IDNA)PRECIS Framework: Preparation, Enforcement, and Comparison of
Internationalized Strings in Application ProtocolsThe Unicode StandardThe Unicode ConsortiumASCII format for network interchangeHypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingGuidelines and Registration Procedures for New URI SchemesWeb LinkingThe 'mailto' URI SchemeWebFingerThe '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
; 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 and
. IESG comments from
Richard Barnes, Adrian Farrel, Stephen Farrell, Barry Leiba,
Pete Resnick, and Sean Turner also led to improvements in the
specification.