What are mechanisms to enforce policy on the client side?

[MikhailGordienk]

It looks like policy evaluation is currently done on the provider side and performed by checking JWT token claims against stored policy (please correct me if I am wrong here).
Could you please provide an example of such JWT tokens and an example of their evaluation against the corresponding policy?

What are mechanisms to enforce policy on the client side (ex. delete the data after some period)?

Is there a way to enforce the "One up, one down" case, to ensure that different consumers access different subsets of data?

[jimmarino]

Hi,

Policy evaluation can also be done on the client side...it's just that it hasn't been implemented yet.

The JWT structure is just a standard JWT with the added constraint that claims should be key-value string pairs (no complex type values). The specific claims that are passed in the JWT are implementation-specific.

For examples of policy evaluation, please see the test cases and usage of the PolicyEvaluator class.

The mechanisms to enforce policy will be implementation-specific. For example, a policy could potentially be transformed to REGO, cloud infrastructure configuration (e.g. access controls on data), etc. The idea is that once policy is received on the client, it can be transformed/converted based on the execution environment.

Regarding "one up, one down", you'll need to be more specific. What type of data is being transferred, and where is it stored? What identifiers are being used to determine consumers, and how are they resolved in the dataspace?

[MikhailGordienk]

Hello! Thanks for the feedback.

I believe for the "one up, one down" case a data type is not important. It might be just a file.
On the Provider side evaluation is done based on policy, token, and connector IDs. Consider a scenario when I have
a bunch of files comprising some sort of data tree and three different consumers want to access that files.
I want to be able to serve specific files (subset) to specific consumers. As I see it now, to get information
about a consumer, I need to look at the connector's ID or inside the token for some specific claims that all sides have agreed on.

Also, there should be some AgreementStorage where providers can store information about what to serve to each consumer.
The question is - is this AgreementStorage also implementation-specific or will be covered by the core connector specification?

Regarding client-side policy validation. Considering the spatial constraint examples. If a data transfer has been made and the data is already in the consumer's storage I see no mechanisms to prevent potential policy violations other than having all data interactions performed via the connector. I mean that I could access my S3 bucket I have downloaded resources to without using the connector and read the file from anywhere and as many times as I want.

[jimmarino]

Hello! Thanks for the feedback.

I believe for the "one up, one down" case a data type is not important. It might be just a file.
On the Provider side evaluation is done based on policy, token, and connector IDs. Consider a scenario when I have
a bunch of files comprising some sort of data tree and three different consumers want to access that files.
I want to be able to serve specific files (subset) to specific consumers. As I see it now, to get information
about a consumer, I need to look at the connector's ID or inside the token for some specific claims that all sides have agreed on.

Yes, you would need to look inside the token for a verifiable credential and map that to an identity.

Also, there should be some AgreementStorage where providers can store information about what to serve to each consumer.
The question is - is this AgreementStorage also implementation-specific or will be covered by the core connector specification?

Each connector will have access to a set of assets it shares via an AssetIndex (work in progress). Each asset will be associated with a set of policies that can be used to determine access rights. Those access rights can be mapped to an identity resolved through the JWT. This should be sufficient.

Regarding client-side policy validation. Considering the spatial constraint examples. If a data transfer has been made and the data is already in the consumer's storage I see no mechanisms to prevent potential policy violations other than having all data interactions performed via the connector. I mean that I could access my S3 bucket I have downloaded resources to without using the connector and read the file from anywhere and as many times as I want.

There are ways of constraining access. For example, object storage can be restricted to a particular private network, which can be geographically bound. The design of the connector is to have the policy engine capable of transforming or mapping usage policy to these types of configured resources during the provisioning phase.

I would argue this type of approach is likely to be more "secure" than requiring all data access to go through the connector. For example, the connector is likely going to have to persist data somewhere, introducing a potential backdoor.

Stepping back, I would also say that it's nearly impossible to "absolutely" guarantee enforcement of usage policy. The key thing is reasonable steps are in place to help enforce that policy and there is an audit trail..all things the connector provides.

[MikhailGordienk]

Oh, I think I see now. This is where resource management comes into play. The consumer-side storage might also be provisioned dynamically according to the policy configured for the requested resource. And, in general, storage is not necessarily something that consumers or providers have full control over (ex. it might be separate geospatial-aware storage that a consumer will be allowed to access only from certain areas). Right?

[jimmarino]

Yep, that's it!