Skip to content

Latest commit

 

History

History
370 lines (267 loc) · 14.7 KB

2021-04-28.md

File metadata and controls

370 lines (267 loc) · 14.7 KB
Raw

2021-04-28 Solid Authorization

Agenda

  • Minutes #207
  • Cleanup minutes: standard filename and extension #208
  • Add issue template #205
  • Commit PR 201?
  • AnyOf, AllOf, etc...

Present

  • Justin Bingham
  • Eric Prud'hommeaux
  • Henry Story
  • Matthieu Bosquet
  • Sarven Capadisli

Minutes

  1. Commited Meeting Cleanups
  2. Appropve minutes from 207 without the ACP code discused in the last few minutes in the last call
  3. Elf Accept changed and then Commit on PR 205
  4. Merged 201

ACP apply policy algorithm

Henry: Last week, we discussed a PR I made to the wac-acp-diff story which we just committed. We looked at how the ACL ontology allows a behavior similar to ACP by creating an inferred :authorizes relation defined as:

acl:accessTo owl:inverseOf [
        owl:propertyChainAxiom ( acl:accessControl :authorizes )
      ] .

(note: for an interesting discussion on this rule see also the discussion on the PR for the meeting notes)

This relation, which is already implicit in ACL, as it can be defined purely in terms of those concepts, allows one to get similar behavior to the one put forward as a distinguishing feature of ACP.

We then looked at the ShEx examples and showed that with a very simple inferencing step -- adding one triple to the graph after following an :accessControl Link header relation -- one could even apply that WAC ShEx to that graph and get clients written to the old ACL ontology to continue working.

But the question then was what do the allOf, anyOf, noneOf and apply* relations bring to the picture. How do they work?

We were about to start on that when time ran out. We had just pasted this code into the chat.

/**
 * # The apply policy algorithm
 *
 * A policy is applied if:
 * - At least one matcher it uses matches the given context; and
 * - All the conditions it defines are satisfied.
 *
 * Policy conditions behave like intersection, union and exclusion operators. In
 * order to be satisfied:
 * - allOf requires all of its matchers to match the given context;
 * - anyOf requires one of its matchers to match the given context;
 * - noneOf requires none of its matchers to match the given context.
 *
 * Note: Given that the noneOf condition excludes matches, a policy without a
 * satisfied allOf or anyOf condition never applies.
 *
 * @param policy The policy to evaluate
 * @param context The context in which the policy is evaluated
 * @returns True if the policy applies, false otherwise
 */
export function applyPolicy(policy: IPolicy, context: IContext): boolean {
  const matchContext = (matcher: IMatcher) => {
    return matcher.match(context);
  };

  // A policy without positive match doesn't apply
  if (policy.allOf.length + policy.anyOf.length === 0) {
    return false;
  }

  return (
    (policy.allOf.length === 0 || policy.allOf.every(matchContext)) &&
    (policy.anyOf.length === 0 || policy.anyOf.some(matchContext)) &&
    (policy.noneOf.length === 0 || !policy.noneOf.some(matchContext))
  );
}

Henry: before we look at that code, can we look at some simple RDF examples of a policy using that vocabulary?

Matthieu:

Yes, I can write it out here.

prefix ex: <https://example.com/>

ex:PolicyX
    acp:allow acl:Read ; #CSarven comments below
    acp:deny acl:Write ;
    acp:allOf ex:AgentMatcher1, ex:IssuerMatcher1, ex:TimeMatcher1, ex:CredentialIssueTimeMatcher1 .

ex:AgentMatcher1
    acp:agent ex:Bob, ex:Alice .

ex:IssuerMatcher1
    acp:issuer ex:IdP1 .

ex:TimeMatcher1
    acp:time [
    some owl time range e.g. sunday 10am to 2pm
    ]

C Sarven: would only having acp:allow acl:Read imply anything other than Read? Why would acp:deny be necessary?

Matthieu: Allowing read doesn't imply anything else than read. However being able to forbid access following sets of rules could be seen as useful because:

  • You can design Policies that deny certain access following set of conditions that are as intricate as required.
  • You can design standard Policies that deny access and can be widely applied.

