Capabilities for Distributed Authorization

3.1. Authentication

Password-based authentication mechanisms require that the tuple of user name and password (or password hash) are sent to some central repository where records of such tuples are kept; if the tuple is found, the user name is authenticated.¶

This common scheme mixes different aspects to authentication, however, which are worth disambiguating.¶

Endowment:

The act of logging in establishes an association between a user name and the person interacting with the device. More broadly speaking, (parts of) a three-way endowment are performed: an identifier is endowed with attributes, which describe a person in sufficient detail to identify them. The term "endowment" is used here because it is a superset of the more common "identity assertion", and also is less easily confused with the totality of identification concerns.¶

Secret Proving:

Logging in also proves that the person interacting with the device is in possession of some secret; this secret should only be known to the person which matches the description in the endowment step above.¶

This distinction becomes somewhat more relevant when we move towards distributed authentication schemes, which rely on public key cryptography. For now, consider that it is the combination of endowment and secret proving that make up authentication.¶

3.2. Authorization

Authorization occurs only after secret proving. Once an identity has been established, it is then mapped to associated privileges, which determine which object(s) it has access to.¶

There exist a plethora of methods to establish this mapping. Access-control lists (ACL) simply provide tuples of identities, privileges and associated objects. Role-based access control (RBAC) is effectively identical, if the identities specified are not those of individuals, but of groups (as a group member, an individual inhabits the associated role). A comparable approach is Organization-based access control (OrBAC), which not only abstracts the identity to that of a role, but performs a similar abstraction on the object and privilege.¶

More complex systems such as context- or lattice-based access control (CBAC and LBAC respectively) derive a mapping from properties of or labels attached to the individuals and objects. Finally, graph-based access control (GBAC) starts with a graph of an organization, and derives privileges from the properties inherited by being part of a larger organizational structure.¶

What these systems address is the problem of managing the mapping of an identity to access privileges for objects, where each system has advantages and disadvantages for various use cases.¶

In the abstract, however, they each operate on the following pieces of information:¶

Subject:

The subject is the identity (individual or group/role) that intends to perform an action.¶

Action:

The action the subject intends to perform may be as simple as reading or writing a resource, but can be more complex.¶

Object:

Actions are performed on objects , such as a file or network resource.¶

Request Tuple:

A request tuple consists of the subject, action and (optional) object.¶

Privilege:

A privilege encodes whether or not an action is permitted.¶

Authorization Tuple:

An authorization tuple encodes system state, and is thus a tuple of a subject, a privilege and an (optional) object.¶

The act of authorization translates from a request tuple to a Boolean response determining whether a request is permitted. A centralized authorization function provides this answer in real-time, via an API invocation.¶

By contrast, distributed authorization instead deals in authorization tuples, which can be stored and distributed out-of-band.¶

It may be of interest that and authorization tuple is semantically equivalent to an RDF triple ([RDF]), in that it encodes a specific relationship between a subject and an object. Authorization tuples that consists solely of IRIs [RFC3987] is also syntactically an RDF triple. This implies that authorization tuples can encode arbitrarily complex authorization information by building the knowledge graph resulting from resolving such an RDF triple.¶

4.1. Object-Capabilities (OCAP)

Dennis and Van Horn described an approach for securing computations in "multiprogrammed" systems in 1965/66 ([OCAP]). The context in which they operated had little to do with modern distributed systems.¶

However, they recognized the trend of running computing systems complex enough that multiple programmers would contribute to its overall function. This raised a desire for access control to individual sub-functions, which a security kernel within the operating system was to provide.¶

The key differentiator to other systems was that in OCAP, a calling process was to present a "capability", a serialized token to the process being invoked. This capability was intended to encode all relevant information the called process would need to determine whether the caller was permitted to perform such an action.¶

These properties of being serializable and containing all relevant authorization information imply that, conceptually, capabilities are cached results of an authorization query . The called process can then perform access granting without issuing such a query itself, thereby temporally decoupling the two functions.¶

4.2. Identity-Capabilities (ICAP)

