Re: [zcap-spec] Request for Clarification (Is it "what" or "why?" and cross-matching)

Pardon me for butting in, but I've been using capabilities since 1996 and
may be able to clarify some things.


On Sun, Mar 5, 2023 at 12:30 PM Bob Wyman <bob@wyman.us> wrote:

>
> Since my issue may simply be that I don't understand the terms being used,
> let me ask: "How is a 'capability' different from a 'permission?'" Under
> what circumstances might one use a capability but not also exercise
> permission to use that capability? Is a capability without permission
> useful?
>

A capability is an unforgeable, transferable permission to use the thing it
designates.

Note that the capability has two parts, the thing it designates and the
permission.  That's the key thing that distinguishes it from other
access control systems, the combination of designation and authorization.


> I understand that RBAC systems
> <https://csrc.nist.gov/CSRC/media/Publications/conference-paper/1992/10/13/role-based-access-controls/documents/ferraiolo-kuhn-92.pdf> are
> often little better than ACL systems at addressing the risks avoided by
> capability systems. (The explanation for their weakness can be found in the
> "ACLs Don't <https://waterken.sourceforge.net/aclsdont/current.pdf>"
> paper.) However, it also seems to me that one can use capabilities to
> achieve, more securely, the same result as one might wish an RBAC to
> provide...
>

RBAC is an expression of an access policy, i.e., you may do these things if
you are in this role.  As such, it's a fine way to decide if someone should
get a specific capability.  Using RBAC to make an access decision when a
request is receivedi has the problems described in "ACLs Don't.""

>
> For instance, using the dating example of my original message, it seems to
> me that the "search" system would return to Bob a list of potential matches
> and that each match would include a "read profile" capability with caveats.
> If Alice was included in the list returned to Bob, and if Bob wanted to
> read Alice's profile, his request to use Alice's "read profile" capability
> would include proofs of both his gender and age since the caveats of
> Alice's capability constrain those attributes. (I assume that these proofs
> would be VCs.) Only if the proofs provided by Bob satisfied the caveats of
> Alice's "read profile" capability would Bob be able to read her profile. Is
> this correct and in line with what ZCap intends to support? As I understand
> it, such a system should avoid the "Confused Deputy," "Cross-Site Request
> Forgery," and other similar issues typical of ACL-based solutions. (Other
> issues would remain, of course.)
>

A capability system would do this differently.  Bob would present his
credentials, such as age and gender, and get back a capability authorizing
search with caveats limiting what he can find.  The return values would
include a capability to read Alice's profile.  Notice the difference?  Any
authorization is done up front in order to get a capability.  That
capability is then used to make a request.

>
> Please forgive me if I'm being dense. As the inventor, in the late 1980's,
> of one of the first Rights Expression Languages (DDSLA's LDIF), I may be
> prejudiced in my assessment of their scope of utility.
>

Don't feel bad.  You need to turn your brain inside out to understand
capabilities if you're familiar with other access control schemes.  It
takes time and exposure to get used to the difference in perspective.

--------------
Alan Karp


On Sun, Mar 5, 2023 at 12:30 PM Bob Wyman <bob@wyman.us> wrote:

> Manu,
> Thanks for your response. As is often the case, it appears that a shared
> understanding of relevant vocabulary is the first step towards shared
> understanding.
>
> Bob, first of all, I apologize that you had to read a spec that is out
>> of date and most likely sent you down the wrong thought exercise in
>> some cases.
>
> I was confused by the fact that the document
> <https://w3c-ccg.github.io/zcap-spec/> bears the date: "22 January 2023."
> I was surprised to find that and was wondering why a document would be
> revised without any contemporary discussion on this list.
>
> Since my issue may simply be that I don't understand the terms being used,
> let me ask: "How is a 'capability' different from a 'permission?'" Under
> what circumstances might one use a capability but not also exercise
> permission to use that capability? Is a capability without permission
> useful?
>
> We may agree about the similarity between capabilities and permissions
> since you said:
>
>> We could've done that *[i.e. used ODRL]*, but ODRL is so
>> open ended that we felt like it would introduce attack surfaces that
>> would be difficult to analyze/mitigate.
>
> I understand the security concern for something which has the broad
> expressive richness of ODRL. But, if "capabilities" and "permissions"
> really are the same thing, I can't help wondering why the language for
> expressing caveats wouldn't be a simplifying profile of either ODRL or some
> other REL. One reason for caring about this is that I am in the process of
> building up a system that requires some of the expressive richness of ODRL
> to do things similar to what one does with capabilities but I also know
> that if ZCAP capabilities become popular, I'll need to support them in some
> cases as well. Ideally, I'd have only a single piece of code to process
> both "permissions" and "capabilities." Is disdain for Linked Data really
> sufficient justification for requiring duplication of this function?
>
> I think you're describing Role-Based Access Control (RBAC), which are
>> (arguably) not capabilities.
>
> I understand that RBAC systems
> <https://csrc.nist.gov/CSRC/media/Publications/conference-paper/1992/10/13/role-based-access-controls/documents/ferraiolo-kuhn-92.pdf> are
> often little better than ACL systems at addressing the risks avoided by
> capability systems. (The explanation for their weakness can be found in the
> "ACLs Don't <https://waterken.sourceforge.net/aclsdont/current.pdf>"
> paper.) However, it also seems to me that one can use capabilities to
> achieve, more securely, the same result as one might wish an RBAC to
> provide...
>
> For instance, using the dating example of my original message, it seems to
> me that the "search" system would return to Bob a list of potential matches
> and that each match would include a "read profile" capability with caveats.
> If Alice was included in the list returned to Bob, and if Bob wanted to
> read Alice's profile, his request to use Alice's "read profile" capability
> would include proofs of both his gender and age since the caveats of
> Alice's capability constrain those attributes. (I assume that these proofs
> would be VCs.) Only if the proofs provided by Bob satisfied the caveats of
> Alice's "read profile" capability would Bob be able to read her profile. Is
> this correct and in line with what ZCap intends to support? As I understand
> it, such a system should avoid the "Confused Deputy," "Cross-Site Request
> Forgery," and other similar issues typical of ACL-based solutions. (Other
> issues would remain, of course.)
>

A capability system would do this differently.  Bob would present his
credentials, such as age and gender, and get back a capability authorizing
search with caveats limiting what he can find.  The return values would
include a capability to read Alice's profile.  Notice the difference?  Any
authorization is done up front in order to get a capability.  That
capability is then used to make a request.

>
> Please forgive me if I'm being dense. As the inventor, in the late 1980's,
> of one of the first Rights Expression Languages (DDSLA's LDIF), I may be
> prejudiced in my assessment of their scope of utility.
>
> bob wyman
>
>