Re: VCs - zCaps / OCap a Discussion

Stephen Curran writes:

> Thanks, Alan, but I think you answered my question with both Yes and No.
>
> Directly, you said it doesn't matter.  But your follow up statement  ("You
> can (and should) create a one-off key pair for every capability") implies
> to me that you (as the capability issuer/verifier) do want to be sure that
> the entity (or delegates) using the capability demonstrate they indeed were
> given the capability. I interpret that as answering my question as "yes --
> it matters to whom the capability is given".  It doesn't matter the
> identity of the person (gov't ID, name, or anything like that), just that
> they can demonstrate they have a verifiable chain to the key-pair
> associated with the given capability.

Whether or not to create one-off keypairs for every capability is not
agreed upon by everyone; it made no sense to me originally, but has come
to make more sense over time.  I think the DB folks still prefer to
reuse keys across capaiblities.

Rather than debate whether or not it's a good idea, I think it's worth
introducing that this is a nice demonstration of something that "makes
sense" in zcap-ld land that doesn't "make sense" in VC land.  A
reasonable and functioning system *can* be built where you have one-off
keypairs for each authorization, but it wouldn't function for VCs as
identity-and-claims-demontrstating systems... a different identity every
time???  That'd be hot nonsense because we need to "think about" claims
in notion to identities that persist across different ideas and topics
and stories over time.  Such is the nature of narrative language, it
looks backward and spins a story about what has happened to help us
*inform* the future... it is not necessarily the domain of action, which
is in the present and moving forward.  In the physics of action,
particles of air are traveling towards the cup, pushing it off the
table.  In the retrospect of narrative, we construct a story of how that
air got there... was it the wind, or did it come from Alice blowing at
it?

This helps illustrate the nature of the two as being different: VCs are
inherently tied to the idea of an identity that is long-lived.  zcap-ld
capabilities are not.  This is because they are solving different
problems.

Again, it's correctly observed that you can't escape identity; nobody in
the ocap/zcap world is claiming that you can.  Rather, the claim is that
the role of identity/credentials/claims are, in a well designed system,
*separate* from authorization... and that using the former *for* the
latter.

They are *duals*, but this does not mean they are the *same*; I am going
to show another example of duals interacting with each other, well known
in computer science: the cover of SICP famously has a wizard with a
ying/yang saying eval/apply, two essential operations to a running
language, which keep calling each other over and over again as they
evaluate code.  Despite them calling each other, this does not mean they
are the same, even though they work together towards a goal (finding out
the result of that function you just called!).  Like ying and yang, they
are separate, yet complementary.  Distinct, yet intertwined.

If we design our system right, the world of action/command/ocaps and the
world of identity/description/VCs are also duals.  Separate, yet
complementary.  Distinct, yet intertwined.

I keep re-emphasizing that the world of zcaps/ocaps are more akin to a
machine than a narrative structure.  We have immersed them in a
narrative structure, giving them more narrative than the usual gears and
pistons, making *sense* of that structure in that encoding.  And yet, it
may seem too low-level.

But are you a sloshing pile of molecules and energy, or are you a *human
being*, damnit?

You are both.

But the human being is emergent behavior which we have *named*,
constructed from a pile of properties of mere sloshing molecules,
energy, physics.

Looking on the level of molecules sloshing in a physics structure, it is
hard to think about how to construct a narrative.  zcap-ld actually does
a pretty good job of hitting an in-between: it has actually quite a good
deal of narrative than most.  I think that narrative at the introduction
of the document is pretty damn good with the car and all that!

I think that's why there's temptation to say: so let's just combine it
with our retrospective-narrative-structure-system, a world of claims and
out-of-band things that can't be checked in the system (like "hey, don't
violate my privacy!") and all that.

There's a way to encode "don't violate my privacy" into zcap-ld, *with*
VCs: add an arbitrated-revocation-caveat that can be flipped by an
arbitrator, linked to a VC that the arbitrator (knowing things about the
outside world), can read, make a judgement on, and flip, revoking the
capability.

Horray, the duals have found out how to work together!

But that doesn't mean squish them together.


> On Sun, Dec 6, 2020 at 3:04 PM Alan Karp <alanhkarp@gmail.com> wrote:
>
>> Stephen Curran <swcurran@cloudcompass.ca> wrote:
>>
>>>
>>> For OCAPS, is a simple assertion sufficient to convey the capability for
>>> a functioning system, or does it matter to whom the capability was given?
>>>
>>>
>> It does not matter to whom the capability was given.  You can (and should)
>> create a one-off key pair for every capability.  You can include an
>> identity for audit purposes, but it may not be meaningful to anyone else.
>> For example, my company may include my employee id in the capability that I
>> use for another company's service.
>>
>> The danger of including an identity in the capability is that it will be
>> used as part of making the access decision, which can lead to a confused
>> deputy vulnerability.  There are also times when you don't know the
>> identity of who is getting the capability.  Perhaps it was given in
>> exchange for money.
>>
>>>
>>> I've always assumed that it is important that a capability being used is
>>> done so by the party to whom the capability was given, or there is a chain
>>> from a delegate to the initial receiving party.
>>>
>>>
>> You can never know who used the capability, but you can know who to hold
>> responsible for its use.  The same applies to ACL systems.  The reason is
>> credential sharing.  In an ACL system, the only way to delegate is to share
>> your password.  (As dangerous as it is, people do it if that's the only way
>> they can get their jobs done.)  In a certificate-based capability system,
>> you can share capability and the private key needed to use it.  That's why
>> "do not delegate" as appears in SPKI is worse than useless.  You gain no
>> security, and you lose responsibility tracking.
>>
>> --------------
>> Alan Karp
>>
>>>

Received on Monday, 7 December 2020 16:38:31 UTC