The OCAP system proved to have a particular weakness, namely that "the right to exercise access carries with it the right to grant access". This is the result the information encoded in an OCAP capability: it contains a reference to the object and action to perform, but does not tie this to any identity.¶

In 1988, Li Gong sought to address this with an Identity-Capability model ([ICAP]). Including an identity in the capability token arrives at the authorization tuple in Section 3.2.¶

Furthermore, ICAP introduces the notion of capability use in networked systems. ICAP does this by temporally decoupling the authorization query from access granting.¶

The main criticism levelled against the paper and capability-based approaches in general in the following years was that some functions were missing, such as a check for revocations. Proposals to address this often added centralized functions again, which led to criticism of the distributed approach in general.¶

4.3. Pretty Good Privacy

While we previously discussed PGP in terms of authentication in Section 3.1.1, a key property of PGP is the introduction of trust signatures ([RFC4880], Section 5.2.3.13).¶

Trust signatures do not merely authenticate a user, they introduce a kind of authorization as well, as they carry specific notions for what the provided public key may be trusted for. The trust signature thus encodes specific kinds of privileges of an authorization tuple , while the public key encodes a subject . The only component missing in the tuple is the object .¶

While the authorization tuple in PGP is incomplete, the system is based on public key cryptography, and can thus be used to securely verify a binding between the tuple elements.¶

4.4. JSON Web Tokens (JWT)

JSON Web Tokens ([RFC7519]) provide a standardized way for serializing access tokens. Current uses are in systems with centralized authorization functions such as OAuth ([RFC6749]).¶

However, the fundamental notion of capabilities, that a serializable token carries authorization information, is provided also here. Furthermore, JWT combines this with cryptographic signatures, providing for - in theory - temporal decoupling as previously discussed.¶

It's well worth pointing out that JWT is suitable as a portable, modern capability format - all it requires is to encode all necessary information within its fields. One serialization format in JWT for this is [UCAN].¶

4.5. ZCAP-LD

Aimed at the linked data space, [ZCAP-LD] is an expression of cryptographic capabilities for authorization that relies heavily on linked data. While conceptually, the specification shares many similarities with the capability concept in this document, the use of linked data can lead to systems that do not provide for temporal decoupling .¶

Linked data has the downside here that data relationships may need to be resolved at the time of access granting , thus effectively re-introducing parts of an authorization query again at this point.¶

The concept of distributed systems underlying linked data thus differs fundamentally from the one in [RM3420]. Where the former treats distribution as distribution of concerns across different services providing parts of the linked data set, the latter is more concerned with resilience, specifically how to continue operating in the (temporary) absence of such services.¶

4.6. Power of Attorney

The oldest kind of prior work in this field is the concept of Power of Attorney, as exercised throughout much of human history.¶

In a Power of Attorney system, an authority (a king, etc.) grants a token (an official seal, ...) to a subordinate which makes this subordinate recognizable as carrying some of the king's powers and privileges.¶

Modern day Power of Attorney systems abound, and may be formalized as notarized letters granting such and such rights to other people.¶

Capability-based authorization schemes are no different to this kind of system in principle. In both kinds of systems, the token itself encodes the privileges of the bearer. [POA-IOT] describes such a system for the Internet-of-Things.¶

5.1. IoT On-boarding

On-boarding IoT devices into an overall system requires authentication and authorization; this may need to be mutual.¶

In such scenarios, new devices rarely have connectivity before completing on-boarding. It follows that authentication and authorization must work in a fully offline fashion, which in turn requires that authorization tokens provided to the device contain all information required for the authorization step. As described in Section 4.1, this translates to a requirement of temporally decoupling access granting from an authorization query.¶

This specific problem is also addressed in [POA-IOT] and related work.¶

5.2. UAV Control Handover

A similar argument applies to control handover of unmanned aerial vehicles (UAV). The concept of Beyond Visual Line of Sight (BVLOS) missions is to send drones into places that are harder or more costly to reach for humans.¶

Control handover refers to transferring operational control for a drone from one ground control station to (GCS) another. Control handover bears similarities to IoT on-boarding in that the drone is on-boarded to a new control system (and the previous system relinquishes control).¶