To be clear, an access mode is only allowed if at least one policy that applies allows it and none of the policies that apply deny it. Here the Policy X will apply if all the matchers are satisfied in the current context. A context would be the description of a resource access. (note: We have acp:deny which is new compared to WAC.)

So a Policy is what gives access to a resource. With the above Policy applied to the below context, Bob is allowed to read a resource.

ex:ResourceAccess1
    acp:time "2021-04-26T15:30:00Z" ;
    acp:agent ex:Bob ;
    acp:issuer ex:IdP1 ;
    acp:resource ex:MyResource1 .

Henry: Note: it looks like acp:resource is equivalent to acl:accessTo.

Matthieu Note: acp:resource describes which resource is being accessed, above is a context graph describing an instance of resource access. The acl:accessTo would be closer to the inverse of the predicate that links resources to their access controls in ACP, that is, acp:accessControl.

Henry :

So we can get the equivalent of allOf with owl:intersectionOf For example, one can describe EU Citizens over 18 if one has already defined two groups, one the set of Citizens and the other of being over18 as here:

@prefix owl: <http://www.w3.org/2002/07/owl#> .

<#EUOver18> owl:equivalentClass [ 
    owl:intersectionOf ( eu:Citizen iso:Over18 )
].

Matthieu

ACP someOf is the union of the sets described by all matchers.

prefix ex: <https://example.com/>

ex:PolicyY
    acp:allow acl:Read ;
    acp:someOf ex:AgentMatcherFriends1, ex:AgentMatcherFamily1 .

ex:AgentMatcherFriends1
    acp:agent ex:Henry, ex:Jay .

ex:AgentMatcherFamily1
    acp:agent ex:Bob, ex:Alice .

This Policy will apply if you are any of the agents defined by AgentMatcherFriends1 and AgentMatcherFamily1.

Henry

Note that one can get that with owl:unionOf

<#EUOrOver18> owl:equivalentClass [
       owl:unionOf ( eu:Citizen iso:Over18 )
] .

This gives us the set of citizens over18 or those that are European Union Citizens.

The range of acp:allow is a set of agents right?

Matthieu : It is more than that: it can be selecting credentials, issuers and times too.

Access to a resource based on credentials. For example, giving access to those over 18. Note: This example is not normative. There has been no formalisation of verifiable credentials in acp yet. The important point is that acp:attributes that describe an instance of resource access are an extension point of acp. Each attribute corresponding to a specific matching algorithm. Currently, formally defined and in use are the standard attributes for describing agent, client and issuer.

ex:PolicyVC
    acp:allow acl:Read ;
    acp:allOf ex:VCMatcher1 .

ex:VCMatcher1
    rdfs:label "Over 18 VC Matcher" ;
    acp:vc ex:over18 .

Henry: Is it not selecting sets of agents that have certain relations to credential issuers, times, birth dates, capabilities (e.g. the ability to drive) etc...? This is what Description Logic allows one to do: define sets of things by describing their relations to other things? That is: we can get the same effect by using descriptions to constrain the set of agents in the acl:agentClass relation.

Here are a few examples I put together over the past few months in various issues:

From Issue 135: OWL for anyOf, allOf, noneOf? One can model a class minus another, giving us the equivalent of deny perhaps

<#Responsible> owl:equivalentClass [
      owl:intersectionOf  (  iso:Over18  [ owl:complementOf <g0#Trolls> ] ) 
]

In issue 147 I show how one can describe people over 21

<#PersonOver21> owl:equivalentClass [  a owl:Restriction;
      owl:onProperty :hasAge ;
      owl:someValuesFrom   
          [ rdf:type   rdfs:Datatype ;
            owl:onDatatype       xsd:integer ;
            owl:withRestrictions (  [ xsd:minExclusive     21 ]   [ xsd:maxInclusive    150 ] )
          ]
       ].

This example is taken directly from the OWL spec btw. Here again, we describe a set of agents by their relation to some other thing (an age). And in issue 176: Only Trust Certain issuers of Identity I put together an example that creates a subclass of agents, restricted to those that have credentials issued by certain trusted issuers:

<verified#agents>  rdf:type    owl:Class ;
   owl:equivalentClass  [
     rdf:type           owl:Restriction ;
     owl:onProperty     wac:hasCredentialIssuer ;
     owl:someValuesFrom  <trusted#issuers> .
   ] .

