Re: VCs - zCaps / OCap a Discussion

David Chadwick <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.  It's more like what they call proof of possession.  The OAuth
definition is closer to "bearer bonds," 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.

>

> 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.  Unfortunately, the mechanism for claims such as
"over 18" would be quite different from that for an ocap.

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

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