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