Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* sbmarks leaves01:23
* the_mgt leaves06:26
* dwilcox joins07:30
* dwilcox leaves07:42
* dwilcox joins07:52
* awead joins08:11
* esm_ joins08:48
* dhlamb joins08:50
* sbmarks joins09:04
* acoburn joins
* whikloj joins09:11
* ksclarke joins09:12
* jgpawletko leaves09:18
* mikeAtUVa joins09:28
<whikloj>acoburn: ping
* github-ff joins09:29
[fcrepo-module-auth-webac] acoburn pushed 2 new commits to master: http://git.io/vGP2e
fcrepo-module-auth-webac/master ce5cc70 Peter Eichman: Implement an EVERYONE principal in WebACAuthorizationDelegate....
fcrepo-module-auth-webac/master 6a6b0ff Aaron Coburn: Merge branch 'peichman-umd/everyone-principal'
* github-ff leaves
* github-ff joins
[fcrepo-module-auth-webac] acoburn closed pull request #11: Implement an EVERYONE principal in WebACAuthorizationDelegate. (master...everyone-principal) http://git.io/vGrLt
* github-ff leaves
<acoburn>whikloj: pong
<whikloj>acoburn: what would you like to get back from this? https://github.com/fcrepo4-labs/fcrepo-module-auth-webac/pull/8/files#diff-b437fc88d2f81bdcc2063b89bf2a55eeR7909:30
<acoburn>whikloj: I'd like a Set<WebACAuthorization> or a List<WebACAuthorization>09:31
whikloj: the other question is about the arguments
whikloj: it seems that the first value should be a FedoraResource09:32
<whikloj>acoburn: I'm wondering if based on the AccessRolesProvider interface we should return a Set of "all" WebACAuthorizations and filter for user and agent in your FAD
<acoburn>whikloj: that would work too
<whikloj>acoburn: sorry I cut you off, continue
<acoburn>whikloj: in that case, we wouldn't pass the agent value
whikloj: what I was about to say is that the value of the acl:accessControl property can be either a fedora resource or a URI that can be dereferenced elsewhere09:33
whikloj: if it's a fedora URI, then it would make sense to pass a FedoraResource to that function09:34
<whikloj>acoburn: because I was implementing the AccessRolesProvider I was working with this signature. https://github.com/fcrepo4/fcrepo-module-auth-rbacl/blob/master/fcrepo-auth-roles-common/src/main/java/org/fcrepo/auth/roles/common/AccessRolesProvider.java#L75
* MohamedAR joins
<whikloj>^^ to start, but we can use yours and implement this under the covers09:35
<acoburn>whikloj: that works, too
whikloj: basically we need to pass a Session in somehow
<whikloj>acoburn: ^^ that signature takes a Session :)
<acoburn>whikloj: I'd prefer if we weren't passing Session values around directly (awoods has made that point)
whikloj: which is why I suggested the FedoraResource as part of the signature09:36
<whikloj>acoburn: I feel like maybe my suggestion to abstract the AccessRolesProvider is now a hinderance, perhaps we should skip it for the AuthHandler
<acoburn>whikloj: I disagree, we can definitely use this as it currently exists09:37
whikloj: my main question is this: where do we transform the Map<String, List<String>> into List<WebACAuthorization>09:38
whikloj: that can either happen in the AccessRolesProvider or in the FAD09:39
whikloj: it's not much code to do that transformation
<whikloj>acoburn: Either way, that's why I suggested we could implement your signature in the AccessRolesProvider and feed into the interface methods behind the scenes, transform and return the Set<>09:40
* MohamedAR1 joins
<acoburn>whikloj: I think it would be best to keep the signature of this abstract class
whikloj: then we can do the transformation in either a utility class or in a simple private method in the FAD09:41
* osmandin joins
<whikloj>acoburn: ok, but then we are passing a Session into the WebACAccessRolesProvider
* peichman joins09:42
<acoburn>whikloj: I know, but that seems to be the only option
whikloj: I say that because if the ACL is not in fedora's domain, then the getRoles() method won't suffice09:43
<whikloj>acoburn: true
* MohamedAR leaves
<acoburn>whikloj: this way, the signature is generic enough to handle both cases09:44
whikloj: if the resource is external, the session is just disregarded
<whikloj>acoburn: except the signature also takes a jcr.Path09:45
<acoburn>whikloj: oh right
whikloj: ok, then this will only work for in-domain resources
whikloj: here's what I suggest:09:46
whikloj: we have some sort of intermediate (utility) class (or function)
whikloj: and that function takes the value of the acl:accessControl property + a Session09:47
* MohamedAR joins
<acoburn>whikloj: if that value is in-domain, it creates a JCR Path with a Session and uses the AccessRolesProvider09:48
whikloj: if not, it pulls in the data from an external URL and parses it
whikloj: the second case should be a lower priority, though
whikloj: would you like to implement that?
* MohamedAR1 leaves09:49
<whikloj>acoburn: The first or second part or both? I am also still working on the WebACAuthorization implementation.
<acoburn>whikloj: how about you finish the WebACAuthorization piece first09:50
<whikloj>acoburn: fair enough
<acoburn>whikloj: I'm going to put together a list of what still needs to be done and we can divide that up at our 11 ET call09:51
<whikloj>acoburn: ok, last question. Easiest way to convert an RdfStream to a collection (ie. Set<>)
<acoburn>whikloj: you can iterate over it: for(final Triple t : rdfStream) { mySet.add(…); }09:52
whikloj: RdfStream is basically an Iterator09:53
<whikloj>acoburn: ok, thanks ttyl
* ajs6f joins09:59
* github-ff joins10:01
[fcrepo-webapp-plus] awoods closed pull request #23: Added webac maven profile (master...webac-profile) http://git.io/vGrwN
* github-ff leaves
* travis-ci joins10:11
fcrepo4-exts/fcrepo-webapp-plus#71 (master - 14966f7 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-webapp-plus/compare/81fd433c7e86...14966f7f05b9
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-webapp-plus/builds/78401619
* travis-ci leaves
* the_mgt joins10:14
* github-ff joins10:16
[fcrepo-module-auth-webac] whikloj opened pull request #12: Adding http://www.w3.org/ns/auth/acl#mode to constants file. (master...constants) http://git.io/vGP7O
* github-ff leaves
<whikloj>acoburn/peichman/MohamedAR: ^^ yet another constant
<awoods>MohamedAR: please move the following ticket to "Start Review" if it is ready: https://jira.duraspace.org/browse/FCREPO-171410:20
* github-ff joins10:21
[fcrepo-module-auth-webac] awoods pushed 2 new commits to master: http://git.io/vGPdT
fcrepo-module-auth-webac/master 8b66025 Jared Whiklo: Adding ttp://www.w3.org/ns/auth/acl#mode to constants file.
fcrepo-module-auth-webac/master 32189ea Andrew Woods: Merge pull request #12 from whikloj/constants...
* github-ff leaves
<MohamedAR>awoods: did that. one issue though, the integration test for webac is failing with this PR.
<awoods>MohamedAR: do you know why?10:23
<MohamedAR>awoods: failing in the ingestObject, couldn't identify the reason yet. Added the stacktrace to the issue comment: https://jira.duraspace.org/browse/FCREPO-1714?focusedCommentId=44548&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-4454810:25
<acoburn>whikloj: it looks like the AccessRolesProvider interface will be insufficient10:26
<awoods>MohamedAR: I added a comment to: https://github.com/fcrepo4-labs/fcrepo-module-auth-webac/pull/9
MohamedAR: it is the same comment as from the first review.
<acoburn>whikloj: I say that b/c in addition to roles and "modes", it needs to include "accessTo" and "accessToClass" values
whikloj: which means we will need to extend the interface10:27
<whikloj>acoburn: and you don't want to extend it to far
acoburn: ok
<acoburn>whikloj: there are two options, as I see it10:28
whikloj: one is that we use the AccessRolesProvider only for agents and mods
whikloj: and then add in any accessTo or accessToClass values taken from the FedoraResource10:29
whikloj: — OR --
whikloj: we extend the interface so that it extracts everything we need10:30
whikloj: ideally, returning it in a format that is readily usable: List<WebACAuthorization>
whikloj: any thoughts?
<MohamedAR>awoods: addeed a response to the comment.
<whikloj>acoburn: would we not assume that the accessTo or accessToClass is irrelevant as it would be scoped by the "getRolesForPath"?10:31
acoburn: not that "getRolesForPath" is an adequate name anymore
acoburn: but we only return permissions relevant to that resource
<acoburn>whikloj: that would work for accessTo, but what about accessToClass?
<whikloj>acoburn: same thing, we are passing in a path which we would have to convert to a FedoraResource so we can get the classes to test.10:32
<acoburn>whikloj: actually, that might work...
<awoods>MohamedAR: added a response to your response to the comment.
<acoburn>whikloj: if the constructor accepts those values10:33
whikloj: in that case, the getAccessToURIs() would return only the relevant URI?
whikloj: and the same for the getAccessToClassURIs()10:34
<whikloj>acoburn: it would return all accessTo statements, such that at least one accessTo or accessToClass matches the requesting resource. IMHO
* dhlamb leaves
<whikloj>acoburn: however...10:35
<MohamedAR>awoods: updated the PR
<whikloj>acoburn: should we do as you suggest, because moving to having URIs for agent and agentClass is going to cause us problems in future.
<acoburn>whikloj: so is the AccessRolesProvider returning the accessTo statements?10:36
whikloj: b/c I don't see how those would fit into the Map<String, List<String>> return value
<whikloj>acoburn: oh wait, I see. no no it is not.10:37
acoburn: But maybe that is a change to the WebACAuthorization interface?10:38
acoburn: Do we care what else it applies to, as long as it applies to the current resource?
<acoburn>whikloj: what I was thinking was that the AccessRolesProvider implementation reads all the Authorizations for a given ACL, but includes only those Authorizations that apply to the given resource10:39
<whikloj>acoburn: so it never returns them and they are not included in the WebACAuthorization?10:40
* dhlamb joins
<acoburn>whikloj: the downside of this is that a given WebACAuthorization wouldn't know what it's accessTo or accessToClass values are
* escowles leaves10:41
* jgpawletko joins
<whikloj>acoburn: and why do we need to know that?10:42
<acoburn>whikloj: I need to think about this a bit, though — we need to segregate the accessTo and accessTo authorizations because they happen at different phases
whikloj: I mean "segregate the accessTo and accessToClass"
<acoburn>whikloj: from what I can tell, we can either reuse the existing interface (as-is), parsing the ACL twice: once for accessTo and once for accessToClass - OR - we can extend the interface10:44
whikloj: does that sound right to you?
<whikloj>acoburn: I could be wrong, but if resource A -ex:hasAcl-> ACL_1, then if ACL_1 has either accessTo or accessToClass matching resource A we are good.10:45
acoburn: If resource A -container-> B -ex:hasAcl-> ACL_2, then (again) if ACL_2 has either accessTo or accessToClass matching resource A we are good.10:46
acoburn: we filter the Set<WebACAuthorization> to just those relevant to making the decision in the FAD
<MohamedAR>whikloj: I have the same understanding.
<acoburn>whikloj: yes, you are correct, thanks!10:49
<f4jenkins>Project fcrepo4-T2 build #343: UNSTABLE in 5 min 36 sec: http://jenkins.fcrepo.org/job/fcrepo4-T2/343/10:53
awoods: Add FedoraResource.getTypes() method
in a meeting
* acoburn1 joins11:17
* acoburn leaves11:19
* escowles joins11:31
* acoburn joins11:44
* acoburn2 joins11:45
* acoburn1 leaves11:46
* acoburn leaves11:49
whikloj: https://jira.duraspace.org/browse/FCREPO-171911:58
<escowles>awoods: hangout?12:02
<whikloj>acoburn2: here is the WebACAuthzImpl, which is more like the WebACAccessRolesProvider https://github.com/whikloj/fcrepo-module-auth-webac/blob/WebACAuthorizationImpl/src/main/java/org/fcrepo/auth/webac/WebACAuthorizationImpl.java12:28
<acoburn2>whikloj: thanks12:29
* github-ff joins12:32
[fcrepo4-release-tests] whikloj pushed 2 new commits to master: http://git.io/vGXpp
fcrepo4-release-tests/master 10f6f81 Andrew Woods: Fix broken sparql-recipes...
fcrepo4-release-tests/master f68121c Jared Whiklo: Merge pull request #16 from awoods/fcrepo-1719...
* github-ff leaves
* travis-ci joins12:38
fcrepo4-labs/fcrepo4-release-tests#52 (master - f68121c : Jared Whiklo): The build was fixed.
Change view : https://github.com/fcrepo4-labs/fcrepo4-release-tests/compare/2815567e482d...f68121c77fa1
Build details : https://travis-ci.org/fcrepo4-labs/fcrepo4-release-tests/builds/78429940
* travis-ci leaves
<whikloj>awoods: ping13:04
<awoods>in a meeting13:05
whikloj: back13:12
<whikloj>awoods: I know in Fedora 3 the XACML policies were stored on the object, is that your understanding of how the current RbAcl and Xacml works?13:13
^^ on the resource
<awoods>whikloj: F4 rbacl stores policies as children of the resource (or the resource's parent)13:17
whikloj: F4 xacml, I believe the policies can be anywhere in the repo.13:22
<whikloj>awoods: ok, thanks13:23
<awoods>whikloj: for xacml, and initial set of policies are created in a top-level container13:24
whikloj: you are working through the existing integration tests?
<whikloj>awoods: yes, just trying to understand how the RolesFadTestObjectBean can generate both RbAcl and Xacml ACLs with the same createJsonAcls method13:26
<awoods>whikloj: this may or may not come into play, but when the xacml module is initially loaded, a whole set of policies get put into the repository.13:27
whikloj: That may add a piece of magic to what you are looking at.
<whikloj>awoods: ok I'll have a look, thanks
<peichman>whikloj: that was part of my confusion as well, and what led me to believe that there is a bunch of RBACL-specific stuff baked into the AbstractRolesIT class
<awoods>whikloj: https://github.com/fcrepo4/fcrepo-module-auth-xacml/blob/master/src/main/java/org/fcrepo/auth/xacml/XACMLWorkspaceInitializer.java#L15213:28
<whikloj>peichman: my guess is that perhaps in the AccessRolesProvider postRoles, etc. It must interpret the same Json to apply the ACL and just do it differently.
<peichman>whikloj: that suggests to me that the different auth modules are all supposed to be implementing the same JSON-based API for managing ACLs as RBACL?13:31
<whikloj>peichman: possibly, my guess is that the structure is very simple and is just the Map<String, Set<String>> seen on the rbAclAccessRolesProvider.postRoles()13:34
<awoods>peichman: your are correct: rbacl and xacml "auth modules are all supposed to be implementing the same JSON-based API for managing ACLs as RBACL"13:36
<peichman>awoods: Is this something we need to implement in the WebAC auth module?13:37
<awoods>peichman: the xacml part just applies rules to the roles defined in the json
peichman: no, webac is different
<peichman>awoods: that is what I thought13:38
<awoods>peichman: which likely means the integration tests will also be different
<peichman>awoods: that is the conclusion I am coming to
<awoods>peichman: hopefully that is the conclusion whikloj is also coming to.13:39
<peichman>awoods: I see starting with whikloj's recipes in the wiki and turning them into code
awoods: replace curl with HttpClient, etc.13:40
<whikloj>peichman++ awoods++
<awoods>peichman/whikloj: although there are some good patterns to be learned from in the legacy integration tests
<peichman>awoods: noted
* dwilcox leaves13:53
* github-ff joins14:00
[fcrepo-module-auth-webac] acoburn force-pushed delegate_impl from 37c40d8 to dce811c: http://git.io/vG1Qc
fcrepo-module-auth-webac/delegate_impl ed1e47f Aaron Coburn: strawman delegate implementation
fcrepo-module-auth-webac/delegate_impl eaf631b Aaron Coburn: fixed syntactical error
fcrepo-module-auth-webac/delegate_impl a1a5bd1 Aaron Coburn: added accessToClass stubs and use of acl:accessControl property
* github-ff leaves
<terrellt>When I sparql-update a new mime-type on this fcr:metadata I get "WARN 14:25:52.556 (RepositoryExceptionMapper) Caught repository exception: This method cannot be called on a property with multiple values"14:27
When I pull up the NonRDF source.14:28
The fcr:metadata still work
Looks like it's when I update the mime type?14:29
* osmandin leaves14:30
<terrellt>Yeah, arbitrary metadata added to that node is fine.14:32
* jgpawletko leaves
* jgpawletko joins14:34
* jgpawletko leaves
<awoods>MohamedAR: Is this comment meaningful: https://github.com/fcrepo4-labs/fcrepo-module-auth-webac/pull/9/files#diff-0bab136fbb2fc32a56fbd93d3af62c5aR6314:39
* pgwillia joins
<awoods>peichman/whikloj/acoburn2: I have reviewed and rebased MohamedAR's three PRs associated with: https://jira.duraspace.org/browse/FCREPO-171414:48
peichman/whikloj/acoburn2: I am ready to push them to their respective projects. Any objections?14:49
<acoburn2>awoods: they look good to me14:50
<awoods>acoburn2: commits coming14:51
* github-ff joins14:52
[fcrepo4] awoods pushed 1 new commit to master: http://git.io/vGMIY
fcrepo4/master 3b03cc1 Mohamed Mohideen Abdul Rasheed: Refactor for alternate implmentations of FedoraUserSecurityContext...
* github-ff leaves
* 17SADG8D9 joins14:55
[fcrepo-module-auth-rbacl] awoods closed pull request #23: FCREPO-1714. Moved FedoraUserSecurityContext instantiation to fad. (master...FCREPO-1714) http://git.io/vGVMk
* 17SADG8D9 leaves
* github-ff joins
[fcrepo-module-auth-rbacl] awoods pushed 1 new commit to master: http://git.io/vGMLP
fcrepo-module-auth-rbacl/master 362a501 Mohamed Mohideen Abdul Rasheed: FCREPO-1714. Moved FedoraUserSecurityContext instantiation to fad....
* github-ff leaves
* github-ff joins
[fcrepo-module-auth-webac] awoods pushed 1 new commit to master: http://git.io/vGML5
fcrepo-module-auth-webac/master 05041cb Mohamed Mohideen Abdul Rasheed: Add FedoraWebACUserSecurityContext...
* github-ff leaves
* github-ff joins14:56
[fcrepo4] awoods closed pull request #896: Created FedoraWebACUserSecurityContext (master...FCREPO-1714) http://git.io/vGWrn
* github-ff leaves
* github-ff joins14:57
[fcrepo-module-auth-webac] awoods closed pull request #9: FCREPO-1714. (master...FCREPO-1714) http://git.io/vGVDr
* github-ff leaves
* travis-ci joins14:59
fcrepo4/fcrepo-module-auth-rbacl#30 (master - 362a501 : Mohamed Mohideen Abdul Rasheed): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-rbacl/compare/9e284e64cc98...362a501b34bf
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-rbacl/builds/78451715
* travis-ci leaves
<awoods>terrellt: Is your mimetype update failing? or is this issue around a misleading logging message?15:00
<terrellt>The update works, but then the content's unretrievable.15:04
Only the fcr:metadata
* travis-ci joins15:09
fcrepo4/fcrepo4#4020 (master - 3b03cc1 : Mohamed Mohideen Abdul Rasheed): The build passed.
Change view : https://github.com/fcrepo4/fcrepo4/compare/b03c4ea93d04...3b03cc16a5d8
Build details : https://travis-ci.org/fcrepo4/fcrepo4/builds/78451267
* travis-ci leaves
<MohamedAR>awoods: acoburn: whikloj: peichman: I have a question on yesterday's discussion on when to stop looking up the tree for ancestor ACLs. http://irclogs.fcrepo.org/2015-09-01.html @15:5215:15
Looks like we decided to stop when the first ACL is found, is that right?
<acoburn2>MohamedAR: that is correct
<whikloj>MohamedAR: that is my recollection
<peichman>MohamedAR: yes
<MohamedAR>awoods: acoburn: whikloj: peichman: I see a problem with that. Here is a scenario:15:16
UserA belongs to GroupA
UserB belongs to GroupB
ObjectA belongs to CollectionA
ObjectA is of type ClassA
CollectionA has ACL_1
ObjectA has ACL_2
ACL_1 specifies:
GroupA can READ to CollectionA
GroupA can WRITE to ClassA
ACL_2 specifies:
UserB can READ ObjectA
Now, when UserA requests WRITE access to ObjectA, if we stop after checking authorizations for UserA on ACL_2, the requested would be denied.
Shouldn't UserA be granted access based on ACL_1 that includes WRITE access for GroupA to ClassA objects?
* travis-ci joins15:17
fcrepo4/fcrepo-module-auth-rbacl#30 (master - 362a501 : Mohamed Mohideen Abdul Rasheed): The build has errored.
Change view : https://github.com/fcrepo4/fcrepo-module-auth-rbacl/compare/9e284e64cc98...362a501b34bf
Build details : https://travis-ci.org/fcrepo4/fcrepo-module-auth-rbacl/builds/78451715
* travis-ci leaves
<whikloj>Then we need to collect all ACLs from resource to root node and merge permissions?
<MohamedAR>or we could continue to chack for ancestor ACL, until a matching authorization is found or we reach root.15:19
<acoburn2>No. If the child ACL is more restrictive, then UserA is out of luck
<peichman>in the planning discussions prior to the sprint, I recall us deciding that we were not going to attempt to do any merging of ACLs in this phase
in the scenario given, I don't see a reason why there are two separate ACLs
<whikloj>but the ACL on the object does not specify any permissions for the user, so would we not continue up? Or deny right there?15:20
<peichman>whikloj: it specifies them indirectly, since it mentions the group they are a part of15:21
<whikloj>peichman: not really the resource has "UserB can READ ObjectA", but UserA is reading it.15:22
peichman: ACL_1 is on the collection
<peichman>why would ACL_1 and ACL_2 have to be separate ACLs? why not combine them?15:23
also, we did discuss implementing an acl:include property in a future phase, for explicit merging of ACLs
<whikloj>what MohamedAR is saying is that because there is an ACL on the object, we would stop there. But if we went up one level the user would have permission. This is the reverse of my Scenario 3.15:24
<MohamedAR>peichman: the UserB just needs access to that particular object and has nothing to do with that collection, so a separate ACL. I guess the user can make a choice to add it to the collection ACL, but it could be otherwise too.
<whikloj>the question is do we stop at the first ACL or the first ACL that specifies a permission applicable to the user/group
<peichman>MohamedAR: I think until we implement acl:include, it is simpler to just stop at the first ACL15:25
if we stopped at the first ACL that mentioned the user/group, we would also block what I see as a legitimate use case, where a child collection needs more restictive permission to exclude a certain user/group that can see its parent collection
<acoburn2>I thought we decided to stop at the first ACL15:26
<whikloj>I think we are making a mistake then.
<peichman>for use cases like MohamedAR brings up, the current colutions would be either: 1) combine the ACLs, or 2) duplicate applicable rules15:27
<MohamedAR>acoburn: peichman: I am fine with that, but just wanted to make sure that we know that the functionality we envisioned for the global accessToClass initially is different from this.15:28
<whikloj>collectionA -ex:hasACL-> ACL_1 (foaf:Agent READ), resourceA (inside collectionA) -ex:hasACL-> ACL_2 ('Admins' READ, WRITE).
<acoburn2>whikloj: do you have the link handy where we outlined how an effective ACL will be found?
<whikloj>public can't see anything in collectionA15:29
I have another meeting, be back shortly
<acoburn2>MohamedAR: since this commit: http://git.io/vGML5 I'm unable to compile the webac module15:32
it seems the hasRole() method is marked as final in the parent class
were you able to get the code to compile?15:33
<MohamedAR>acoburn2: pull the latest changes from fcrepo4, I have removed the final modifier in the supre class
* github-ff joins15:40
[fcrepo-module-auth-webac] acoburn created acl-Authorization-constant (+1 new commit): http://git.io/vGMBw
fcrepo-module-auth-webac/acl-Authorization-constant 4fb187f Aaron Coburn: added acl:Authorization class
* github-ff leaves
* github-ff joins
[fcrepo-module-auth-webac] acoburn opened pull request #13: added acl:Authorization class (master...acl-Authorization-constant) http://git.io/vGMBy15:41
* github-ff leaves
<acoburn2>MohamedAR/whikloj/awoods/peichman: here's a very simple PR for you all to review ^^^15:42
* github-ff joins15:54
[fcrepo-module-auth-webac] awoods deleted acl-Authorization-constant at 4fb187f: http://git.io/vGMup
* github-ff leaves
<MohamedAR>awoods: acoburn: piechman: whikloj: https://wiki.duraspace.org/display/FEDORA4x/WebAC+Authorization+Delegate Please review.16:03
<peichman>MohamedAR: should steps 2.a.iv-v. each include 1) authorizations that specify accessTo the resource's ancestor, and 2) authorizations that specify accessToClass of the resource's ancestor's type?16:08
<awoods>MohamedAR: My understanding of 1.a.i is different.16:11
* esm_ leaves
<MohamedAR>peichman: I wasn't sure about that. awoods: acoburn2: whikloj: opinions?16:12
* ajs6f leaves
<awoods>MohamedAR: from a readability and maintenance point of view, I would suggest not duplicating steps 1.a.i-iii in 2
MohamedAR: instead, maybe "refer to the steps above"16:13
<whikloj>I'd agree that trimming it down to Finding the ACL, then processing the ACL would be more readable.
<MohamedAR>awoods: will refactor it.
<awoods>Are we taking the union of 'accessTo' and 'accessToClass'?16:14
<whikloj>MohamedAR: I would have said you were correct, but now I am unclear. If there is not a specific accessTo or accessToClass, we didn't discuss testing against two FedoraResources
<awoods>I was thinking that 'accessTo' is more specific, and would therefore take precedence.
<whikloj>awoods: I thought it would be the union of the permissions, as that would be the "most permissive"16:15
<MohamedAR>awoods: I was thinking the same as whikloj.
<acoburn2>MohamedAR: I have a different understanding of 1.a.iii.1
<awoods>all: I wonder if we need a quick call?16:16
<whikloj>MohamedAR: in which case, I think if the object is not in the accessTo or has a rdf:type in accessToClass, they we don't match and Deny access
<acoburn2>You have: Find the union of authorizations found from steps 1.a.i and 1.a.ii.
* dhlamb leaves
<acoburn2>I thought "user" access takes precendence
<whikloj>awoods: ok
<awoods>others? are you ready?
<acoburn2>awoods: do you have that link handy?
* whikloj leaves16:58
* mikeAtUVa leaves17:05
* dwilcox joins17:17
* peichman leaves17:27
* dwilcox leaves17:48
* pgwillia leaves18:00
* acoburn2 leaves18:10
* ksclarke leaves18:22
* MohamedAR leaves18:25
* dwilcox joins18:46
* github-ff joins18:54
[fcrepo4] awoods opened pull request #900: Update CND to define cardinality of binary properties: (master...fcrepo-1720) http://git.io/vGDBI
* github-ff leaves
* github-ff joins19:16
[fcrepo-module-auth-webac] acoburn created acWebAuthImpl (+1 new commit): http://git.io/vGDuz
fcrepo-module-auth-webac/acWebAuthImpl 0d93fe7 Aaron Coburn: added a WebACAuthorizationImpl class
* github-ff leaves
* github-ff joins19:17
[fcrepo-module-auth-webac] acoburn opened pull request #14: added a WebACAuthorizationImpl class (master...acWebAuthImpl) http://git.io/vGDuP
* github-ff leaves
* the_mgt_ joins
* the_mgt leaves19:21
* dwilcox leaves19:43
* ksclarke joins20:05
* ksclarke leaves20:10
* ksclarke joins20:25
* github-ff joins22:07
[fcrepo-module-auth-webac] acoburn force-pushed delegate_impl from dce811c to b9a7f84: http://git.io/vG1Qc
fcrepo-module-auth-webac/delegate_impl bd58295 Aaron Coburn: strawman delegate implementation
fcrepo-module-auth-webac/delegate_impl b9a7f84 Aaron Coburn: added accessToClass stubs and use of acl:accessControl property
* github-ff leaves
* dhlamb joins22:12
* f4jenkins leaves23:21
* f4jenkins joins
* awead leaves23:52
* awead joins23:54
* ksclarke leaves00:08
* dhlamb leaves00:09
* awead leaves00:11
* awead joins00:22
* awead leaves00:51
* github-ff joins01:32
[fcrepo4] jrgriffiniii opened pull request #901: FCREPO-1627 #time 1h After failed attempts to rebase from the upstrea… (master...fcrepo-1627) http://git.io/vGygl
* github-ff leaves
* github-ff joins01:33
[fcrepo4] jrgriffiniii closed pull request #841: FCREPO-1627 (https://jira.duraspace.org/browse/FCREPO-1627) (master...fcrepo-1627) http://git.io/vm4f8
* github-ff leaves