Re: Today's presentation on Credentials v Capabilities

Just addressing some missed points of communication:

On Tue, Feb 18, 2020, at 3:58 PM, Daniel Hardman wrote:
>> There are some misconceptions about how zCaps work (verifying a DID signature doesn't require phoning home to the DID subject)
> 
> I think you may be misconstruing something. Did you have the following sentence in mind when you made that conclusion? I said that the zCaps "mechanism for validating the non-revocation status of each credential in the delegation chain seemed to follow the same revocation checking pattern as traditional non-ZKP credentials." Note that this sentence has nothing about signature verification in it, and that it also has nothing about DID subjects in it. It's about revocation checking, not signatures.

Yes, I may have mis-read that. But two things. First, I'll note that there are, as yet, no standard revocation checking patterns for any credentials, ZKP or otherwise. There are approaches and even implementations, but nothing standard.

Second, zCaps don't have credentials in a chain. They have delegations in a chain. Revocation checks are not well defined in the spec, and, sadly, the only example is a rather frustrating phone home pattern.

Which is to say, yes, you can use crappy revocation processes. There are also other approaches that don't require as hamfisted an approach as 
"caveat": [ {"type": "ValidWhileTrue", "uri": "https://social.example/alyssa/ben-can-still-drive"}],

https://w3c-ccg.github.io/zcap-ld/

In other words, assumptions about revocation methods are likely to be wrong if you base it on the zcap-ld spec.

> 
>> and some root disagreements about priorities (ZKP ALL-THE-THINGS).
> 
> The mechanism I'm advocating is not dependent on ZKP technology, as the RFC states very explicitly at the top (and several places in the running text). You could implement it today with Digital Bazaar's JSON-LD-centric credentials, or with JWT-centric credentials, etc. I also pointed this out in my first message on the thread. I have never taken the position that we should "ZKP ALL-THE-THINGS." That is a caricature that seems to crop up from time to time in these circles; I would be glad of a general commitment from all of us to kill such distortions. As near as I can tell, the caricature seems to survive on careless FUD. I find it particularly amusing in this case, given the non-ZKP-oriented content I linked.

Unfortunately, I must put on my co-char hat and push back against calling this FUD. That's a dangerous accusation. One that is inappropriate to this community group. I've seen that term used outside this group referring to criticisms raised about ZKP. I can't control that, but I will call it out as unwelcome in the CCG. 

All criticism is acceptable in this community group as long as it is professional and respectful. Accusing me, or anyone, of FUD, is neither. Instead, respond to criticism with concrete and specific arguments. 

Returning to the discussion as a participant rather than moderator:

In your own discussion contrasting zCaps with your approach,
https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0104-chained-credentials/contrast-zcap-ld.md,
you say:
It wasn't obvious to us how to use ZCAP-LD when ZKPs are a desirable feature.

ZKPs are not necessarily a desirable feature. Presuming that they are is what I am referring to as "ZKP ALL-THE-THINGS" There are many of us who don't believe the tradeoffs of current ZKP approaches are worth it. In short, for an exceptionally marginal use case--which will likely not be usable for most transactions that require identity-proofing--you have to accept, at a minimum, untested cryptography and give up the ability to rotate subject keys without invalidating all of the credentials issued to you.

I don't have a problem with folks developing a ZKP-centric approach, but the fact that ZKPs are central to your world view was used as a reason not to use zCaps. I don't share that world view. That's what I was calling out in your contrast of the two approaches.


>> I also have my doubts about the security implications of "short circuiting" VC issuance.
> 
> Excellent. I invite you to contribute to the discussion about the VC threat model at credential-fraud-study@googlegroups.com, or to raise issues against Aries RFC 0207: Credential Fraud Threat Model <https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0207-credential-fraud-threat-model/README.md>; when there's evidence of serious engagement on the topic in W3C circles, perhaps we can finally bring it to this group as a work item. I raised the threat model topic at the Aug 2019 RWOT, but didn't have an opportunity to engage with you directly. My perception is that we're not thinking about this topic hard enough, yet. So your thoughts could probably help us a lot.

I've got my hands full with unpaid work at the moment. The way things work in the W3C is if you want serious engagement, YOU show up and engage. If you have a work item you'd like to propose, we would welcome it as long as they meet our fairly well-documented yet lightweight requirements. We have an open policy with regard to diverse perspectives and approaches. That's the point of the community group.

My short statement is this: your approach seems to find it desirable to avoid verifying every signature in a chain of VC delegations. From what I could glean, I don't see how this is credible. Every signature should be checked. Otherwise, you can't know if the delegation chain is, in fact, complete. Is there something I'm missing?

> 
>> 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.
> 
> It seems like maybe you haven't read the RFC? We could very well still have a difference of opinion when you've done that, but I doubt it will be about ambiguity.

I read it. I found it rather opaque as it illustrated the use cases with implementation details rather than clearly articulating what is happening without regard to the mechanisms proposed.

Frankly, I had similar difficulties absorbing the ocap model and then, later, mapping ocaps to zCaps. It was the insight about trust boundaries that "clicked" for me, which I shared in that presentation. In fact, the whole point of the presentation is that these are slippery, nuanced techniques and we need every insight we can to make them accessible to the typical developer.

Maybe there's something I'd find worth advancing in your approach, but I'm not yet seeing it. Maybe it will take the same kind of time and working familiarity with the approach to tease it out.

In the meantime, I see a clear distinction and use case boundary that delineates credentials from capabilities. Blurring those lines, IMO, wasn't helping anyone understand. Your approach further blurs those lines. I'm advocating that bright lines will allow both technologies to find their niche. 

Trying to do EVERYTHING with VCs is as bad as just using SAML or JWTs or JSON or whatever for everything. There are distinct layers in the architecture for a reason. Overuse of VCs is, IMO, a tale of holding a hammer and treating everything as a nail. I encourage you to set down the hammer of VCs and think through the security implications of open-ended delegations across trust boundaries. Then contrast that with closed-model delegatable actions restricted application within the same trust boundary. I find the latter tractable. The former, not so much.

THAT said. My approach to directed capabilities is like haiku. They can be beautiful. However, to be a haiku, they must follow the pattern. Limericks and Sonnets can also be beautiful poems. Your approach is different. It has different constraints and different security considerations. As such, it will never be a Haiku, although many may find it beautiful.

> 
>> 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?
> 
> Yes, I'd be glad to do that. Thank you for the invitation. How is an item like this scheduled?

The chairs schedule things on a weekly basis. Would March 3rd work for you? If so, I think we can make that work.

-j

--
Joe Andrieu, PMP joe@legreq.com
LEGENDARY REQUIREMENTS +1(805)705-8651
Do what matters. http://legreq.com <http://www.legendaryrequirements.com/>