- From: Snorre Lothar von Gohren Edwin <snorre@diwala.io>
- Date: Thu, 24 Nov 2022 11:45:17 +0100
- 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>
- Message-ID: <CAE8zwO3CEOAowi3v=WwPd9rpbv=dUOprZ--7asaCmXR-A7NPDw@mail.gmail.com>
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