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

I believe your verifier is actually more complicated than zcap-ld because
you have to evaluate the policy on every request.  I don't know what kind
of policies you're dealing with, but the kind I saw at HP and the US Navy
were surprisingly complex.  Even with all that complexity, those policies
were unforgivingly restrictive, which can lead to some surprising
vulnerabilities <https://www.hpl.hp.com/techreports/2008/HPL-2008-204R1.pdf>
.

--------------
Alan Karp


On Mon, Sep 18, 2023 at 7:36 AM Nikos Fotiou <fotiou@aueb.gr> wrote:

> Hi,
>
> We avoided zcap because we wanted to keep our verifier simple. Now, our VC
> verifier just validates the VCs (signature, revocation status, etc),
> extracts the claims and "feeds" them to a policy decision point (which is
> an instance of openfga--https://openfga.dev/ ) The verifier is oblivious
> to "relationships", "delegations" and anything else related to the access
> control mechanism.
>
>
> Best,
>
> Nikos
>
> Στις 2023-09-18 16:59, Alen Horvat έγραψε:
>
> 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
>
>
>