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

On Sat, Mar 4, 2023 at 4:19 PM Bob Wyman <bob@wyman.us> wrote:
> After reading Authorization Capabilities for Linked Data v0.3 (ZCAP-LD)

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. Many of the people that were working on ZCAPs just jumped
forward to doing implementations and that's where most of the
"knowledge" is these days. We have yet to circle back to the spec to
update it.

If you're code-oriented, reading the docs in the ezcap library might
be more useful on how this stuff is used in practice (but that
requires quite a bit of connecting the dots):

https://github.com/digitalbazaar/ezcap

> why was ODRL rejected?

ODRL was rejected for two reasons: 1) it's application is too broad
for a security specification, and 2) it's not clear that ZCAPs need
Linked Data (in fact, we've been trying to figure out ways to remove
the Linked Data requirement for several years now).

> Also, I'm a bit confused by the "who" vs. "what" distinction offered in the spec.

I read that paragraph several times and couldn't figure out what
question you are asking. I'm going to try parsing the rest of what you
wrote to see if it becomes more obvious... I might just be being
dense.

> I think I could understand ZCAP-LD better if I understood how it would work in an application which requires the assignment to actors of permissions or capabilities based on the actors' claimed attributes, rather than based on their identifiers. (i.e. sort of like an ACL, but different.)

I think you're describing Role-Based Access Control (RBAC), which are
(arguably) not capabilities. I'll let Dmitri chime in here in case he
wants to get on this "RBAC is just as good" soap box. :)

> Can you give me some idea of how capabilities might be used in the simple system described below:

No, because you described a system where it would take quite a bit of
effort to explain where capabilities should be applied, so I'm going
to try to build up from first principles. :)

Here's a capability to read the pitch deck on creating the Verifiable
Credentials Working Group to W3C Members:

(READ, "https://docs.google.com/presentation/d/1623vnHdndSKu-pMBC4RZTp5_WkAevYm4GDBZARwggLo/edit")

Anyone that holds that capability (now, everyone on this mailing list)
can read that document. That's a bearer capability. It designates the
permission and the resource.

Here's another capability to read a document called "The Secret of Life":

(READ, "https://docs.google.com/presentation/d/vYm4GDBZARndSKu-pMBC4RZTp5_WkAewggLo1623vnHd/edit",
did:key:z6MkqvajY2zUw866mQyY2LRwdPXKov1Q48Hw8RWxnKd1AeEt)

And whomever can do a digital signature as that did:key will learn the
secret of life. That's a capability that requires cryptographic proof
of some kind when access to the document is requested. The requirement
of a cryptographic proof is called a "caveat" -- that is, "You can
access X, as long as you meet requirements Y."

That's fundamentally all a capability is, and going much beyond that
is what gets all of us into trouble (but sometimes that's
unavoidable).

The question you asked could be interpreted as "Why didn't you use
ODRL for expressing caveats?". We could've done that, but ODRL is so
open ended that we felt like it would introduce attack surfaces that
would be difficult to analyze/mitigate.

So, let's start with that as the basis for the discussion and build
from there. Did I answer your question (unlikely)? Or does the above
empower you to frame your question in a way that I, or someone else on
this list, might understand?

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/

Received on Sunday, 5 March 2023 17:52:54 UTC