Bearer URIs

1.1. Rationale

The research on access control has shown that between the two major paradigms of access control, access control lists (ACLs) are less expressive and usually open the possibility of confused deputy attacks, which include some the most problematic attack surfaces of the Web, like XSS and CSRF (cf. ACLs Don't). The ambient authority inherent to ACLs is also often critical in enabling privilege escalation, making one security flaw vastly more damaging.¶

The other paradigm, capability-based security, combines designation and permission, making it possible to prevent confused deputy attacks and create new patterns of access control, including composable security policies and safe delegation mechanisms. (cf. Capability Myths Demolished)¶

HTTP/S URIs could be used as capabilities, but as HTTP/S URIs are not treated as sensitive data by most systems, except for their authorization part (but the classical format login:password has been deprecated since, cf. [RFC3986], section 3.2.1), it opens up the possibility that capabilities would get leaked in various problematic places, including being stored in server logs and shown in browser address bars.¶

This specification describes URI schemes that make it possible to safely encode capabilities as URIs by combining an existing URI and a bearer token into a URI, called bearer-URI.¶

1.2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [BCP14].¶

1.3. Syntax Notation

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].¶

2.1. Principle of operation

When a bearer-URI-aware HTTP agent (like a browser or library) is asked to make an HTTP request to a resource identified by a bearer-http URI (with parameters like the method or the request body), it extracts from that bearer-URI the bearer token and the HTTP URI, and prepare the HTTP request with the given parameters but put the bearer token in the Authorization header with the Bearer authorization scheme: ([RFC6750]):¶

http.post("bearer-http://AViRTF9ppWiAtdnpVtVHDQ@example.com/foo", body="bar",
  headers={"Content-Type": "text/plain"})

would produce the following HTTP request:¶

POST /foo HTTP/1.1
Host: example.com
Content-Type: text/plain
Authorization: Bearer AViRTF9ppWiAtdnpVtVHDQ

bar

The URI embedded in an absolute bearer-URI is the same URI with only two transformations:¶

• removal of the authority¶

• replacement of the scheme¶

As far as the bearer-URI-aware agent is concerned, the URI of the designated resource MUST NOT be the embedded HTTP URI, but the bearer-URI (the retrieval URI is one source for a base URI).¶

2.2. Relative URI references

The normal algorithm from [RFC3986] (section 5.2) applies to relative references, which means that except for network-path references with a userinfo component, relative references reuse the same bearer token used to retrieve the resource representation where they appear.¶

For that reason, the bearer schemes include a dedicated syntax to use a relative path with a different token: bearer-https:NVW9YpUuEkZ367AyA-3MZw@./bar. Note that when such a relative bearer-URI is parsed by a generic URI parser, the whole content after the scheme will match the path-rootless rule of [RFC3986] (and the token won't be parsed by the authority rule).¶

To make a relative reference with an absolute path, a network-path reference can be used: //D-nX3h-tDq_VtaYQKYYlDw@/baz. If there could be ambiguity whether the base URI is a bearer-URI, it is valid for bearer-URIs to have an empty host, which creates a URI that is equivalent to a network-path reference, but with the scheme specified: bearer-https://D-nX3h-tDq_VtaYQKYYlDw@/baz.¶

2.3. Definitions

The four URI schemes are specified by the rules¶

• bearer-http-uri¶

• bearer-https-uri¶

• bearer-ws-uri¶

• bearer-wss-uri¶

bearer-http-uri      = "bearer-http" ":" bearer-path [ "?" query ] [ "#" fragment ]
bearer-https-uri     = "bearer-https" ":" bearer-path [ "?" query ] [ "#" fragment ]
bearer-ws-uri        = "bearer-ws" ":" bearer-path [ "?" query ]
bearer-wss-uri       = "bearer-wss" ":" bearer-path [ "?" query ]
bearer-path          = absolute-bearer-path / relative-bearer-path
absolute-bearer-path = "//" token "@" host [ ":" port ] path-abempty
token                = *( unreserved / pct-encoded / sub-delims )
relative-bearer-path = token "@" segment-rel "/" path-rootless
segment-rel          = "." / ".."

The definitions of the following rules are adopted from the generic syntax of URI:¶

host          = <host, see [RFC3986], Section 3.2.2>
port          = <port, see [RFC3986], Section 3.2.3>
path-abempty  = <path-abempty, see [RFC3986], Section 3.3>
path-rootless = <path-rootless, see [RFC3986], Section 3.3>
unreserved    = <unreserved, see [RFC3986], Section 2.3>
pct-encoded   = <pct-encoded, see [RFC3986], Section 2.1>
sub-delims    = <sub-delims, see [RFC3986], Section 2.2>
query         = <query, see [RFC3986], Section 3.4>
fragment      = <fragment, see [RFC3986], Section 3.5>

If the token component of the bearer-URI is empty, it means that the Authorization header MUST be absent from the request.¶

If the host component of the bearer-URI is empty, the URI is relative and is valid only if there is a known base URI (cf. [RFC3986], section 5.1). Resolving the relative bearer-URI consists in creating a target bearer-URI where every component is taken from the relative bearer-URI except the host, taken from the base URI.¶

3.2. TODO: POLA

3.3. TODO: revocation