- From: <steve.e.magennis@gmail.com>
- Date: Wed, 19 Feb 2020 13:45:57 -0800
- To: "'Joe Andrieu'" <joe@legreq.com>, "'Credentials Community Group'" <public-credentials@w3.org>
- Message-ID: <02e401d5e76d$f84a5450$e8defcf0$@gmail.com>
Thanks Joe, no worries! Couple follow-up Q’s inline [SM]: -S From: Joe Andrieu <joe@legreq.com> Sent: Wednesday, February 19, 2020 10:21 AM To: Credentials Community Group <public-credentials@w3.org> Subject: Re: Today's presentation on Credentials v Capabilities Steve, My apologies, this got lost in the flurry with Daniel. Comments inline. On Tue, Feb 18, 2020, at 3:58 PM, steve.e.magennis@gmail.com <mailto:steve.e.magennis@gmail.com> wrote: Joe, thanks for elevating these distinctions. I’ve been trying to wrap my head around a number of credential use cases to see how they hold up. Hoping you can share you thinking here: * Looking at possible attenuations in the directed banking capability example, e.g. a controller can cut, but not sign a check. As I understood the presentation, the bank only cares about the capability/attenuation presented to it and not the person presenting it. If someone other than the controller were to take possession of the capability, the bank would gladly allow the check cutting action regardless of that person’s actual role. Does this imply that the responsibility of enforcing real-world attenuation and delegation would be left to the original recipient of a capability to manage by making sure only the right people obtain access to capabilities? I’m not seeing how the issuer service side could enforce this. The "directed" part in directed capabilities is that each delegate is specified with a cryptographically verifiable identifier, such as a DID. So, if someone gets your capability, it's useless unless they also get access to your private keys. If your private keys are compromised, all bets are off. The issuer enforces this by checking the delegation chain to make sure that each delegation is signed with the appropriate key. [SM]: I’m still a little confused. If Alice possesses a capability and wants to delegate it to Bob, would: * Alice inject a verifiable identifier representing Bob into the capability, indicating only Bob is entitled to the capability. The issuer service upon receipt then somehow verifies that the ID and Bob are the same and has been delegated the right to the capability. OR * Alice encrypt the capability with a private key for which Bob has the corresponding public key? Bob decrypts it and presents it to a service as a bearer capability; the service does not care if the presenter is Bob. OR * Something else? * I’ve always thought about credentials as coming in different flavors * Self-attestation: “I like ice-cream” | The truth of the statement by itself cannot be easily verified * Sovereign statement : “The sky is blue” | The truth of the statement must be independently verified * 3rd party claim: “Alice earned her degree” | Truth of the statement is evaluated based on the reputation of the issuer * Issuer / Verifier: “I hereby confer the right to Bob (or anyone possessing the credential) to sit in seat A23 at tonight’s showing of Thelma and Louise.” | The truth of the statement is pre-determined if the issuer and verifier are the same In the case where the issuer and verifier are the same, and the verifier chooses to ignore the identity of the holder, is that essentially a capability? It definitely gets more complicated when provenance and delegation chains come into play and maybe this is the distinguishing point you and Daniel were making. For example if an issuer and verifier (issuer’s service) are not the same, but rather cooperative entities where one issues and the other consumes, but both play by pre-arranged rules. I'm not sure I follow your flavors, but a VC is essentially a statement. Even if it asserts a privilege that should be afforded the Subject, it may or may not be invocable in any concrete way. Wrt issuers=-verifiers, IMO, an issuer should just keep a database rather than creating VCs which it gets the user to surface later. [SM]: By ‘flavors’ I mean roughly common types of statement that a VC might be used propagate. I didn’t mean to imply the existence of different types of VCs. I would assume that if the issuer and verifier were the ‘same’ it would be very odd if the privilege were not invocable in a concrete way, though I agree the Subject may choose to never invoke it. In the case of "pre-arranged" rules, we have two competing notions. The first is that of a trust framework. In practice, these have been extraordinarily complex and only worth the investment for high-value, high-volume transactions, such as the ones established by credit card companies. So far, it has proven elusive for general use, for reasons I won't go into here. I believe the complexity factor is innate and every such framework requires compromises that are expensive to achieve. Directed Capabilities bypass this form of complexity by ensuring that the DC only has meaning at the original issuer. Any "pre-arranged" rules are arranged by the same party that interprets them. The second notion of "pre-arranged rules" is that of standards. That's what we are here for: making up pre-arranged rules so we can reliably interact online in interesting ways. My personal opinion is that the simpler these standards are, the more likely they are to be adopted and to work. Call it the Occam's razor of standards adoption. The kind of complexity you need for a trust framework is far beyond what I would recommend pushing through as an open standard. In fact, that's kind of the point, the trust framework is defined by and for a limited audience: the members of the framework. Open standards need to be applicable to the broadest possible set of use cases, while still maintaining some semblance of unity of vision aligned with a specific solution. [SM]: Agree, I was thinking in terms of pre-arranged rules / trust established out of band. For example, if Acme issues a capability at the behest of Faber, both could agree ahead of time on the details of the capability, usage, etc. so that if and when a capability shows up at Faber, the service is performed as predicted. If the capability were to show up somewhere else it would likely just be ignored by the recipient. -j From: Joe Andrieu <joe@legreq.com <mailto:joe@legreq.com> > Sent: Tuesday, February 18, 2020 12:50 PM To: Credentials Community Group <public-credentials@w3.org <mailto:public-credentials@w3.org> > Subject: Re: Today's presentation on Credentials v Capabilities 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). 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 On Tue, Feb 18, 2020 at 11:06 AM Joe Andrieu <joe@legreq.com <mailto: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 -j -- Joe Andrieu, PMP joe@legreq.com <mailto:joe@legreq.com> LEGENDARY REQUIREMENTS +1(805)705-8651 Do what matters. http://legreq.com <http://www.legendaryrequirements.com> -- Joe Andrieu, PMP joe@legreq.com <mailto:joe@legreq.com> LEGENDARY REQUIREMENTS +1(805)705-8651 Do what matters. http://legreq.com <http://www.legendaryrequirements.com> -- Joe Andrieu, PMP joe@legreq.com <mailto: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 21:46:14 UTC