RFC 7565

The 'acct' URI Scheme

📅 published May 2015, from ietf

The 'acct' URI Scheme 🦋

Okay bestie, this is RFC 7565 from May 2015, written by P. Saint-Andre and filed as a Standards Track document under ISSN 2070-1721. It's an official IETF Standards Track spec, so it's been through public review and approved by the IESG. The title block doesn't list anything it obsoletes or updates. 💅

Abstract 🌸

This doc defines the 'acct' Uniform Resource Identifier (URI) scheme. It's a way to point at a user's account on a service provider without caring which protocols you use to talk to that account. ✨

Status of This Memo 📜

This is an Internet Standards Track document. 🎀

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. You can find more about Internet Standards in Section 2 of RFC 5741. 🧚

Info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc7565. 💜

Copyright (c) 2015 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) as they stand on the publication date. Read these carefully, because they're the rules for what you're allowed to do with this doc. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License. 🫶

Table of Contents 🍓

1. Introduction ....................................................2
2. Terminology .....................................................2
3. Rationale .......................................................2
4. Definition ......................................................3
5. Security Considerations .........................................4
6. Internationalization Considerations .............................5
7. IANA Considerations .............................................5
8. References ......................................................6
   8.1. Normative References .......................................6
   8.2. Informative References .....................................7
Acknowledgements ...................................................8
Author's Address ...................................................8

1. Introduction ✨

Okay so, existing URI schemes that let you interact with a user's account at a service provider, or that identify stuff tied to that account, are all locked to specific services or application protocols. 🙄 Two examples are the 'mailto' scheme, which is for talking to someone's email account, and the 'http' scheme, which is for grabbing web files a user controls or poking at interfaces that show info about a user. 🌸

The problem is that there's no URI scheme that just generically identifies a user's account at a service provider without also picking a protocol for talking to it. This spec fills that gap. 💅🦋

2. Terminology 💖

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 [RFC2119]. 🎀

3. Rationale 🧚

While the WebFinger protocol [RFC7033] was being formalized, people argued a LOT about which URI scheme to use when writing a user's account as a web link [RFC5988]. 😭 Both the 'mailto' [RFC6068] and 'http' [RFC7230] schemes got proposed, but not every service provider does email or web interfaces for user accounts. For example, a microblogging or instant messaging provider might not offer email, and an enterprise might not offer HTTP interfaces with info about its employees. 💀

So the folks in that discussion realized it'd be super helpful to have a URI scheme that generically identifies a user's account at a service provider, no matter which application protocols you use to interact with it. That became the 'acct' URI scheme defined in this document. 👑

