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

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

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