Re: Today's presentation on Credentials v Capabilities

On Wed, Feb 19, 2020, at 1:45 PM, steve.e.magennis@gmail.com wrote:
> Thanks Joe, no worries! Couple follow-up Q’s inline *[SM]:*

> -S

> 

> *From:* Joe Andrieu <joe@legreq.com> 
> 

> On Tue, Feb 18, 2020, at 3:58 PM, 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.

No. The delegation wraps the capability and adds a delegation, using a verifiable identifier. The service has no idea who "Bob" is. They just know that a delegated party has demonstrated control of the private cryptographic material associated with the delegate identifier.

> 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?

Something else, as described above. There is no encryption. Just signing the chain that declares the delegation.

> 

>> 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.

> 

> *[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.


Yes. The point is to do that in a secure and reliable fashion. With Directed Capabilities, the issuer is also the invocation service, so the meaning of the capability is explicitly understood, inspectable, and auditable. They created it, they understand it. Any system that relies on an externalized set of rules is subject to interpretation. We have a nearly $1 trillion global legal industry that helps people and organizations establish pre-arranged rules of trust and then deal with disagreements in interpretation. The rule of law is a powerful thing, but it is cumbersome and expensive.

Directed capabilities avoid that risk of misinterpretation by keeping the meaning of the capability in a closed system. The recipient is free to delegate and attenuate, but the underlying meaning of the capability itself is always resolved by the issuer.

It's actually amazing in its simplicity and power. I didn't come up with it, but I'm finding myself more and more aligned with its fundamental approach to enabling arbitrary delegation within a rigorous context. The recipient or any of the delegates might misunderstand the capability, but the invocation service will not. The risk of confusion at the point of invocation is avoided.

As soon as you adopt a VC-like mechanism, where the delegation is applied at a service OTHER than that of the issuer, you cross trust boundaries and open the flood gates to semantic mismatch and misalignment of expectations and requirements.

-j

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