(Quick aside: a user isn't necessarily a human. It could be an automated app like a bot, a role-based alias, etc. But 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. Even though 'acct' URIs look like "user@host", the scheme is built for identification, not interaction. For more on that distinction, check Section 1.2.2 of [RFC3986]. ✨ The "Internet resource" an 'acct' URI identifies is a user's account hosted at a service provider, and that provider is usually tied to a DNS domain name. So you make a particular 'acct' URI by putting the user's account name in the "user" part and the service provider's DNS domain name in the "host" part. 🌈

Say a user named "foobar" has an account on a microblogging service "status.example.net". By convention, the string "foobar@status.example.net" designates that account. As an 'acct' URI, that's "acct:foobar@status.example.net". 🍓

Here's a very common situation: a user signs up with a service provider using an identifier, like an email address, that belongs to some other provider. For example, a user with the email address "juliet@capulet.example" might sign up on a commerce site whose domain is "shoppingsite.example". To use her email address as the localpart of the 'acct' URI, the at-sign character (U+0040) has to be percent-encoded as described in [RFC3986]. So the resulting 'acct' URI would be "acct:juliet%40capulet.example@shoppingsite.example". 💅

Nothing here assumes an entity can necessarily interact with a user's account using any particular application protocol, like email. If you want that interaction, you'd need the right URI scheme for that protocol, such as the 'mailto' scheme. 🦋 It might be true that the 'acct' URI minus the scheme name (e.g., "user@example.com" from "acct:user@example.com") can be reached by email or some other app protocol. But that's purely contingent on how the provider deploys things. 🫶

Since an 'acct' URI is only for abstract identification and not interaction, this spec doesn't give any way to dereference an 'acct' URI on its own. For example, it's a no-go to use one as the value of the 'href' attribute of an HTML anchor element, like this:

<a href='acct:bob@example.com'>find out more</a>

This document doesn't specify any behavior for an 'acct' URI used that way. 🙅‍♀️

Any protocol that uses 'acct' URIs is responsible for spelling out how the 'acct' URI gets used in that context. In particular, it needs to say how it's 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 then retrieves the metadata tied to the account that URI identifies, and hands that metadata back to the requester in an HTTP response. 🌸

If an application needs to compare two 'acct' URIs (say, for authentication and authorization), it MUST do that 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 doesn't directly let you interact with a user's account at a service provider, the direct security concerns are pretty minimal. 💖

BUT (okay, not in caps, but still big energy) an 'acct' URI does prove the account exists. That means harvesting published 'acct' URIs could be super useful to spammers and similar attackers. For example, they could use an 'acct' URI to pull more info about the account (like via WebFinger), or they could interact with protocol-specific URIs, like 'mailto' URIs, whose user@host part matches the 'acct' URI's. 😭💀

On top of that, protocols that use 'acct' URIs are responsible for defining their own security considerations. That covers things like the risks of dereferencing an 'acct' URI, the authentication and authorization methods that can control access to personal data tied to a user's account at a service, and methods for keeping that info confidential. 🛡️

Percent-encoding lets you use a wider range of characters in account names, but it brings some extra risks too. 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 [RFC3986] says, the 'acct' URI scheme lets you use any character from the Unicode repertoire [Unicode], encoded as UTF-8 [RFC3629] and then percent-encoded into valid ASCII [RFC20]. 🌏 Before you apply any percent-encoding, an application MUST make sure the following about the string that goes into the URI-construction process:

  • The userpart consists only of Unicode code points that conform to the PRECIS IdentifierClass specified in [RFC7564].
  • The host consists only of Unicode code points that conform to the rules specified in [RFC5892].
  • Internationalized domain name (IDN) labels are encoded as A-labels [RFC5890]. 🧁

7. IANA Considerations 🎀

okay bestie, so this is the part where we tell IANA how to register the acct URI scheme 📋✨ it follows the guidelines and registration procedures for new URI schemes in [RFC4395], and it gives us everything needed to get the scheme on the official list 💅

URI Scheme Name: acct 🦋

Status: permanent 💖

URI Scheme Syntax: the acct URI syntax is written in Augmented Backus-Naur Form (ABNF) [RFC5234] 🧚 and it borrows the host, pct-encoded, sub-delims, and unreserved rules from [RFC3986] 🌸

acctURI      = "acct" ":" userpart "@" host
userpart     = unreserved / sub-delims
               0*( unreserved / pct-encoded / sub-delims )

note that extra rules about the strings used to build acct URIs limit which characters can be percent-encoded, so check the Encoding Considerations AND Section 6 of this doc 🙈

URI Scheme Semantics: the acct scheme identifies accounts hosted at service providers 💜 it's used only for identification, NOT interaction ✨ any protocol that uses acct is responsible for saying how an acct URI gets dereferenced in that protocol's context 🫶 and there is no media type associated with the acct scheme 🙅

Encoding Considerations: see Section 6 of this document 🍓

Applications/Protocols That Use This URI Scheme Name: at the time of writing, only the WebFinger protocol uses acct 🎀 but use isn't restricted to WebFinger, and the scheme might be considered for other protocols too 👑

Interoperability Considerations: there are no known interoperability concerns with acct 🌈

Security Considerations: see Section 5 of this document 🔒

Contact: Peter Saint-Andre, peter@andyet.com 💌

Author/Change Controller: this scheme is registered under the IETF tree, so the IETF keeps change control 🏛️

References: None. ✨

8. References 📚

8.1. Normative References 💜

8.2. Informative References 🫧

Acknowledgements 🫶

The acct URI scheme was originally proposed during work on the WebFinger protocol 🔎 special thanks to Blaine Cook, Brad Fitzpatrick, and Eran Hammer-Lahav for their early work on the concept, which was partially inspired by work on Extensible Resource Identifiers at OASIS 🌟 The scheme was first formally specified in [RFC7033], and the authors of that spec (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 3 and 5 🎀 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: https://andyet.com/ 💖

📦 where this page comes from