search

solid / authorization-panel

Github repository for the Solid Authorization Panel
MIT License
19 stars 20 forks source link

ODRL in Solid #55

Open csarven opened 4 years ago

csarven commented 4 years ago

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:

jaxoncreed commented 4 years ago

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.

michielbdejong commented 4 years ago

CC @Mitzi-Laszlo

simonstey commented 4 years ago

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.

coolharsh55 commented 3 years ago

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> .
timbl commented 3 years ago

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.

coolharsh55 commented 3 years ago

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:

  1. Combine Processing and Purpose together into an Action. e.g. Collect for Service Provision where Collect is processing operation and Service Provision is the purpose (missing item is data i.e. Collect <data> for .... which is an Asset in ODRL)
  2. Consider Processing to be same/similar as Action and express Purpose as part of a restriction on where that action can be applied. This is the approach taken in my earlier comment
  3. 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
] ;