Re: Concept of schematic checks for hierarchical VC's

I agree with what Joe said, and I would note that this use case is closer
to the sweet spot for zCaps than for chained credentials, in that it
involves enforcement within the same identity domain where issuance
happened.

Just one thing to add: We need to get much more detailed as a community
about our notions of what "verifying" a credential entails. There are many
possible things that might be done in such a process; a (probably
incomplete) enumeration is being discussed over in our Verifier API work
item (https://github.com/w3c-ccg/vc-verifier-http-api/issues/6).

On Tue, Mar 10, 2020 at 11:02 AM Joe Andrieu <joe@legreq.com> wrote:

> Sebastian,
>
> One approach to your use case is to use zCaps:
> https://w3c-ccg.github.io/zcap-ld/
>
> You would essentially have the gate system issue a delegatable capability
> to the security officer, who in turn delegates it to Mr. Random, who
> presents it to the gate to get it to open.
>
> One thing that's unclear in your example is why doesn't the security
> officer just open the gate directly. I interpreted your scenario as the
> Security Officer is the one who decides who gets to enter the facility,
> which may be separated in time or space from the actual gate entry.
>
> The zCap that is actually invoked to open the gate contains the entire
> delegation chain with the information you are seeking: who issued what to
> whom for what purpose, all the way up to the original issuance.
>
> zCaps simplify the schema check by having the gate specify the action
> directly as something like "open" which only needs to have meaning to the
> gate, although it can be helpful to the security officer and potential Mr.
> Random to have a name that is semantically evident. Technically, however,
> the gate could use its own term for "open", as long as the meaning of that
> term is consistent from the time of issue to invocation.
>
> The one thing that isn't addressed is why the gate would issue the
> Security Officer a delegatable capability to open the gate in the first
> place. One way to do that would be to configure the gate to accept an
> employment VC as evidence for the capability issuance. Alternatively, you
> could bootstrap the gate system such that someone at the firm holds an
> onboarding capability to get the gate to issue the open capability. That
> onboarding capability would be invoked when the Security Officer is hired.
> Or in a fancier architecture, it could be tied to a time-card system that
> issues a capability that is then revoked when the officer goes off the
> clock. However it is set up, there are always bootstrapping that must be
> done to give some party initial control over a root capability.
>
> Separately, Daniel Hardman has advocated an approach of Chained
> Credentials. I believe that might be able to address your requirements as
> well, although the semantics of each credential in the chain would need to
> be formalized.
>
> https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0104-chained-credentials/README.md
>
> He also published an article contrasting his approach with zCaps at
> https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0104-chained-credentials/contrast-zcap-ld.md
>
> -j
>
> On Tue, Mar 10, 2020, at 5:51 AM, Sebastian Dechant wrote:
>
> Hi all,
>
>
>
> we’re facing the challenge that we want to verifiy not 1 to 1 vc’s,
> instead we want to check against a hierarchy of vc’s that have to be
> presented to the proofer of a vc.
>
>
>
> Lets take a example:
>
>
>
> Mr. Random wants to pass a gate to a factory with his car. The security
> officer in front of the gate now issues a vc for mr. randoms did for
> passing the gate.
>
> The VC also contains a "credentialSchema" field to check the data format
> of the issued vc.
>
> When Mr. Random no presents the vc to the gate, the gate has to check
> different things.
>
> 1. The gate checks the proof property of the presented VC
>
> When this check is successful, the basic cryptographic proof matches and
> the vc data is valid
>
> 2. After the proof check, the gate must check if the format defined in
> credentialSchema is valid
>
> When this check is successful, the data integrity of the vc is valid and
> well-formed
>
> 3. After the schema check, the gate must check if the security officer is
> allowed to issue this kind of vc
>
> In this enterprise scenario the gate also wants to check if the issuer of
> the vc to open the gate, has the permissions to issue this kind of vc and
> the gate opens or not.
>
>
>
>
>
>
>
> The third points belongs to my question. Is there any formal definition
> (like JSON) of checking against a whole hierarchical set of vcs? Our
> approach would be:
>
>
>
> The gate in the example above has the did id from the employer of the
> security officer hard coded in his source code for checking the validity of
> vcs. Now when the security officer creates a vc for the driver, he also
> attaches an “evidence” vc or vp of his employer.
>
>
>
> With this VC the gate can now check and prove the hierarchy "gateOpenVC"
> ----issuedBy----> "securityOfficerGateVC" ----issuedBy----> employerDid.
> And because the securityOfficerGateVC is valid and not revoked, the gate
> will open because the issuer did matches the one which has been hardcoded
> in the sourcecode of the gate.
>
>
>
>
>
> And in general is this approach acceptable to the concept of vcs? We’re
> also looking at
> https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0250-rich-schemas
>  but this also looks only like a schema for only one VC.
>
>
>
> Thanks in advance!
>
> Sebastian
>
>
>
>
> --
> Joe Andrieu, PMP
>                    joe@legreq.com
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>