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

Open ID seems to be doing fine using JWT for both id_token and access_token
s... With far more adoption than verifiable credentials or semantic object
capabilities.

The arguments against allowing for a single standard to be used multiple
ways don't make sense to me.

Especially given the success of JOSE / COSE / OIDC.

Specifying claims is the job of the issuer, interpreting them is the job of
the verifier.

Telling an issuer that they can't specify claims that only they will
verify, but they can specify claims that mostly a 3rd party will verify...
Does not make sense.

Forbidding verifiable credentials from being capabilities feels like
competition suppression packaged as "a community that knows better,
protecting users from themselves"...

It reminds me of Apple refusing to implement web standards or mDoc only
supporting drivers licenses and vaccination credentials.

It feels like being tricked into buying an entire different system based on
semantic preferences that make very little sense, and that can easily be
changed if the community realizes that they are responsible for creating
those restrictions in the first place...

As the wise Morpheus once said: "Free your mind".

Regards,

OS




On Fri, Sep 9, 2022, 5: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
>
>
>