Re: Verifiable Credentials and (relationship-based) access control

Hi, Nikos.

In this exact case we used the approach where company put the device-owner issued VC in the vc.evidence; Namely: company issued VC has been issued based on the device owner VC.

If information is signer-related, we use the design of JAdES, where signer credentials are in the signed header (either referenced or embedded).

However, we were recommended to use https://w3c-ccg.github.io/zcap-spec/ instead. Zcaps have better terminology, but we didn’t finish the new analysis/design, yet.

BR, Alen

> On 18 Sep 2023, at 15:32, Nikos Fotiou <fotiou@aueb.gr> wrote:
> 
> Hi,
> There has been some discussions about the (un)suitability of VCs for implementing access control. I would like to share with you our experience with a recent project where we implemented access control for digital twins.  You can find a high level description of what we have done here https://medium.com/@excid/relation-based-access-control-using-verifiable-credentials-d8e542a0ce1
> 
> We used a type of access control known as relationship-based access control, also used by Google (https://research.google/pubs/pub48190/). This paradigm has two properties that make it suitable for use with VCs: 
> 
> A) Objects of access control are explicitly defined (e.g., "Company A has "can access" relationship with Device A)
> B) Delegations can be defined as part of the authorization model (e.g., An "employee of a company" can access a device, is she has "authorized" relationship with the company and the company has "can access" relationship with the device.
> 
> So in our system we created a new type of VC that includes "the relationships that the subject id has with objects".
> 
> One of the challenges we faced was related to the discussion that Oliver Terbu raised some time ago and it was about validating verifiable presentations.  Imagine that Alice creates a VP that includes two VCs, one issued by the device owner to Company A assigning it the "can access" relationship (with Device A), and another issued by Company A to Alice, assigning her the "authorized" relationship (with Company A): the signature of the VP should be validated using  the public key that corresponds to the subject id of the latter VC (i.e., Alice). Nevertheless, AFAIU, there is no way to "signal" that to verifier even though this is a typical "chain of trust". We created an ad-hoc solution, but we wish there as there something more generic and interoperable.
> 
> I would love to hear your feedback.
> 
> Best,
> Nikos
> 
>