In general, aviation authorities such as FAA, EASA, etc. expect control handover to occur under ideal circumstances, in which centralized authorization schemes suffice. There is, however, a class of scenarios where connectivity to a central service cannot be guaranteed.¶

5.3. Zero Round-Trip-Time (0-RTT)

If fast authorization is a goal, reducing the number of roundtrips to establish a privilege follows. Due to the temporal decoupling that cryptographic capabilities provide, they're suitable for use in 0-RTT scenarios.¶

Of course, authorization can only follow when authentication already occurred. Authentication in a 0-RTT protocol is predicated on prior key exchange and verification.¶

Both [WIREGUARD] and DTLS 1.3 [RFC9147] offer 0-RTT handshakes. In the former, keys are pre-shared out of band, because WireGuard is used to establish static VPN tunnels. Because mutual authentication is assumed to be part of this process, authenticated encryption is sufficient to ensure that the keys are safely associated with network addresses in a 0-RTT roundtrip.¶

By contrast, DTLS simply offers different kinds of handshakes. 0-RTT can only be used for reconnection when a previous full handshake has provided sufficient authentication.¶

In either case, adding a capability to this 0-RTT handshake would also yield 0-RTT authorization, as long as the key that authenticates the remote party is also the subject of the authorization triple.¶

5.4. Human Rights Considerations

[RFC8280] lists a number of distinct objectives that help support human rights in protocol design. The above distributed authorization scheme addresses a number of them, such as Connectivity, Reliability, Content agnosticism, Integrity, Authenticity, Pseudonymity, Censorship Resistance, Outcome Transparency, Adaptability, Decentralization and Security, and by way of producing this document, Open Standards.¶

Rather than address each in detail, suffice to say that the use of pseudonymous public keys, and proofs based on cryptographic signatures, the majority of these objectives are reached.¶

It remains to highlight that the scheme outlined in this document observes the end-to-end principle, precisely by temporally decoupling different concerns. This permits for almost arbitrarily disrupted connectivity, and thus also censorship resistance. As capabilities can travel entirely out-of-band to any resource data, e.g. by sneakernet or similar means, they can be a building block of protocols that provide better human rights protections than systems that rely on temporal coupling of authorization concerns.¶

6.1. Grantor

A grantor, sometimes called principal, has authority over an object, and generates authorization tuples for use in the overall system.¶

As we describe cryptographic systems, a grantor is represented by an asymmetric key pair. Endowment for a grantor is out of scope of this document; for the purposes of distributed authorization, the grantor key pair is the grantor.¶

6.2. Agent

The agent is the element in a distributed system that executes a requested action after verifying a capability. It typically manages objects itself, or provides access to them.¶

6.3. Verifier

The verifier is a role in the system that verifies a capability. While verifiers can exist in a variety of system nodes, it's a mandatory part of the agent role.¶

Outside of the agent, verifiers may exist in intermediary nodes that mediate access to agents. An example here might be an authorization proxy that sits between the public internet and a closed system. While it may not be an agent in and of itself, it can still decide to reject invalid requests, and only forward those to agents that pass verification and its own forwarding rules.¶

6.4. Time-Delayed Transmission Channel

We introduce the concept of a time-delayed transmission channel to illustrate that communications between grantor and verifier is not possible in real-time.¶

In practice, of course the transmission channel does not have to be time- delayed. But treating it as such implies that granting access must be temporally decoupled from the authorization query.¶

6.5. Grantee

The grantee is the entity to which a privilege is granted.¶

A grantee SHOULD also be represented by an asymmetric key pair in order to perform distributed authentication.¶

6.6. Object

An object is a resource the grantee wishes to access. This can be a file, or a networked service, etc.¶

6.7. Privilege

