- From: Joe Andrieu <joe@legreq.com>
- Date: Tue, 18 Feb 2020 16:41:55 -0800
- To: "Credentials Community Group" <public-credentials@w3.org>
- Message-Id: <19813971-ad33-4eab-bb3d-d990544ff15a@www.fastmail.com>
That's correct. DIDs for the issuer of a VC is what allows avoiding the phone home problem. Other technologies do not. On Tue, Feb 18, 2020, at 4:30 PM, Leonard Rosenthol wrote: > No DID’s here, Joe. There aren’t necessary for VC. I can happily create claims w/o ever seeing a DID (and in fact am doing just that!). Using standard JWS & JAdES… > > Leonard > > *From: *Joe Andrieu <joe@legreq.com> > *Date: *Tuesday, February 18, 2020 at 7:28 PM > *To: *Credentials Community Group <public-credentials@w3.org> > *Subject: *Re: Today's presentation on Credentials v Capabilities > *Resent-From: *<public-credentials@w3.org> > *Resent-Date: *Tuesday, February 18, 2020 at 7:26 PM > > If the DID Method itself is sufficiently decentralized, the only phone home is to the network. BTC and ETH based DIDs can verify a signature without contacting the issuer. > > Of course, since anyone can make up a DID Method, it is possible to create a method that, in fact, phones home to get the certificate. > > -j > > On Tue, Feb 18, 2020, at 4:18 PM, Leonard Rosenthol wrote: >> > VCs are specifically designed to cross trust boundaries, from the issuer to the verifier. They can be verified without the verifier phoning home. >> > >> That is not necessarily true. A VC that uses an externally referenced signing certificate will require the verifier to “phone someone” (not necessarily home, but maybe) to obtain the certificate (and possibly the entire trust chain, revocation info, etc.) . >> >> Leonard >> >> *From: *Joe Andrieu <joe@legreq.com> >> *Date: *Tuesday, February 18, 2020 at 6:59 PM >> *To: *Credentials Community Group <public-credentials@w3.org> >> *Subject: *Re: Today's presentation on Credentials v Capabilities >> *Resent-From: *<public-credentials@w3.org> >> *Resent-Date: *Tuesday, February 18, 2020 at 6:58 PM >> >> The phrase that rang for me when I replied to Daniel is "trust boundary". >> >> VCs are specifically designed to cross trust boundaries, from the issuer to the verifier. They can be verified without the verifier phoning home. >> >> Directed Capabilities always return to the same trust context: the issuer. The holder can delegate (if allowed) to any allowed actions and with any allowed attenuations. These holder actions do not require phoning home. HOWEVER, invoking the capability inherently "phones home" because home is where the action takes place. >> >> VCs are useful if you need assertions that cross trust boundaries. DCs are useful if you want flexible delegation at the within a given trust boundary. >> >> If you use it elsewhere, use a VC. If you use it at the issuer, use a directed capability. >> >> -j >> >> On Tue, Feb 18, 2020, at 3:38 PM, Kim Hamilton wrote: >>> I was rambling in IRC about this during the meeting. The data model similarities (and differences) caught my eye, but based on the discussion, I saw why the zcap spec (for example) was more streamlined for the purpose. >>> >>> Yet, I did not understand how no-phone-home yet issuer-specific were reconcilable, but I didn't think there was time to get into it. >>> >>> Again, I was approaching it from a very low-level data model diff-ing perspective, and wondering if we will end up with a range of VerifiableXs in the future. >>> >>> On Tue, Feb 18, 2020 at 3:54 PM Joe Andrieu <joe@legreq.com> wrote: >>>> >>>> Daniel, >>>> >>>> Let's dive into this. I agree that VCs can be used for delegation. I just don't believe they are the most appropriate way to do so. You can, of course, say *anything* in a VC, so you can easily make statements that are interpreted as delegations. But VCs themselves do not provide mechanisms to specify or interpret capabilities and delegations. >>>> >>>> So, let's take your first statement: >>>>> 1. Credentials can be made delegatable, and they can be attenuated. This collapses the most interesting differences between credentials and capabilities, making a special new data format for capabilities unnecessary. Capabilities can be done with VCs (any type that's W3C-data-model-compliant). >>>> >>>> Can you provide an example? Even better if you start with a VC, issued by Joe, that claims "The sky is blue". We'll call this VC X. >>>> >>>> What does it mean to delegate that? Or attenuate it. >>>> >>>> Yes, I can make statements about that statement. I can even make arbitrary statements about that statement. I could say "Joe delegates the credential X". But these appear to have no meaning. >>>> >>>> Generally only privileges are delegatable. So, the only VCs that are delegatable are those expressing privileges. But which VCs should be interpreted that way? Certainly not VC X. So how does anyone know which VCs are delegatable? Further, how does anyone know the boundaries of that delegation, that is, the range of verifiers for whom such delegation is appropriate? Just because I give my child a VC saying they can use my credit card to buy milk at Ralph's doesn't mean that the cashier at LiquorMart will honor that constraint. Heck, all they need is the credit card # and a willing cashier. More importantly, will the credit card companies recognize that delegation as legitimate? What if they accept the first one (because "Milk from Ralph's" is fairly well defined) but they reject the second one? More likely, because the LiquorMart POS almost certainly doesn't require a VC of any particular type, the cashier will probably just make the sale. In contrast, the same use case using zCaps would originate at the credit card company and invoking it at either the LiquorMart or Ralph's would definitively validate the purchase according to the delegation framework as defined by the credit card company... and the retailer would immediately know whether or not the transaction is valid. >>>> >>>> zCaps is a particular set of semantically rigorous operations that define, without ambiguity, how delegation and invocation proceeds for particular actions at a given issuer. I have my doubts about the wisdom of shoe-horning custom semantics into the VC structure, which is meant for verifying statements by one source at another. Statements across trust boundaries and actions within a singular trust context are two very different beasts, IMO. >>>> >>>> I also read through the article contrasting zCaps with your approach (https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0104-chained-credentials/contrast-zcap-ld.md <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhyperledger%2Faries-rfcs%2Fblob%2Fmaster%2Fconcepts%2F0104-chained-credentials%2Fcontrast-zcap-ld.md&data=02%7C01%7Clrosenth%40adobe.com%7C46651439b72642ccbb0c08d7b4d29148%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637176688799077797&sdata=awJ8O%2FOKna18MLkfprwyhKHTrSw65PZmQD%2Be4F57RVw%3D&reserved=0>). >>>> >>>> I won't go into it line-by-line here, but I do invite others to review it. >>>> >>>> There are some misconceptions about how zCaps work (verifying a DID signature doesn't require phoning home to the DID subject) and some root disagreements about priorities (ZKP ALL-THE-THINGS). I also have my doubts about the security implications of "short circuiting" VC issuance. >>>> >>>> That said, I'll repeat my opening statement. YES, you can use VCs to construct delegations. >>>> >>>> But IMO doing so is barely more rigorous than using a printed contract for the same purpose. Maybe it will be accepted by a verifier, maybe it won't. Maybe it will make sense to a verifier, maybe it won't. Maybe it will be delegated appropriately, maybe it won't. Maybe the verifier will be able to make sense of delegations, maybe they won't. zCaps fixes all that ambiguity, IMO. >>>> >>>> Let me finish by inviting you to present your approach on a future call. My discussion was to socialize a distinction between credentials and capabilities that is creating value for people I'm working with. As CCG co-chair, it would be a service to the community if you could present your approach to directed capabilities. >>>> >>>> Would you be up for that? >>>> >>>> -j >>>> >>>> On Tue, Feb 18, 2020, at 10:52 AM, Daniel Hardman wrote: >>>>> FWIW, I would like to offer the following alternative perspective to the ideas in Joe's slides. >>>>> >>>>> 1. Credentials can be made delegatable, and they can be attenuated. This collapses the most interesting differences between credentials and capabilities, making a special new data format for capabilities unnecessary. Capabilities can be done with VCs (any type that's W3C-data-model-compliant). >>>>> >>>>> 2. The problem of extending privileges (delegation and attenuation) is actually a special case of the more general problem of data provenance. Delegation just requires that we show the provenance of privileges (did these privileges derive from someone who had them to give away?). But solving the data provenance problem has additional far-reaching benefits (a small employer can prove the provenance of data that they collected from an employee, that originated in a passport -- and the assurance associated with the employment credential, for those attributes, can be as strong as it was for data directly from the passport itself, instead of being governed by whatever trust someone might be inclined to give to the small and unfamiliar employer). >>>>> >>>>> This is discussed at length in Aries RFC 0104: https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0104-chained-credentials/README.md <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhyperledger%2Faries-rfcs%2Fblob%2Fmaster%2Fconcepts%2F0104-chained-credentials%2FREADME.md&data=02%7C01%7Clrosenth%40adobe.com%7C46651439b72642ccbb0c08d7b4d29148%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637176688799087792&sdata=7ozkMx0pvM4Jo6NpizzdKsnaqEfuAI3koyLbOyWAc0o%3D&reserved=0> >>>>> >>>>> >>>>> On Tue, Feb 18, 2020 at 11:06 AM Joe Andrieu <joe@legreq.com> wrote: >>>>>> >>>>>> Here's a link to the powerpoint for today's tech talk. >>>>>> >>>>>> https://github.com/w3c-ccg/meetings/blob/gh-pages/2020-02-18/credentials_and_capabilities.pptx?raw=true <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c-ccg%2Fmeetings%2Fblob%2Fgh-pages%2F2020-02-18%2Fcredentials_and_capabilities.pptx%3Fraw%3Dtrue&data=02%7C01%7Clrosenth%40adobe.com%7C46651439b72642ccbb0c08d7b4d29148%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637176688799087792&sdata=J7nrGe1yekynJ4XbeNW2VX%2BPFwWR7Md%2Fw7KA9h0bnFs%3D&reserved=0> >>>>>> >>>>>> -j >>>>>> >>>>>> -- >>>>>> Joe Andrieu, PMP joe@legreq.com >>>>>> LEGENDARY REQUIREMENTS +1(805)705-8651 >>>>>> Do what matters. http://legreq.com <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.legendaryrequirements.com%2F&data=02%7C01%7Clrosenth%40adobe.com%7C46651439b72642ccbb0c08d7b4d29148%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637176688799097787&sdata=g4KAohoxRXoVt%2Bx2g8hjlKaxiJYxv8SsEfutSOERiZM%3D&reserved=0> >>>>>> >>>>>> >>>> >>>> -- >>>> Joe Andrieu, PMP joe@legreq.com >>>> LEGENDARY REQUIREMENTS +1(805)705-8651 >>>> Do what matters. http://legreq.com <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.legendaryrequirements.com%2F&data=02%7C01%7Clrosenth%40adobe.com%7C46651439b72642ccbb0c08d7b4d29148%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637176688799107780&sdata=lCNW8HshPTHYsKbTo2%2FQHrpPAVwamzkPZVcxiLW3rR4%3D&reserved=0> >>>> >>>> >> >> -- >> Joe Andrieu, PMP joe@legreq.com >> LEGENDARY REQUIREMENTS +1(805)705-8651 >> Do what matters. http://legreq.com <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.legendaryrequirements.com%2F&data=02%7C01%7Clrosenth%40adobe.com%7C46651439b72642ccbb0c08d7b4d29148%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637176688799107780&sdata=lCNW8HshPTHYsKbTo2%2FQHrpPAVwamzkPZVcxiLW3rR4%3D&reserved=0> >> >> > > -- > Joe Andrieu, PMP joe@legreq.com > LEGENDARY REQUIREMENTS +1(805)705-8651 > Do what matters. http://legreq.com <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.legendaryrequirements.com%2F&data=02%7C01%7Clrosenth%40adobe.com%7C46651439b72642ccbb0c08d7b4d29148%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637176688799117771&sdata=L6W1n363jaTtr0TsJsFbuOjoS%2FgwpqAp8O5jWWo6Dus%3D&reserved=0> > > -- Joe Andrieu, PMP joe@legreq.com LEGENDARY REQUIREMENTS +1(805)705-8651 Do what matters. http://legreq.com <http://www.legendaryrequirements.com/>
Received on Wednesday, 19 February 2020 00:42:37 UTC