-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Minutes 2021-04-28 #209
Merged
Merged
Minutes 2021-04-28 #209
Changes from 3 commits
Commits
Show all changes
14 commits
Select commit
Hold shift + click to select a range
fb48602
Minutes 2021-04-28
matthieubosquet 019eb9c
Update 2021-04-28.md
bblfish c6321af
grammatical corrections
bblfish 8b0b427
Update meetings/2021-04-28.md
bblfish 05c9f0d
Update meetings/2021-04-28.md
bblfish a3171e8
Update meetings/2021-04-28.md
bblfish 61731aa
Update meetings/2021-04-28.md
bblfish 5b64215
Update meetings/2021-04-28.md
bblfish 136a2e3
Update meetings/2021-04-28.md
bblfish 53cafab
Update meetings/2021-04-28.md
bblfish 2724448
Update meetings/2021-04-28.md
csarven 36355ae
Update meetings/2021-04-28.md
bblfish c5c48e0
fixed rule invovling :authorizes after discussion
bblfish dfa8ecd
Update meetings/2021-04-28.md
matthieubosquet File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,358 @@ | ||
# 2021-04-28 Solid Authorization | ||
|
||
* [Meeting](https://meet.jit.si/solid-authorization) | ||
* [Chat](https://gitter.im/solid/authorization-panel?at=6088092ac1a9210b3c23a55a) | ||
* [Notes](https://hackmd.io/mFgvpYMZR7Co_DIDgUaNwA) | ||
|
||
## Agenda | ||
|
||
* Minutes https://github.com/solid/authorization-panel/pull/207 | ||
* Cleanup minutes: standard filename and extension https://github.com/solid/authorization-panel/pull/208 | ||
* Add issue template https://github.com/solid/authorization-panel/pull/205 | ||
* Commit [PR 201](https://github.com/solid/authorization-panel/pull/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](https://github.com/solid/authorization-panel/blob/main/proposals/wac-acp-diff-story.md) 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: | ||
|
||
```Turtle | ||
:authorizes owl:inverseOf [ | ||
owl:propertyChainAxiom(:accessControl acl:accessTo) | ||
] | ||
``` | ||
|
||
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 the distinguishing feature of ACP. | ||
bblfish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
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. | ||
|
||
```typescript | ||
/** | ||
* # 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? | ||
|
||
**Mattieu** | ||
bblfish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Yes, I can write it out here. | ||
|
||
```Turtle | ||
prefix ex: <https://example.com/> | ||
|
||
ex:PolicyX | ||
acp:allow acl:Read ; # would only having acp:allow acl:Read imply anything other than Read? Why would acp:deny be necessary? | ||
csarven marked this conversation as resolved.
Show resolved
Hide resolved
|
||
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 | ||
] | ||
``` | ||
|
||
bblfish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
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 context, Bob is allowed to read a resource. | ||
bblfish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
```turtle | ||
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`. | ||
bblfish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
|
||
**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: | ||
|
||
```Turtle | ||
@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. | ||
|
||
```turtle | ||
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` | ||
|
||
```Turtle | ||
<#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. | ||
bblfish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
```turtle | ||
ex:resource | ||
matthieubosquet marked this conversation as resolved.
Show resolved
Hide resolved
matthieubosquet marked this conversation as resolved.
Show resolved
Hide resolved
|
||
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?](https://github.com/solid/authorization-panel/issues/135) | ||
One can model a class minus another, giving us the equivalent of deny perhaps | ||
|
||
```Turtle | ||
<#Responsible> owl:equivalentClass [ | ||
owl:intersectionOf ( iso:Over18 [ owl:complementOf <g0#Trolls> ] ) | ||
] | ||
``` | ||
|
||
In [issue 147](https://github.com/solid/authorization-panel/issues/147#issuecomment-743158893) I show how one can describe people over 21 | ||
|
||
```Turtle | ||
<#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](https://github.com/solid/authorization-panel/issues/176) I put together an example that creates a subclass of agents, restricted to those that have credentials issued by certain trusted issuers: | ||
|
||
```Turtle | ||
<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. | ||
|
||
```Turtle | ||
<> :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: | ||
|
||
```turtle | ||
<mydoc> acp:accessControl <mydoc.acp#> . | ||
``` | ||
|
||
The ACR doc contains a policy X mandating access over the resource controlled by <#>. | ||
|
||
```Turtle | ||
<#> acp:apply ex:PolicyX . | ||
``` | ||
|
||
**Henry**: this looks very much like `:authorizes` relation defined in | ||
[issue 184](https://github.com/solid/authorization-panel/issues/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](https://github.com/solid/authorization-panel/blob/main/proposals/acp/wac-acp-diff.ttl). | ||
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 (<>). | ||
|
||
|
||
```Turtle | ||
<#> | ||
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 case clike this: | ||
bblfish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
```turtle | ||
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 publisheablle. | ||
bblfish marked this conversation as resolved.
Show resolved
Hide resolved
|
||
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](https://github.com/solid/authorization-panel/pull/205) - done |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bblfish I'm not sure you can assert the statement that is part of the object property chain.
If:
SubObjectPropertyOf( ObjectPropertyChain( :hasFather :hasBrother ) :hasUncle ) :x :hasFather :y . :y :hasBrother :z . # Then :x :hasUncle :z .
However, I don't think (and didn't find example of in the OWL 2 syntax of) infering the property chain predicate. And I think it is deliberate (I might be wrong).
Let's imagine for a second that:
So just to confirm, the following axiom is incorrect:
Instead what we're proposing to assert here is the
acl:accessTo
relationship via the following axiom:(which relies on the not yet existing
:authorizes
predicate).Is this correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For those following here, I recommend looking at the OWL 2 Primer §Property Chain section. You can get the Turtle version of each code snippet if you go to the top of the page and click a "Turtle Syntax" button. That will give you the definition for :hasGrandparent in Turtle as:
(It is annoying that one cannot pass that decision around as a URL and I sent a mail to the semantic-web mailing list reporting that.)
We also have the definition given in OWL2 RDF Based Semantics.
I was working with this picture in mind:
But I wrote it out too quickly and got the order of the relations wrong.
But it is still a good question whether even that is correct.
And indeed the following does not look right:
I can follow the
:accessTo
link from<fake.acl>
follow the:accessControl
relation from there and that does not give me the:authorizes
link that givesControl
rights I started off with.So yes, I should go back to the original proposal I made:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The above is a very good example of why we want to build on formally specified languages such as OWL, as it allows one to make precise arguments as @matthieubosquet just made above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I see why the
:authorizes
statement cannot be inferred using that graph and the previous axiom.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand you correctly you have this picture in mind, where I have labelled the nodes.
The mapping from your code is
ex:authorization1
->a1
ex:resource
->r
<fake.acl#authorization2>
->a2
So I was trying to say that with the improved but still rejected rule
we then get (inferred) the red dotted line representing
<card.acl#> :authorizes <fake.acl#a2>
which is not what is desired.That would make it easy to create fake authorizations.
But that no longer follows from the rule originally proposed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Henry, that makes sense. So, to summarize:
acl:accessTo
statement seems safeacl:authorizes
statement is not safe because it introduces a problem in controlling the boundaries of the authorization graph applying to a resource X.Given a set of server managed statements (by that I mean statements that "lawfully" belong in the authorization graph or in other words, assuming that the statements in the form
:x acl:accessTo :y .
are all part of the authorization graph and apply to the resource already), theacl:authorizes
inferrence axiom could be used.Therefore, it seems unlikely the axiom for inferring
acl:authorizes
could be used in production to maintain a compatibility layer, it may in certain circumstances be used to migrate from one authorization system to the other.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, thanks. What I thought was a mistake might have a use after all!
So yes, to first address your second bullet point, the rule for inferring
:authorizes
could be used by new clients (ACP, WAC+, whatever...) on existing deployments. Or at least it allows us to see how existing deployments fit in with the proposal for an
:authorizes
relation.Existing deployments do not show the
:authorizes
relation, but it is as if there always had been one such relation from the document to eachAuthorization
. I.e. they could infer the blue dotted lines below.But as shown in our previous comment, it is essential for the
Authorization
nodes to appear inside the document linked to by theacl:accessControl
header. So there has to be some context around the:authorizes
rule above that makes that clear. That could be done in N3, and perhaps there is a better construct thanpropertyChainAxiom
to express it.To your first bullet point, the rule for
accessTo
is on the other hand completely general.It can be used to help clients written for the acl ontology to continue making sense of servers producing ACP, WAC+ or whatever we come up with, by injecting the new
acl:accessTo
triple in the Graph before the UI ACL code gets to run, as illustrated in issue 184.In any case both of these rules help show how the two systems relate, and increase our understanding of what is going on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Henry, out of curiosity, what do you use for those graphs?
It's quite handy and you seem very quick to make them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have been using Omnigraffle for close to 16 years now.
(I am not sure if there are new better tools out there)