W3C home > Mailing lists > Public > public-credentials@w3.org > September 2022

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

From: Alan Karp <alanhkarp@gmail.com>
Date: Fri, 9 Sep 2022 13:31:23 -0700
Message-ID: <CANpA1Z0fszQcgcoQbjtdJr2_62RxvzfYp9J10jHiCKCNLHGcNg@mail.gmail.com>
To: Orie Steele <orie@transmute.industries>
Cc: David Chadwick <d.w.chadwick@truetrust.co.uk>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Comments inline.

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


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

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

I prefer strict rules rather than warnings.  Just to make up something, a
credential VC with a scope field should be rejected as invalid.  Similarly,
an authorization VC that does not specify a resource should also be
rejected.

>
>
>> 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"],
> ```
>
> This is a capability anti-pattern.  What if the holder wants to delegate
just the permission?  The other risk is that developers will use the
additional fields in an ACL-like manner.


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

I don't have a complete design in mind, but one field that makes sense for
a capability but not a credential is scope.

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

Since the capability designates the resource, you can revoke by telling the
resource not to honor this certificate.  Since you never know who will
validate a credential VC, you need something like a CRL.

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

Agreed.  I expect the majority of the fields will be common to the two
uses.

>
> --------------
>> 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>
>
Received on Friday, 9 September 2022 20:31:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 9 September 2022 20:31:48 UTC