Bearer URIs

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. ). 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. ) 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. , 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.

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 .

This specification uses the Augmented Backus-Naur Form (ABNF) notation of .

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: ():

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

Bearer URI scheme	Embedded URI scheme
`bearer-http`	`http`	(see about the security considerations)
`bearer-https`	`https`
`bearer-ws`	`ws`	(see about the security considerations)
`bearer-wss`	`wss`

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).

The normal algorithm from (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 (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.

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. , 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.

mandates the use of TLS because transmitting bearer tokens on an unprotected channel is deemed too risky in the use case of OAuth. But fine grained capabilities have a wider use case than OAuth and may be used between services where security is guaranteed at a different layer, like IPsec or when services are communicating on a dedicated virtual network (which is typical in some cloud deployments). For this reason, this specification describes the use of bearer tokens both with and without TLS. Of course, bearer-http URIs SHOULD never be used over an unprotected channel. Doing so would make it possible for an observer anywhere on the path between the client and the server to store and reuse any capability that isn't otherwise limited in its use.

This specification defines several new URI schemes. Here are the informations for their registration to IANA according to .

bearer-http Provisional TBD

bearer-https Provisional TBD

bearer-ws Provisional TBD

bearer-wss Provisional TBD

The idea of a bearer-URI was independently discovered by several people before this specification was imagined and written, and its final form draws a lot of elements from the work of Neil Madden (), Ariadne Conill () and Christine Lemmber-Webber. The bearcap URI scheme was broader in that it was supposed to embed any URI where a bearer token might be used to create a capability URI. Using dedicated URI schemes to embed HTTP URIs has several desirable properties: When embedding a URI with query parameters, it avoids the need to escape it, which makes such URIs easier to transcribe, which is an important design goal of URIs (see , section 1.2.2). When the bearer token is a series of words like an XCKD password, this can make manual transcription of a bearer-URI both easy and reliable. When using absolute bearer-URIs, the sensitive information is in a part of the URI that the generic syntax of URIs already treats as sensitive, which makes it more likely that even software that doesn't recognizes these new URI schemes would handle the sensitive part accordingly. It avoids the confusion when new URIs are embedded in bearer-URIs. Different implementations might presume different semantics or implementation details which, for something that is central to security, can easily lead to serious security issues. Thus, if another URI scheme can be embedded with a bearer token, a new bearer-URI scheme will be created with precise semantics.