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

Re: VCs - zCaps / OCap a Discussion

From: Alan Karp <alanhkarp@gmail.com>
Date: Tue, 22 Dec 2020 13:54:27 -0800
Message-ID: <CANpA1Z2z79CjLWT712T3jVL10T3Lkp-uD_pFwQKbmumigE8ytw@mail.gmail.com>
To: Orie Steele <orie@transmute.industries>
Cc: Daniel Hardman <daniel.hardman@evernym.com>, Adrian Gropper <agropper@healthurl.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
> I made some updates to this strawman proposal for using the VC Data Model
to describe capabilities, capabilities chains, delegation and invocation:
> https://transmute-industries.github.io/authorization-credentials/

I've only started working through your note, but I stopped because I got

I thought every certificate had a unique identifier, but I didn't see it.
Nor did I see the signatures, which becomes particularly important for
invocations.  (The Navy signed the capability and request separately in
their first implementation based on our Zebra Copy
<https://www.hpl.hp.com/techreports/2007/HPL-2007-105.html> work.)

In example 2, how does the verifier know that the delegation is a subset of
the delegator's permissions.  In both SPKI and the SAML version we built,
the proof field contains the deletator's capability certificate.

In example 3, where is the actual read request?

The issuer and the credential subjects are the same key.  That's not a
problem, but I think the example would be more useful if the delegation was
to a different key.

Alan Karp
Received on Tuesday, 22 December 2020 21:54:51 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 22 December 2020 21:54:53 UTC