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

Responses inline:

On Fri, Sep 9, 2022 at 11:48 AM Alan Karp <alanhkarp@gmail.com> wrote:

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

Sounds like something the VCWG could add additional text to protect against
this.

1. You cannot make a credential that is a capability.
2. You can, but beware of X, Y, Z.


> Requiring a type field to clearly distinguish the intended use would
> resolve the problem.
>

In JSON-LD, the current type system supports multiple inheritance...

https://www.w3.org/TR/vc-data-model/#example-a-simple-example-of-a-verifiable-credential

```
"type": ["VerifiableCredential", "AlumniCredential"],
```

Imagine:

```
"type": ["VerifiableCredential", "AlumniCredential",
"AcademicResearchDataAccessCapability"],
```

In particular, certain fields would be forbidden (required) in an
> authorization VC and others forbidden (required) in a credential VC.
>

Sounds like a use case specific thing... or maybe better solved for with
selective disclosure... and ... presentations.


> Also,  how you revoke a VC depends on which type it is.
>
>
This is not true today... it's determined by the credential status type
property... not the credential type property:

https://www.w3.org/TR/vc-data-model/#status

It seems there was some foresight for this case, because "credential status
type", is different from the "credential type".

Should we have to define an entire different scheme to revoke capabilities?

... or can we build on / reuse terms defined in the VC Data Model.

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

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>