Re: Verifiable Credentials as Authorization Anti-Pattern (was Re: Funded Deployments of Verifiable Credentials - framework for meta-credentials)

I'm confused. Regardless of how we define a wallet, it sounds like Manu is
talking about the data model of a thing and David is talking about the
protocols for receiving and presenting a thing. Must the receipt and
presentation protocols be different for VCs vs. capabilities?

Adrian

On Fri, Sep 9, 2022 at 6:36 AM David Chadwick <d.w.chadwick@truetrust.co.uk>
wrote:

> Hi Manu
>
> you are absolutely right, and I said as much (in different words) in my
> earlier response to Steve. The complexity in capability based processing
> vs. ABAC processing is not in the token format but is in the processing
> rules and associated machinery. And you have nicely highlighted below what
> some of these capability processing rules are. I was thinking more from my
> wallet perspective that today I hold different types of plastic cards in my
> leather wallet, but they all have the same format even though the contents
> of them are very different, and they serve very different usage purposes.
> But this does not confuse me. So I don't believe it would confuse users if
> they held ABAC VCs and Capability VCs in their same electronic wallet.
> Hence a common format for issuing, holding, viewing and transferring them
> might be beneficial. However, you think this might lead to developer
> confusion. Probably so, since some developers are already confused by the
> VC DMv1.1 specification! But are you proposing two entirely separate
> infrastructures for ZCAPs and VCs? Or do you see that a common wallet could
> be used for both?
>
> Kind regards
>
> David
> On 08/09/2022 20:54, Manu Sporny wrote:
>
> On Thu, Sep 8, 2022 at 3:32 PM David Chadwick<d.w.chadwick@truetrust.co.uk> <d.w.chadwick@truetrust.co.uk> wrote:
>
> I am asserting that with an appropriate schema a VC can be specified to be a capability.
>
> Ok, good, let's go down that path. In order to do that, we would have to:
>
> 1. Change the current specification, or define a new specification and
> add a new VC type called "Capability" (so we can tell a capability
> apart from a regular VC).
>
> 2. We would need to add properties for "resource" and "action" (at the
> very least).
>
> 3. We would also need to add properties to designate parentCapability,
> invoker, caveats, and pointers to capability chains.
>
> 4. We would have to define new normative cryptographic verification
> rules that are substantially different from how you verify VCs (for
> DI, JWT-VC, etc.). Remember, you can delegate and chain capabilities,
> and the capability isn't valid unless you also validate the capability
> chain, and the way you do that is different from the way you validate
> VCs. We would have to specifically make VC-based (DI/JWT-VC/etc.)
> verification illegal (because the danger is that someone does that, a
> regular VC Verifier gives you a "signature is valid" without checking
> the capability chain, which it has no idea how to do).
>
> 5. We'd have to also figure out what it means to "present" a
> capability and create language that tries to explain that "presenting
> a capability" is really "invoking it"... which will probably require
> us to redefine how presentation works, but only for this very specific
> type of Capability VC.
>
> These are just the specification problems that I can think of at this
> moment, nevermind the developer confusion that will be created by
> trying to embed a security model that is quite different from a VC,
> into a VC.
>
> How do you suggest we address at least the problems above, David?
>
> -- manu
>
>
>