Re: VCs - zCaps / OCap a Discussion

On 07/12/2020 19:11, Alan Karp wrote:
> David Chadwick <D.W.Chadwick@kent.ac.uk 
> <mailto: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?


No, they have to be signed to be verifiable.


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


only a generic way of specifying what revocation mechanism is being 
used. No specific revocation mechanism is standardised. No revocation 
mechanism is required.


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

And what if two superiors delegated the same permission, or sets of 
permissions that intersect?

The delegation and revocation issues are indeed complex and have nothing 
to do with the VC/ocap debate as the complexity exists regardless of the 
encoding mechanism of the tokens. There are no right answers to these 
dilemmas. We already implemented delegation and revocation with X.509 
ACs in our PERMIS infrastructure a decade ago. I had discussions with 
you way back then about capabilities and attribute certificates if you 
remember.

Kind regards

David

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

Received on Monday, 7 December 2020 21:14:11 UTC