A privilege encodes whether an action (on an object) is permitted (for a subject); see {#sec:authorization} for an explanation.¶

For the purposes of creating capabilities, a privilege must have a canonical encoding. The semantics of each privilege are out of scope of this document, and to be defined by the systems using distributed authorization.¶

That being said, a typical set of privileges might include read and write privileges for file-like resources.¶

6.8. Validity Metadata

In practical applications of distributed authorization scheme, validity of a capability may be further scoped. We already discussed the need to scope it to an authorization tuple, but further restrictions are likely desirable.¶

For example, a set of not-before and not-after timestamps exist in e.g. [X.509] certificates; similar temporal validity restrictions are likely required in practical systems.¶

However necessary they may be in practice, however, such additional validity metadata has no bearing on the fundamental concepts outlined in this document, and is therefore considered out of scope here.¶

6.9. Capability

A capability provides a serialized encoding of previously listed elements:¶

1. Fundamentally, a capability MUST encode an authorization tuple, consisting of:¶

   1. A subject identifier.¶
   2. A privilege. ¶
   3. An object identifier.¶
2. A grantor identifier MAY be required in order to identify the grantor key pair used in signing and verification.¶
3. Validity Metadata SHOULD be included in practical systems.¶
4. In order for a verifier to ensure the validity of a capability, it MUST finally contain a grantor signature over all preceding fields.¶

The authorization tuple permits an agent to determine what kind of access to grant or deny. The grantor identifier provides information to the verifier about key pairs used in the authorization. While the signature proves to the verifier that the grantor did indeed authorize access, the validity metadata limits access to whichever additional scope the grantor decided upon.¶

6.10. Authorization Process

Having identified the elements, we can now describe an abstract process in a distributed authorization system.¶

The process is split into two phases.¶

In the first phase, the grantor issues an authorization query (((authorization query))) to an authorization tuple store, which stands in here for the specific process by which authorization is managed, and produces tuples. Based on the response, it serializes a capability and adds its signature over it.¶

The capability then gets transmitted via the time-delayed transmission channel to the second phase, providing temporal decoupling between the phases.¶

In the second phase, the grantee requests access to some object from the agent. The agent must send a verification request to the verifier (which may be a subroutine of the agent; no network transmission is implied here). The verifier responds by either permitting access or not. If access is permitted, the agent grants access to the grantee. Because the capability encodes all required information for the verifier to perform this step, it does not need access to the authorization tuple store itself.¶

Note that the capability can be transmitted to any entity in the second phase; all that is relevant is that it ends up at the verifier. If it is transmitted to the grantee, it has to pass it on to the agent as part of the access request. If the agent receives it, it has to pass it on to the verifier as part of the verification request.¶

8.1. Human Rights Considerations

This document lists human rights considerations as a use case, see Section 5.4.¶

8.2. Protocol Considerations

There are no specific protocol considerations for this document.¶

However, protocols transmitting capabilities MAY provide some relief to human rights concerns Section 5.4, e.g. by providing confidentiality via encrypted transmission.¶

8.3. Security Considerations

This document does not specify a network protocol. In fact, it deliberately requires no specific protocol for transmitting capabilities. As such, much of [BCP72] does not apply.¶

However, distributed authorization does not require the invention of new cryptographic constructs; the document is deliberately phrased such that the choice of such constructs remains implementation defined.¶

As such, some security considerations are supported by the use of capabilities for distributed authorization, such as preventing unauthorized usage and inappropriate use.¶

Some notes on specific considerations follow.¶

8.4. Privacy Considerations

As part of supporting human rights considerations as a first class use case, exploring privacy considerations as covered by [RFC6973] is worthwhile.¶

In particular, distributed authorization schemes address the concerns of: intrusion and misattribution (as related to pseudonyms only).¶

It's also worth highlighting that surveillance and stored data concerns, as well as disclosure, are not addressed. In order for distributed capabilities to work, any likely recipient needs to be able to decode them.¶

The threat model then assumes that all capability data is accessible to anyone, which is why the use of pseudonymous public-key based identifiers is suggested. Sufficient care must be taken in key rotation, etc. in order to provide additional protections.¶

Note that despite this, nothing prevents a system from encrypting capabilities for use only by a single authorized party, which means that these last concerns can be addressed in the surrounding system.¶

8.5. IANA Considerations

This document has no IANA actions.¶