Re: VCs - zCaps / OCap a Discussion

Unfortunately Alan you are wrong in some of your assumptions

On 07/12/2020 17:49, Alan Karp wrote:
> David Chadwick <D.W.Chadwick@kent.ac.uk 
> <mailto:D.W.Chadwick@kent.ac.uk>> wrote:
>
>     Hi Alan
>
>     we are using VCs for one thing only: authorisation.
>
>     Now it depends upon how fine grained you want to go. Do you want
>     to use
>     the same construct for all authorisations, or different constructs
>     for
>     each individual type and instance of authorisation?
>
>
> There is a big difference in the way authorization is used with VCs 
> and with ocaps. With VCs,
>
>   * 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.


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

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

There is only a requirement that the verifier trusts the issuer. 
Trusting yourself is easy.

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


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


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

Kind regards

David

>
> --------------
> Alan Karp

Received on Monday, 7 December 2020 18:20:24 UTC