- From: Alan Karp <alanhkarp@gmail.com>
- Date: Mon, 7 Dec 2020 09:49:36 -0800
- To: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Cc: public-credentials@w3.org
- Message-ID: <CANpA1Z1LN3BkqGoTb+Ai8D_tWE0eS8=JGB2jgut4=zsHjYPxkA@mail.gmail.com>
David Chadwick <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 claim must be associated with an identifier in order to be useful. (The owner of this DID is over 18.) - The verifiers are not known at the time the VC is constructed. (Revocation is hard.) With ocaps, - The issuer need only be known to itself. (Loop, in Sam's terminology.) - The claim need only be associated with a key pair. (Any holder of this private key may exercise these rights.) - The issuer of the root ocap is the verifier. (Revocation is easy.) 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. -------------- Alan Karp
Received on Monday, 7 December 2020 17:49:59 UTC