Re: VCs - zCaps / OCap a Discussion

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:
>
>
>     No, they have to be signed to be verifiable.
>
> 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.


> It's more like what they call proof of possession.


Pop is signing something with your key that is in the credential. In the 
VC world your key would be the subjectIdentifier (or indirectly related 
to it). But then its not a bearer credential.


> The OAuth definition is closer to "bearer bonds,"


this is the same for VCs


> in which possession of the item itself is sufficient.  I prefer to say 
> that the pair (private key, certificate) is the bearer credential in 
> this case.

And its not really a private key if you are passing it from person to 
person.


>     > 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.
>
> No being required and not being specified are two different things.  I 
> have no problem with not making revocation mandatory, but I'd like to 
> have a standard way to do it.


I dont think the group has reached consensus yet on which revocation 
mechanism is the best one to use for VCs.

> Unfortunately, the mechanism for claims such as "over 18" would be 
> quite different from that for an ocap.


I dont know enough about ZKPs to know how revocation is performed in 
this case.


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

Kind regards

David

>
>     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.
>
>
> It rings a bell, but at my age I have trouble remembering what I did 
> last week.  I checked my gmail history, and nothing showed up.  That 
> discussion must have taken place when I still worked for HP.
>
>
>     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
>
>
> --------------
> Alan Karp

Received on Monday, 7 December 2020 21:50:36 UTC