So we only need a relation of a Policy or Access control Rule to a set of agents. We can then specify what that set of agents is.

<> :authorizes [
    a               acl:Authorization;
    acl:agentClass  </grps/verified#agents>;   # Authenticated Agents from verified issuers
    acl:mode           acl:Read, acl:Write             # has Read/Write access to the collection
].

This gives us the same properties as allOf, anyOf, noneOf relations it seems. Perhaps then allOf, anyOf, noneOf can be mapped to OWL. Writing up such a mapping would allow us to leverage well-known, widely researched and deployed standards in what we are doing.

So we see that we can certainly both define the restrictions on the set of agents using ACL or extensions thereof (in the ACP namespace, why not?).

Flow from Resource to Policy

But there are a few other relations I have been wondering about. Perhaps we can go back to the beginning so that I can make sure I follow the path from the access-controlled resource.

Matthieu

Certainly, we can start with the relation from LDPR to the Access control resource with the following relation, via the header:

<mydoc> acp:accessControl <mydoc.acp#> .

The ACR doc contains a policy X mandating access over the resource controlled by <#>.

<#> acp:apply ex:PolicyX .

Henry: this looks very much like :authorizes relation defined in issue 184 which we discussed last week.

The apply name is not very clear, perhaps because it is so general. (In functional programming and Category Theory it is used for all applications of arguments to a function). I found this makes its role difficult to understand. That explains perhaps why I could not work out how it fits into wac-acp diff. So I find it helps to see that it is playing the role of acp:authorizes. I had not understood that.

But there is also another set of relations named access* if I remember correctly. Why do we need all of those?

Matthieu:

This is useful when the ACR doc contains another policy Y mandating access over itself (<>).

<#>
    acp:access ex:PolicyY .
    acp:applyProtected ex:ProtectedAccessControl1 .

Henry:

So that is specifying what rights we have to access the ACR itself? Why not reuse the same acp:accessControl mentioned at the beginning?

Matthieu: Indeed acp:access is very similar to that. But it helps avoid infinite recursion in cases like this:

ex:resource1 acp:access ex:acr1 .
ex:acr1 acp:access ex:acr2 .
ex:acr2 acp:access ex:acr3 .

Henry: I am not sure that actually is a problem. It would need to be argued for carefully. I have not found there to be a problem when a resource claims to be its own ACR. (And recursion is not problematic if it has a fixed point. Functional programming relies on that.)

There is a fundamental distinction in philosophy between Epistemology (what you know) versus ontology (how things are) that can help us here. We can see the ACL ontology as telling us that every resource on the web has access control rules. And indeed, they do: most web pages cannot be written to by just anyone. Even places like Wikipedia that allow wide-open contributions can limit access. So if I had full knowledge of the access control state of a website, I could write out a document describing all resources there and who had access. So we can think of those statements as not being published at present, but as potentially publishable. Indeed those statements are written somewhere: in some binary or textual form, Apache config files, databases, XML documents, ... and could be given an RDF representation. All publishing the ACRs is doing is allowing a client to "know" what the rules of access are (epistemology). At present browsers don't have access to the policies, and humans have to work those out by reading text and filling in forms.

In short: there is no difference ontologically that one can make between ACRs and other resources -- all resources have access control rules, even access control rule resources.

So, in that case, why build up a new type of relation, when we already have what we need? It seems furthermore that this complicates things: instead of 1 acp:accessControl relation you now have 4 or so more.

Discussion on Resource restrictions

Henry

I was wondering how in ACP one restricts policies to sets of resources? If I remember correctly, EricP had a use case for the transitive closure of resources he needed for a health care example.

EricP

Diagnosis > Conditions > Observations

Access inheritance via specific paths.

Condition 456 -> Observation 789 ->

Henry: How do you describe sets of resources that have a set of properties in addition to describing agents that have sets of properties? And how do you describe the relationships between those?

Sarven: How does the shapetree work through HTTP resources where the target of a request is a resource. It is a document with a body... How does shapetree work in context of a resource targeted?

The chain of how information is preserved (host a medical image XRay is an ldp resource is this shapetree the shapetree has resources to other resources)

Actions

  • Elf to Accept suggestions and commit PR 205 - done