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

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

From: Snorre Lothar von Gohren Edwin <snorre@diwala.io>
Date: Thu, 24 Nov 2022 11:45:17 +0100
Message-ID: <CAE8zwO3CEOAowi3v=WwPd9rpbv=dUOprZ--7asaCmXR-A7NPDw@mail.gmail.com>
To: Alan Karp <alanhkarp@gmail.com>
Cc: Orie Steele <orie@transmute.industries>, David Chadwick <d.w.chadwick@truetrust.co.uk>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
Always a bit late to the party here!
But this discussion is truely interesting and I wonder how can this be
taken further?
I wonder since this stopped now and I want to see this get a proper sendoff.

Shall it be an issue in the VC WG github?
Next time people of this community meet physically?
ᐧ

On Fri, Sep 9, 2022 at 10:34 PM Alan Karp <alanhkarp@gmail.com> wrote:

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

-- 

*Snorre Lothar von Gohren Edwin*
Co-Founder & CTO, Diwala
+47 411 611 94
www.diwala.io
<http://www.diwala.io/>
*Stay on top of Diwala news on social media! **Facebook
<https://www.facebook.com/diwalaorg>** / **LinkedIn
<https://www.linkedin.com/company/diwala>** / **Instagram
<https://www.instagram.com/diwala_/>** / **Twitter
<https://twitter.com/Diwala>*
Received on Thursday, 24 November 2022 10:45:42 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 November 2022 10:45:43 UTC