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

On Fri, Sep 9, 2022 at 6:02 AM Orie Steele <orie@transmute.industries>
wrote:

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

I don't disagree with you.  I am only worried about developers getting
confused and mix the two uses into a single VC.  Requiring a type field to
clearly distinguish the intended use would resolve the problem.  In
particular, certain fields would be forbidden (required) in an
authorization VC and others forbidden (required) in a credential VC.
Also,  how you revoke a VC depends on which type it is.

--------------
Alan Karp


On Fri, Sep 9, 2022 at 6:02 AM Orie Steele <orie@transmute.industries>
wrote:

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