Re: Concept of schematic checks for hierarchical VC's

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