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

Whether we seek to use the same DM for both might be determined by how we
define a wallet.

Most of us in this community, I dare say, are trying to avoid wallets
dominated by the platform oligopolies. We're hoping that some combination
of regulation and market forces will prevail in opening up the uses of VCs
through the DM and protocol standards we develop.

My proposed strategy is based on the assumption that people will store and
manage VCs in multiple apps that are separate from their biometric secure
element (BSE).  The BSE might, due to inadequate regulation and platform
oligopolies, be controlled by a hardware platform like today's mobile
wallets. To separate out the BSE functionality from multiple credential
management apps requires an interoperable standard for connecting the BSE
to an app and securely displaying the transaction request that is about to
be signed by the human using their biometric.

Sign-in with Ethereum is a very simple example of this separation between
BSE and apps. The transaction request is displayed in the BSE as a hybrid
of human and machine readable terms. This is not a particularly
sophisticated DM but it can work for many use-cases. In our implementation,
the request includes standard VCs as well as other components in a RAR
format. This approach would clearly benefit from more sophisticated DMs but
in our use-cases, including health care, it is more important to support
delegation to the app and to standardize the transaction request than to
worry about the details of VC DMs and the requisite proofs.

Adrian



On Fri, Sep 9, 2022 at 10:40 AM David Chadwick <
david.chadwick@crosswordcybersecurity.com> wrote:

>
> On 09/09/2022 13:45, Adrian Gropper wrote:
>
> 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?
>
> I would hope not.
>
> And since the VC DM is infinitely extensible, then I am suggesting we can
> use (different branches of ) the same DM for both.
>
>
> 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
>>
>>
>>