Attenuate delegation rights

Context

For ActivityPods, we need Data Grants to have a limit in their delegation. I will implement this in the coming weeks.

We had a long discussion about this with @elf-pavlik, @niko-ng, @Laurin-W here: https://github.com/activitypods/activitypods/issues/386

For delegation to work, we will also need https://github.com/solid/data-interoperability-panel/issues/328

Proposal

My proposal would be to add these two predicates to the interop:DataGrant class:

• interop:delegationLimit: Integer with the number of times the data grant can be delegated
  • If zero, it means the data grant cannot be delegated
  • If not specified, it means there is no limit to the amount of time the Data Grant can be delegated
• interop:delegableMode: The ACL modes that can be delegated
  • It cannot include other modes than those specified in interop:accessMode
  • If interop:delegationLimit is 0, it should not be specified (it will not be taken into account)

Note that this would not be taken into account for applications (in the case a resource is shared with me, and I want to grant the application access to this resource)

Example

Bob gives Alice read/write access to his projects + the right to delegate the read access to one level:

bob:b2b6a645
  a interop:DataGrant ;
  interop:dataOwner bob: ;
  interop:grantee alice:\#id ;
  interop:registeredShapeTree pm-shapetrees:ProjectTree ;
  interop:hasDataRegistration bob-work-data:08a99a10\/ ;
  interop:accessMode acl:Read, acl:Create ;
  interop:creatorAccessMode acl:Update, acl:Delete ;
  interop:scopeOfGrant interop:AllFromRegistry ;
  interop:delegationLimit 1 ;
  interop:delegableMode acl:Read .

If Alice then share Bob's projects with Craig, the Delegated Data Grant will look like this:

alice:b2b6a645
  a interop:DataGrant ;
  interop:dataOwner bob: ;
  interop:grantee craig:\#id ;
  interop:registeredShapeTree pm-shapetrees:ProjectTree ;
  interop:hasDataRegistration bob-work-data:08a99a10\/ ;
  interop:accessMode acl:Read ;
  interop:creatorAccessMode acl:Update, acl:Delete ; # Not sure how to handle this predicate (see below)
  interop:scopeOfGrant interop:AllFromRegistry ;
  interop:delegationLimit 0 .

Craig thus cannot delegate the projects to someone else.

Open questions

• Would it be more clear to also have a interop:delegationAllowed boolean ?
• Would interop:delegationLevel state more clearly that this is not about the number of Delegated Data Grants that can be created, but rather if Delegated Data Grants can themselves generate new Delegated Data Grants ?
• How should the interop:creatorAccessMode predicate be taken into account irw interop:delegableMode ? Since we haven't implemented yet this, I'm not sure how it works.

Once we agree on these details, I can propose a PR.

Start by reviewing the discussion in issue 386 and the related data-interoperability-panel issue 328, then examine the proposed delegationLimit and delegableMode predicates and the open questions about creatorAccessMode and naming. Done means the delegation semantics and predicate details are agreed, after which a PR can be proposed.