Re: VCs - zCaps / OCap a Discussion

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