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

Manu:

I really wanted to learn the secret of life, but of course I don't control
the did:key value you used in your capability example. Can I convince you
to share a broader capability with us? This may be our only chance to learn
the secret! :-) JK

On Sun, Mar 5, 2023 at 6:56 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> 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/
>
>