The 'acct' URI Scheme
Extracted elements (14)
A user is not necessarily a human; it could be an automated application such as a bot or a role-based alias. However, an 'acct' URI always identifies something that has an account at a service, not the service itself.
An 'acct' URI enables abstract identification only and not interaction; therefore, this specification provides no method for dereferencing an 'acct' URI on its own. Any protocol that uses 'acct' URIs is responsible for specifying how the URI is employed, dereferenced, or resolved in that protocol's context.
The 'acct' URI scheme was created to generically identify a user's account at a service provider without specifying a particular application protocol. Existing schemes like 'mailto' and 'http' are tied to specific services, and not all providers offer email or web interfaces, so a protocol-agnostic identifier was needed.
The 'acct' URI minus the scheme name (e.g., '[email protected]') may superficially resemble an email address reachable via 'mailto', but any such reachability is purely contingent on the deployment practices of the provider and should not be assumed.
When a user's account name includes an at-sign character (U+0040), it must be percent-encoded as '%40' to avoid ambiguity with the '@' delimiter separating the userpart from the host. For example, '[email protected]' registered at 'shoppingsite.example' becomes 'acct:juliet%[email protected]'.
Before applying any percent-encoding, an application MUST ensure that the userpart consists only of Unicode code points conforming to the PRECIS IdentifierClass (RFC 7564), and the host consists only of Unicode code points conforming to RFC 5892.
If an application needs to compare two 'acct' URIs (e.g., for 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 RFC 3986.
Internationalized domain name (IDN) labels in the host portion of an 'acct' URI MUST be encoded as A-labels as specified in RFC 5890.
An 'acct' URI takes the form 'acct:userpart@host', where 'userpart' is the user's account name at the service provider and 'host' is the DNS domain name of the service provider. The scheme is intended for identification only, not interaction.
This document registers the 'acct' URI scheme in the IANA URI Schemes registry as a permanent scheme. The scheme identifies user accounts hosted at service providers and is used for identification only, not interaction.
An 'acct' URI provides proof of existence of the account, so harvesting published 'acct' URIs could be useful to spammers and attackers who may leverage the URI to obtain more information (e.g., via WebFinger) or interact with protocol-specific URIs whose user@host matches the 'acct' URI.
Protocols that make use of 'acct' URIs are responsible for defining their own security considerations, including risks in dereferencing, authentication and authorization methods for controlling access to personal data, and confidentiality of account-associated information.
The use of percent-encoding introduces risks; implementers are advised to disallow percent-encoded characters or sequences that would result in space, null, control, or otherwise forbidden characters, allow unauthorized access to private data, or lead to other security vulnerabilities.
The 'acct' URI ABNF is: acctURI = "acct" ":" userpart "@" host; userpart = unreserved / sub-delims 0*( unreserved / pct-encoded / sub-delims ). The 'host', 'pct-encoded', 'sub-delims', and 'unreserved' rules are borrowed from RFC 3986.