authorization-panel
authorization-panel copied to clipboard
ODRL in Solid
I'm keeping coming back to the ODRL Information Model: https://www.w3.org/TR/odrl-model/ .
I'm logging this so that we can evaluate ODRL's fit for Solid. Or something pertaining to policies.
This is an important piece of the ecosystem puzzle as we go forward.
It'd be ideal to coordinate with the Data Interoperability Panel: https://github.com/solid/data-interoperability-panel/
See also:
- https://github.com/solid/data-interoperability-panel/issues/31
- https://www.w3.org/TR/odrl-vocab/
- https://www.w3.org/ns/odrl/2/
- https://github.com/solid/specification/issues/151
- https://github.com/solid/authorization-panel/issues/50
This looks good. We probably would still need to invent some way to denote things like "all resources including this shape". Perhaps that could be an extension of an asset collection.
CC @Mitzi-Laszlo
This looks good. We probably would still need to invent some way to denote things like "all resources including this shape". Perhaps that could be an extension of an asset collection.
something along the lines of this?
<http://alice.pod/policy:88>
a odrl:Policy ;
odrl:permission [
odrl:target [
a odrl:AssetCollection ;
odrl:source <http://alice.pod/share/photoAnnotations/> ;
odrl:refinement [
a sh:NodeShape ;
sh:pattern "public" ;
sh:flags "i" .
]
]
odrl:action acl:Read;
] .
ODRL Constraints would be replaced with SHACL shapes where all focus nodes passing the refinement node shape would serve as target to the permission.
Of relevance is work by @besteves4 @vroddon and mysel - where the ODRL policy is used to express preferences for sharing categories of data for specific purposes. Example:
:policy-1 a odrl:Policy ;
odrl:profile oac: ;
odrl:permission [
a odrl:Permission ;
odrl:assigner :anne ;
odrl:target oac:Contact ;
odrl:action oac:Read ;
odrl:constraint [
odrl:leftOperand oac:Purpose ;
odrl:operator odrl:isA ;
odrl:rightOperand
dpv:ResearchAndDevelopment ] ] .
:anne a oac:DataSubject ;
cert:key <https://anne.databox.me/profile/card#me> .
- paper: https://hdl.handle.net/2262/96757
- profile: https://w3id.org/oac/
- website with interactive demo of policy authorisation: https://protect.oeg.fi.upm.es/solid-consent/#examples
How does ODRL fit with/compete with gConsent? gConsent has a concept of what purpose the information or access is going to be used for, which I think is important.
GConsent (and others like DPV) can complement ODRL to express legal concepts of Purpose
and Processing
(e.g. EU/GDPR). ODRL's Action
concept tells what is the operation, but not why it needs to happen (as you point out). To have ODRL express the purpose of action, possibilities are:
- Combine
Processing
andPurpose
together into anAction
. e.g. Collect for Service Provision whereCollect
is processing operation andService Provision
is the purpose (missing item is data i.e.Collect <data> for ....
which is anAsset
in ODRL) - Consider
Processing
to be same/similar asAction
and expressPurpose
as part of a restriction on where that action can be applied. This is the approach taken in my earlier comment - Create a new concept to integrate
Purpose
in an ODRL rule or profile. Example is of this is in ODRL policy modelling and compliance checking by Vos et al. https://doi.org/10.1007/978-3-030-31095-0_3 ODRL example: https://github.com/instsuite/instsuite.github.io/blob/master/gdpr.ial
<http://example.com/policy:01> a orcp:Set ;
odrl:profile <http://example.com/odrl:profile:regulatory-compliance> .
orcp:request [
odrl:action orcp:Processing ;
orcp:resource orcp:PersonalData ;
orcp:controller <http://example.com/CompanyA> ;
orcp:purpose orcp:KYC ;
orcp:location orcp:EU ;
orcp:legalBasis orcp:Consent ;
odrl:responsibleParty orcp:Controller
] ;