The RBAC page you link says nothing about tokens, because tokens are not a fundamental part of RBAC.

It's true that secret tokens commonly appear in security system implementations, and secret tokens usually could qualify as (weak) capabilities by definition. However, usually such tokens are not intended to be used as capabilities, but are rather a practical implementation detail, and the fact that they are transferable is seen as a weakness. E.g. when you log into a web site it stores a cookie on your system which you present back to the server to authorize each request, but abstractly the security model calls for authenticating that each request is coming from you, and the token is being used as a hack to avoid making you sign every request.

Capability-based security is a field of security theory which goes far beyond describing these implementation-detail tokens. In fact, when tokens are used in capability systems, they are again an implementation compromise. A good capability system does not assign authority to a secret sequence of bits, but rather is based on communications protocols where capabilities are explicitly recognized as they pass between contexts. For example, a unix file descriptor is a sort of capability, but its numeric value is not a secret token. It's secure because only the process which possesses the descriptor can access it using that number. You can pass file descriptors between processes, and the OS knows that the transfer is happening and assigns a new number to the object in the new process.

The researchers at the forefront of capability-based security theory, such as Mark Miller, strenuously oppose RBAC. Alan Karp, another researcher, likes to call capabilities "ZBAC" -- "authoriZation-Based Access Control" -- to make explicitly clear that he's talking about a different thing (though I'm not a fan of this acronym personally). Trust me, I know these guys and they will fight hard against any suggestion that their research and RBAC are the same thing.

> You can leave out identities or assume them (eg. IIRC Linux's OS-level capabilities assume this on a per-process or cgroup basis).

Linux OS-level capabilities are NOT capability-based security. This is a common misconception -- Linux/POSIX capabilities were misnamed by people who didn't understand the capability-based security model which predated them. Maybe this is what's confusing you. Indeed, Linux kernel "capabilities" are much more similar to RBAC than to capability-based security.

File descriptors are much closer to being capability-based. Once you have an open file descriptor, you can pass it off to another process. That process will be able to access the file descriptor in the same ways that you could, even if that process doesn't have permission to open the underlying file directly. That's capability-based security. Though, disclaimer: file descriptors are missing a lot of features which are normally considered necessary in a high-quality capability system.

EDIT: Please don't reply by adding new text to the parent post, it's really confusing.

> full of appeals to authority

We're debating the meaning of "capability-based security" and whether it should be merged with "Role-based access control" on Wikipedia. The opinions of the people who have literally spent years or decades of their lives researching these fields is relevant, because they literally defined the terms.

If we were debating whether capability-based security or RBAC is better-suited to a particular purpose, then appeals to authority would be invalid.

> Perhaps you can define briefly the difference between an authentication token in any other security system and a capability in the terminology you are using?

A capability is both a pointer to a resource and a grant of access to that resource. A capability is the subject of an operation.

An authentication token is a thing tacked on to requests indicating that the request was made by some particular user identity. In a way, you could consider it a capability to the user account, where the user account in turn contains capabilities to everything the user can access, and the request receiver digs into that bag and pulls out the needed one automatically in order to authenticate the request -- however, this is convoluted, and not how capabilities are normally used.

A fundamental difference between capability systems and identity systems is "ambient authority". In an identity system, you are authorized to perform a request simply because of who you are. It's "ambient".

Consider how you delegate access to someone else in the two systems:

- In an ACL system, Alice adds Bob to the ACL for a resource, and then asks that Bob to perform an operation on her behalf. However, if Alice is malicious she could request that Bob perform an operation on some other resources which Alice never had access to but Bob did. This is called a confused deputy attack. Bob must carefully check that Alice has the correct permissions on the resource before acting on her behalf.

- In a capability system, Alice sends Bob her capability and then asks Bob to access it. There is no risk of confused deputy because there is no way for Alice to instruct Bob to use a capability that he has but Alice doesn't.

> My interest is in the abstract model, not the implementation.

Then the use of tokens is not relevant.

> If you are talking about the capsicum implementation

I'm not. I'm talking about things like the E programming language, or Microsoft's Midori, or my own Cap'n Proto and Sandstorm.io, or Google Docs invite tokens (an example of an accidental capability system), etc.

> the sort of thing Laurie encourages ignoring

Ben Laurie, who is a friend of mine, would absolutely object to the idea that RBAC and capabilities are the same thing. He is also once of the driving forces behind capsicum so I think you may misunderstand his views on it.

> my view is that they're all just dynamic (feel free to read "glorified") ACLs

Mark Miller et al. explicitly address that belief here:

http://www.erights.org/elib/capability/duals/myths.html#equi...

Of course, if you zoom out far enough, you can argue that anything is basically the same as anything else. But it takes a very liberal definition of "access control list" to include an access control mechanism that does not involve any kind of "list".

> I remain unconvinced of the supposed uniqueness

It's a valid opinion, but you really shouldn't be proposing merging two fields of research on Wikipedia based on an opinion that differs from the experts in said fields.