Re: VCs - zCaps / OCap a Discussion

I can believe that identifiers and identity are different, though I
think they are related.  I am interested in your distinction, though.

Here would be my attempt at an distinction:

 - identifier: a "name" by which we address a thing, whether to route
   to, or to talk about, or identify

 - identity: an identifier which, over time, is continuously referred
   to... or those associations themselves, depending on how you want to
   frame it.  objects in the system develop an idea of information
   associated with the identity.

An identity thus changes over time, it accrues information and changes.
Identifier is more of a routing method.

A quick Google search seems to suggest much the same.

In that case, I would think both ocaps/zcaps and VCs must grapple with
identifiers to some degree, but VCs are the land of identity-assertions.

Do you think differently?  And whether we share the same understanding,
how does this result in a misunderstanding here?


David Chadwick writes:

> 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 19:24:56 UTC