Re: VCs - zCaps / OCap a Discussion

I have to cherry-pick my responses because there's just too much deep
thinking to explore it all. Thanks to everyone who's weighing in.

To Dave L:

>The above does not say "It's an assertion that the bearer is authorized."
as you stated in your earlier email. It says: The subject identified by "
https://roboticlab.cam.ac.uk/~amyt/capstone-project" has the
property "allow" with the value "operate".

Yes. But the reason I get away with the interpretation I asserted is that I
introduced a context that defines what the predicate "allow" and the object
"operate" mean ("https://roboticlab.cam.ac.uk/grants"). This is how the
open world of extensibility is supposed to work, is it not? Didn't we put
extensibility into VCs exactly to enable extension without ambiguity? It
seems inconsistent to argue that my usage of the extension mechanism is
rife with ambiguity whereas your preferred usages are not, when both depend
on the same mechanism.

To Tobias and Dave and Chris, who've all asserted something like this
concise argument from Tobias:

>Instead I think reading the abstract, introduction and what is a VC
section quite clearly outline that a VC is a cryptographically secure
assertion format for communicating identity claims.

Here is a use case that could be expressed with VCs that may help us
explore whether identity is truly at the heart of the spec. Alice is being
deposed by a lawyer about a car accident that happened outside Acme Corp's
headquarters. The lawyer wants her on-the-record statement about what
happened. Alice bundles her statement into a pair of signed RDF triples (a
VC?), as follows:

subject: purported accident outside Acme's headquarters
predicate: what I saw
object: Malfoy entered the intersection after the light turned yellow. He
clipped Bob, whose car spun around and collided with Carol...
predicate: what I heard
object: Malfoy's brakes squealed before any other unusual sounds occurred.


Now, I feel that it's a stretch to view these triples as having much
meaning for identity. Alice's testimony is not being used to establish the
identity of the accident; it's being used to present general assertions by
Alice where the subject of the assertions is the purported accident. So: is
this a valid VC (assuming we have a context that gives a formal name to the
"what I saw" and "what I heard" predicates, and all the other plumbing is
wired up correctly to satisfy the VC data model spec)? Or is it a
perversion of VCs because VCs are only for identity -- in the same way that
making assertions about authorizations is a perversion of VCs? (And if I
keep coming up with use cases for VC-like things that aren't identity
related -- which I can do all day long -- are we going to keep pushing
those out of the legitimate scope of the spec, too, based on tribal
knowledge rather than spec language?)

In my prior example of authorizations to use a student's robot, I used the
word "allow" for the predicate, and the argument was that "allow" doesn't
fit with describing the subject. But what if I change the wording slightly:

subject: Alice's capstone robot project
predicate: is allowed to be used in the following way by the bearer
object: activate "self defense" mode


It feels to me like this is an authorization that is also a clean VC
candidate, and that the objections about interpretation were caused by my
vague word "allows." Do you agree that the new predicate I'm using makes
your objection go away, or is it still there?

Returning to my example about Alice giving testimony, suppose that the
lawyers succeed in getting Alice's visual testimony struck from the record.
We want to do selective disclosure of the VC's "what I heard" attribute
only. Are we going to re-invent selective disclosure for some new mechanism
that's based atop LD-signatures, just so we don't have to pollute VCs with
the idea that they're about something other than identity?






On Mon, Dec 7, 2020 at 12:13 PM Alan Karp <alanhkarp@gmail.com> wrote:

> David Chadwick <D.W.Chadwick@kent.ac.uk> wrote:
>
>> Unfortunately Alan you are wrong in some of your assumptions
>>
>
> You caught me.  I've only done a cursory pass over the documentation.
>
>>
>> >
>> >   * The issuer must be known, often widely known, in order to
>> >     establish trust in the claims.  (State DMV)
>> >
>> The issuer must only be known by the holders and verifier(s) that trust
>> it.
>>
>
> That's what I mean by "known."  State DMV is in the "widely known"
> category.
>
>>
>> >   * The claim must be associated with an identifier in order to be
>> >     useful.  (The owner of this DID is over 18.)
>>
>> Not so. Bearer credentials are specifically mentioned in the standard.
>> e.g. for tickets. There is an entire section on this.
>>
>
> It sounds like bearer credentials don't have to be signed to be used.  Is
> that correct?  At any rate, I'm talking about the use cases I hear people
> talking about most.
>
>> >
>> >   * The verifiers are not known at the time the VC is constructed.
>> >     (Revocation is hard.)
>> >
>> To be precise, the issuer role creates the VC and gives it to the holder
>> role, for it to give to whomever it wants to (the verifier role). If the
>> verifier role and issuer role belong to the same entity, then the VC
>> will flow in a circle.
>>
>> There is no requirement to revoke VCs.
>>
>
> Does the spec include a way to revoke if I want to?  If I'm over 18 now,
> I'll never be younger than that.  However, if I have the right to drive a
> car, I might lose that right in the future.  Waiting until my driver's
> license expires may not be the desired behavior.
>
>>
>> > With ocaps,
>> >
>> >   * The issuer need only be known to itself.  (Loop, in Sam's
>> >     terminology.)
>> >
>> There is nothing in the VC standard which forbids the issuer and
>> verifier being the same entity.
>>
>
> Which is why I mentioned Sam's terminology.
>
>>
>> There is only a requirement that the verifier trusts the issuer.
>> Trusting yourself is easy.
>>
>
> Yes.
>
>>
>> >   * The claim need only be associated with a key pair. (Any holder of
>> >     this private key may exercise these rights.)
>> >
>> There is nothing in the VC standard which prohibits the subjectID from
>> being a key ID. There is even a proposal for did:key which is precisely
>> for this.
>>
>
> Something I didn't know about.
>
>>
>>
>> >   * The issuer of the root ocap is the verifier. (Revocation is easy.)
>> >
>>
>> There is nothing in the VC standard which mandates revocation.
>> Unrevocable VCs are supported (short and long lived). If the verifier
>> role and issuer role belong to the same entity then revocation is simple.
>>
>> Revocation is an important part of ocaps, and the mechanism for
> revocation is important.  For example, if you are in the middle of a
> delegation chain, can you only revoke the delegation you made, or can you
> revoke from any point beyond that?  There are valid arguments on both
> sides.   This example is one of the things that worries me about combining
> VCs and ocaps.
>
>>
>> > While I have no doubt that these two use cases can be implemented with
>> > VCs, the differences make me worry that inconsistencies will
>> > eventually arise.  At that point, the standard will have to choose one
>> > or the other as primary, making the other somewhat awkward to use.
>>
>>
>> On the contrary, the VC standard was designed to be a generic standard
>> for credentials of any type. It is true that many people envisaged that
>> identity credentials would be the most popular and most common usage of
>> VCs in the first instance, but certainly not the only usage. And, as
>> with all standards, the writers can never envisage the innovative ways
>> that creative engineers will use a standard for.
>>
>
> I agree.  I'm just worried about incompatibilities arising from the
> different use cases, such as the revocation example.
>
> --------------
> Alan Karp
>