search

solid / data-interoperability-panel

Repository for the Solid Data Interoperability Panel
MIT License
51 stars 19 forks source link

Support longer delegation chains #222

Open elf-pavlik opened 2 years ago

elf-pavlik commented 2 years ago

Screen Shot 2021-12-15 at 14 16 46

To keep #187 focused on Trusted Grants/Consents I will focus on delegation chains here. Currently, we only use delegation where end-user delegates access to data someone else owns, to applications they want to use to exercise that access. Currently, we still do not clarify how storage hosting the data gets hold of and verifies the validity of that delegated grant!

Longer delegation chains will allow social agents to delegate to other social agents. This will also not require the usage of access modes like acl:Control.

Delegated Data Grant would still apply here. We pretty much only need to specify the mechanism to register delegation upstream. I will propose one of the possible approaches but we should evaluate other approaches as they get proposed.

Each Data Grant and Delegated Data Grant would get a dedicated resource to capture its downstream delegation chain. For example given snippet:

auth-omni-acme-reg:40d038ea
  a interop:DataGrant ;
  interop:dataOwner omni:\#corp ;
  interop:grantee acme:\#corp ;
  interop:registeredShapeTree pm-shapetrees:ProjectTree ;
  interop:hasDataRegistration omni-na-data:8501f084\/ ;
  interop:accessMode acl:Read, acl:Create ;
  interop:creatorAccessMode acl:Update, acl:Delete ;
  interop:scopeOfGrant interop:AllFromRegistry ;
  interop:hasDelegationChainIn auth-omni-acme-reg:e401fa27 .

Notice last statement interop:hasDelegationChainIn auth-omni-acme-reg:e401fa27 . Grantee's authorization agent would have access to that resource and use it to reference all the downstream delegations.

# auth-omni-acme-reg:e401fa27
auth-acme-kim-reg:c22bdf79
  interop:delegationOfGrant auth-omni-acme-reg:40d038ea .
auth-kim-projectron-reg:c4636092
  interop:delegationOfGrant auth-acme-kim-reg:c22bdf79 .

ACME's authorization agent would add the first statement when the Delegated Data Grant gets generated

auth-acme-kim-reg:c22bdf79
  a interop:DelegatedDataGrant ;
  interop:dataOwner omni:\#corp ;
  interop:grantee kim:\#corp ;
  interop:registeredShapeTree pm-shapetrees:ProjectTree ;
  interop:hasDataRegistration omni-na-data:8501f084\/ ;
  interop:accessMode acl:Read, acl:Create ;
  interop:creatorAccessMode acl:Update, acl:Delete ;
  interop:scopeOfGrant interop:AllFromRegistry ;
  interop:delegationOfGrant auth-omni-acme-reg:40d038ea ;
  interop:hasDelegationChainIn auth-acme-kim-reg:93d6ab0d .

And the second one once Kim's authorization agent registers the delegation made by Kim:

# auth-acme-kim-reg:93d6ab0d
auth-kim-projectron-reg:c4636092
  interop:delegationOfGrant auth-acme-kim-reg:c22bdf79 .

In other words, each Delegated Data Grant keeps track of the downstream part of the chain.

This approach would also require that data owner gets access to every Delegated Data Grant in the chain. So Omni's authorization agent based on auth-omni-acme-reg:e401fa27 can fetch and cache all the Delegated Data Grants.