W3C home > Mailing lists > Public > public-credentials@w3.org > December 2020

Re: VCs - zCaps / OCap a Discussion

From: Alan Karp <alanhkarp@gmail.com>
Date: Mon, 7 Dec 2020 14:22:26 -0800
Message-ID: <CANpA1Z2xzNhM=FKa92G33-CnSe1wFGU0+WpcNJUeZPj_Wt5tQQ@mail.gmail.com>
To: David Chadwick <D.W.Chadwick@kent.ac.uk>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
David Chadwick <D.W.Chadwick@kent.ac.uk> wrote:

> On 07/12/2020 21:31, Alan Karp wrote:
> > David Chadwick <D.W.Chadwick@kent.ac.uk
> > <mailto:D.W.Chadwick@kent.ac.uk>> wrote:
> >
> > That's a very different definition of "bearer credential" than used in
> > OAuth.
> No its the same I believe, the credential has to be signed by the
> issuer, not the holder. I think we got crossed wires here.
> Yes we did.

> I dont think the group has reached consensus yet on which revocation
> mechanism is the best one to use for VCs.
> If the verifier(s) are known as with ocaps, you can just tell them not to
honor the claim.  If the verifiers are not known, you need something like
CRLs or a site to check for revocation.

Here's a crazy idea that only covers part of the VC space.  Let's say I own
a DID, and I attach a claim from you to it.  Is it possible to allow you to
attach a claim to that claim, perhaps revoking it?  I know that updating
someone else's DID is a no no, but here you're only updating something you
provided in the first place.

> >
> > Alice delegates a particular permission to Bob.  Carol delegates that
> > same permission to Bob.  They are separate ocaps.  When Bob acts on
> > behalf of Alice, he uses the ocap he got from Alice.  When he acts on
> > behalf of Carol, he uses the ocap he got from Carol.  If Alice revokes
> > the ocap she gave Bob, he can still act on behalf of Carol.  I use
> > this example when explaining the shortcomings of ACL-based systems.
> But you can equally well argue that this is a shortcoming of ocaps. E.g.
> Bob has a permission from his boss, and also the same permission from
> his co-worker friend who got the same permission from their joint boss.
> Bob is sacked and the boss revokes the permission he gave him. His
> friend is not at work that day, so Bob uses his other permission to
> wreak havoc in the company that just fired him. The boss was unaware
> that Bob had the same permission from another delegation.
> As a boss, if I revoked an employee's permission I would want all
> instances of this to be revoked.

You need a different mechanism for that.  The solution is to give Bob an
ocap to use a Bob-agent, which holds all the ocaps that have been delegated
to Bob.  When Bob gets fired you revoke his Bob-agent ocap.  This solution
also works in the case in which the boss gets fired.  If you didn't do
something like this, every delegation the boss made would be revoked, and
nobody would be able to get any work done.

Alan Karp
Received on Monday, 7 December 2020 22:22:51 UTC

This archive was generated by hypermail 2.4.0 : Monday, 7 December 2020 22:22:52 UTC