Re: VCs - zCaps / OCap a Discussion

Chris

unfortunately you are making the same mistake that many identity experts 
continually make, and that is to confuse identifiers with identity and 
to equate them. They are different, and you should be clear about which 
you are referring to rather than using the term identity to refer to both.

I will point out your mistake below

On 07/12/2020 16:37, Christopher Lemmer Webber wrote:
> 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

No. It might be a different identifier every time (i.e. subjectID), but 
it will be the same identity every time.

Users can generate fresh key pairs and DIDs whenever they wish.

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

the claims are the same each time. The identities do persist. But the 
identifiers they are linked to may be different each time.

Kind regards

David

>   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:59:51 UTC