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

Using timezone: Eastern Standard Time
* cmills joins06:26
* cmmills leaves06:28
* MohamedAR joins07:09
* dwilcox joins07:18
* dwilcox leaves08:08
* dhlamb joins08:14
* osmandin joins08:23
* dwilcox joins08:24
* awead joins08:45
* esm_ joins08:55
<ruebot>awoods: let me know if you want me to squash https://github.com/fcrepo4-labs/fcrepo4-vagrant/pull/18 when the time comes.09:05
* acoburn joins09:11
* whikloj joins09:17
<acoburn>whikloj: about fcrepo-1670, is it possible that you have an older version of fcrepo-camel in use?09:20
<whikloj>acoburn: I didn't think so, but I'll pull from master09:21
<acoburn>whikloj: the classNotFound error had to do with fcrepo-1667, and making use of a new jena package in fcrepo4
whikloj: but that package wasn't present in the (wrapped) jena libs that fcrepo-camel used09:22
<whikloj>acoburn++ git pull; mvn clean install; BUILD SUCCESS09:23
<acoburn>whikloj: excellent
whikloj: the camel part was resolved with this PR: https://github.com/fcrepo4-exts/fcrepo-camel/pull/89
* github-ff joins09:28
[fcrepo4-vagrant] awoods pushed 1 new commit to master: http://git.io/vGJqe
fcrepo4-vagrant/master 51f04d0 nruest: Move Fuseki install from stand alone server to deployable war....
* github-ff leaves
* github-ff joins
[fcrepo4-vagrant] awoods closed pull request #18: Move Fuseki install from stand alone server to deployable war. Addres… (master...FCREPO-1467) http://git.io/vsMH3
* github-ff leaves
* jrgriffiniii joins
* dwilcox leaves09:35
* dwilcox joins09:40
* ksclarke joins09:49
* dhlamb leaves09:53
* dhlamb joins09:54
* jgpawletko joins10:01
* peichman joins10:15
<MohamedAR>awoods: acoburn: whilkoj: peichman: I have updated PR7: https://github.com/fcrepo4-labs/fcrepo-module-auth-webac/pull/7 with the interface for AuhtorizationHandler.10:43
* apb18 joins10:55
<acoburn>[standup] working on a strawman implementation of the WebACAuthorizationDelegate logic, given the discussion in the google doc10:56
blockers: none10:57
<whikloj>(standup) Revised WebACAuthorization PR, checking AuthorizationHandler PR, drinking coffee...10:59
* bseeger joins11:00
* ajs6f joins11:01
I'm here.
* bseeger leaves
<whikloj>me too
* bseeger joins
<ajs6f>I cried.11:02
<osmandin>I'm on the call as well.
<peichman>[standup] looking at AuthorizationHandler PR, other than that, looking for assignments :-)11:03
<whikloj>poor dwilcox, many calls, many notes11:04
<ksclarke>I joined in too
* dhlamb_ joins11:10
* mikeAtUVa joins
<ruebot>...then it will put the bash script through its paces
* dhlamb leaves11:12
<ajs6f>I think we have to reserve ldp.11:14
But maybe that's a special case.
* yinlin joins11:16
They shouldn't be.
They should be entirely dynamical.11:23
<ajs6f>Moot Maniacal, the new Marvel superhero.11:24
<whikloj>what is their power?
<ajs6f>Her power is the ability to run fixity on ANYTHING.11:26
Not just digital files.
<whikloj>does it freeze them in time, or just allow you to track changes?11:27
<ajs6f>It makes them painfully, melancholically aware of the passing of time. This causes evildoers to lose interest in whatever crime they were going to commit and turn instead to art or religion in order to make sense of their lives in the brief time allotted.11:28
There's an issue for that somewhere.11:29
We could design our own ontology. It wouldn't be that hard.
<acoburn>wait! that's just À la recherche du temps perdu11:30
<ajs6f>Her other power is the ability to turn criminals into a tasty French cookie.11:31
Let's investigate the snot out of it.11:40
That's why we need a true fixity ontology.11:41
With classes and stuff.
Yes. Fixity is complex in itself and a resource has evolving fixity over time.11:42
* cjcolvar joins
* acoburn1 joins
* cjcolvar leaves
<ajs6f>And it's hard to undertstand.11:44
* acoburn leaves11:45
From the Modeshape PR " You can however, version the children of such a collection which are really regular nodes."11:51
<ajs6f>Right, it's just MODE doing it for us.11:58
* osmandin leaves12:01
<ajs6f>Bye bye.
* bseeger leaves12:02
* dhlamb joins
* ajs6f leaves
* dhlamb_ leaves12:05
* dhlamb leaves12:08
* jrgriffiniii leaves12:20
<awoods>All, if anyone is willing to flush this out or start some investigation, that would be helpful: https://jira.duraspace.org/browse/FCREPO-171012:23
acoburn1/whikloj/MohamedAR/peichman: Where do these PRs stand? What is needed to move them forward?12:39
* dhlamb joins12:48
<peichman>@awoods: PR-4 the only open question I have is about the return type of getObjectClasses()12:49
@awoods: PR-7 my question is about the purpose of the two different signatures for the getAuthorizations() method
<awoods>peichman: both good questions. acoburn1?12:52
* yinlin leaves13:06
<acoburn1>peichman/awoods/whikloj: I also have some questions about the getObjects and getObjectClasses methods13:09
What about renaming getObjects() to getAccessResources()13:10
<MohamedAR>awoods/acoburn/peichman/whikloj: will be leaving for a dr. appointment shortly. I will be glad to take on any assignments you choose for me.
Also updated the authorization flow diagram at: https://wiki.duraspace.org/display/FEDORA4x/WebAC+Authorization+Delegate13:11
<whikloj>acoburn1: are we still marking objects in the ACL with acl:accessTo triples?
<acoburn1>MohamedAR: can you add an analogous AuthorizationHandlerImpl in the impl. package namespace? Just a no-op impl at this point so that we can begin mocking together the interaction in the Delegate class?
whikloj: wouldn't that method return a set of URIs pointed to by the acl:accessTo triples?13:14
<whikloj>MohamedAR: One thing about that, how do we determine what is a user and what is a group? If we've done away with acl:agentClass it seems hard to quantify
acoburn1: I am starting to feel a little lost. That's why I want to clarify if we are? Perhaps it will only be Resource -> Authorization13:15
<MohamedAR>whikloj: I was thinking that neither WebACAuthorization nor AuthorizationHandler needs to make that distinction. Delegate should take care of it. wrong?13:17
<acoburn1>MohamedAR: I had the same thought
whikloj: I'm putting together some code for the Delegate class that models these interactions. I should have something to show in an hour or two. I'm hoping that can help focus discussion13:18
<whikloj>MohamedAR: technically I think the decision is "is agent in set<agents>" if yes, give union of all modes
<peichman>@acoburn1: shouldn't at least the WebACAuthorization make that distinction between the agents and agentClasses specified in the authz rule? The handler or delegate could then choose to collapse the distinction if it wanted to13:19
<whikloj>peichman: except that we are not using acl:agentClass, so we can't say what is a group or a username
<acoburn1>whikloj: so in the RDF for the WebAC, how do we distinguish between users and groups?13:21
<MohamedAR>awoods/acoburn/peichman/whikloj: updated PR with noop impl. signing out now.
<acoburn1>whikloj: do they both use acl:agent properties?
<whikloj>acoburn1: I thought we were using acl:agent for usernames and acl:agentClass for groups.
* MohamedAR leaves13:22
<whikloj>acoburn1: but https://github.com/fcrepo4-labs/fcrepo-module-auth-webac/pull/7#discussion_r38104083
^^ seems I missed this, but we are using a String of acl:agent for both
<peichman>@whikloj it makes a kind of sense to me if I think about a group as just another kind of agent; I think this is the easiest solution for existing implementations that manage group membership on external systems (LDAP, AD, etc.)13:24
<acoburn1>whikloj: that's fine as long as we scope them, e.g. user:acoburn, group:admin (or something like that)
<whikloj>acoburn1: I think that creates more of a headache then just leaving groups in acl:agentClass
<acoburn1>whikloj: I'm also inclined to leave groups in agentClass13:25
<whikloj>acoburn1: If you want to collapse the getAgents() and getAgentClasses() together, fine. But to have to tokenize to get the actual value...meh
<peichman>@acoburn1, @whikloj: the only thing that worries me about that is that both of those properties are supposed to take URIs
<whikloj>peichman/MohamedAR/acoburn/awoods: I guess the question is, do we care if it is a user or their group that gets the permission?13:26
<awoods>on a call
<whikloj>peichman: Yes, but my understanding is we aren't doing that in phase 1.
<peichman>@whikloj yes, but I raise to make sure we are not paiting ourselves into any corners :-)13:27
<whikloj>peichman: actually we aren't implementing WebIDs at all, but we are also not making agentclass a URI
<acoburn1>whikloj: can you imagine a scenario in which some user has the same handle as some group?
<peichman>@whikloj I can't see a use case where it matters whether it is the user or the group membership that allows a user access
<whikloj>acoburn1: it is conceivable13:28
<acoburn1>whikloj: that could cause problems, because suddenly that user has all the same privs as that group
<peichman>@acoburn1 isn't that what group membership should imply?
<acoburn1>whikloj: and it may be that users and groups are opaque values
<whikloj>acoburn1: actually there is a problem with groups as strings, how do we know what group you are a part of?
<acoburn1>peichman: the point is this: the delegate knows what user is accessing the resource and what roles they have13:29
<whikloj>the way it was to work, is get the URI from agentClass and check the list of users for the current user.
acoburn1: how does the delegate know what roles they have?13:30
<acoburn1>peichman: the delegate should then be able to filter authorizations based on (first) the username and (second) the set of roles
whikloj: look in the function signature: https://github.com/fcrepo4-labs/fcrepo-module-auth-webac/blob/master/src/main/java/org/fcrepo/auth/webac/WebACAuthorizationDelegate.java#L42
<whikloj>acoburn1: right but how do you know I am a part of any role?13:31
how do you do "whikloj is a member of Admin" if "Admin" is just a string13:32
groups become useless
<acoburn1>the delegate knows that user X has membership in groups Y and Z13:33
<acoburn1>that is autowired in, either through the servlet container, or through HTTP headers or by some other method13:34
awoods will need to confirm that, though
<awoods>acoburn1: correct. That comes from the notion of "PrincipalProviders"13:37
"principals" are roughly equivalent to "agents"
and "roles" (in the existing impls) map directly to "groups"13:39
<whikloj>ok, so then it really doesn't matter as long as your username or groups are in the Authorization. Filter for those Authz and then get the UNION of acl:modes
<awoods>yes, and as acoburn1 said, the Delegate knows the userId and the associated "roles" i.e. "groups" from the PrincipalProviders.13:40
the fact that the ACL RDF has "<> acl:agent whatever" makes less difference. What matters is that the Delegate knows what is the userId and what are the groups.13:41
<acoburn1>awoods: the question I have is this. Say the acl defines this: <> acl:agent "1e4", "b31", "22a", "8d7" .
<whikloj>acoburn1: how about getObjects() -> getProtectedResources()
<acoburn1>and the userid is "22a" but someone else is in the group "22a"
if the users and groups are opaque resources, that is not inconceivable13:42
then the question becomes: did the ACL mean the user or the group "22a"13:43
<peichman>acoburn1: is this a common scenario to have group names overlap with user names? are you think of a situation where the string that is used is an opaque identifier (like a uid or gid number on *nix)?
<acoburn1>peichman: maybe not, I'm just registering a concern13:44
* goes to look at how Shibboleth represents users and groups *
<awoods>acoburn1: Shib uses qualified attributes
acoburn: like acoburn@institution.edu13:45
<acoburn1>awoods: yes for eppn, but what about groups?
<awoods>acoburn1: not sure
is it Fedora's responsibility to ensure that user-ids and group-ids are unique from one another?13:46
<peichman>awoods: that feels like it should be the responsibilty of the local site operators
<awoods>that seems like a serious issue regardless of what we implement here
<whikloj>awoods: no, but I think there is an assumption that we don't mix up the permissions for group "admins" and Sally Admin's account13:47
<acoburn1>the shib configuration that I'm looking at right now uses "unscoped-affiliation" for groups: e.g. "member;employee"13:48
<peichman>thinking of other common authn systems that might be providing users and groups, and the main one I can think of is LDAP, which would use distinct DNs for a user and a group, even if their CN is the same
<awoods>I am happy only putting user-ids in acl:agent, but think it is a mistake to hijack agentClass for groups.13:49
<peichman>since (AFAIK) they would have to appear at differnt places in the tree
<whikloj>I'm thinking of Drupal that allows you to use a variety of auth systems
<acoburn1>awoods: I can agree to that, too (especially if you're threatening another 2 hr 45 min meeting)
<peichman>@whikloj: are you thinking of a scenario where a user would log in to a Drupal-based frontend, where Drupal would connect their identity from an external authn system to a Drupal user, and then be useing that Drupal user to authenticate to F4?13:51
<whikloj>peichman: possibly
is there a particular reason that groups can't use the acl:agentClass predicate? Then you do two filters for Authz, one with username and one with groups. Then do your UNION13:52
<awoods>I need to dash... bbi ~1.5hours
<acoburn1>Re-reading the webac page, and I think I disagree with awoods on agentClass13:54
all the examples show groups
<whikloj>I think it is not a huge investment to keep them separate.13:55
<peichman>for my part, my reluctance is more the use of string values for agentClass vs. URIs
<whikloj>peichman: I hear that, but acl:agent is supposed to accept URI too. We pick and choose until the spec becomes a spec.
<peichman>given that part of the protocol in the spec involves checking that agentClass URI to confirm that the user is a memeber of that group
@whikloj very true :-)13:56
<acoburn1>but why not interpret the Set<String> roles as URIs?
<acoburn1>e.g. <http://myinstitution.edu/group/groupName>
<peichman>hadn't thought of it quite that way
<whikloj>so I'll put back Set<String> getAgentClasses(); and setAgentClasses(Set<String>); ??
<acoburn1>And I'm not suggesting trying to dereference that URI in any way, just compare it to the set of URIs in the getAgenClasses() return value13:58
whikloj: just not the setXXXX method
<whikloj>acoburn1++ right forgot about that
<peichman>would we want to recommend that people use URIs for agentClass if possible?14:01
(while still allowing for plain Strings for better interop with existing authn systems)
<whikloj>acoburn1: how about getObjects() -> getProtectedResources()14:02
<peichman>@whikloj that method is for returning the list of resources that are the objects of acl:accessTo in the Authorization? if so, ++ to getProtectedResources()14:03
<whikloj>peichman: right
<peichman>maybe also getObjectClasses() -> getProtectedResourceClasses()?14:04
<acoburn1>whikloj: that seems much better. my only concern (which is minor) is that getProtectedResources doesn't sound much like acl:accessTo
<whikloj>acoburn1: getAccessTo()?
acoburn1: getAccessTos()?
<acoburn1>whikloj: getAccessThree14:05
* peichman looking at WebAC spec to see if they have any inverse term for accessTo
<acoburn1>peichman: they don't :-(
<peichman>acoburn1: dangit
<acoburn1>whikloj: what about getAccessToUris()14:06
whikloj: and forget about returning a FedoraResource14:07
<whikloj>acoburn1: except I was return FedoraResource
acoburn1: oh
<peichman>(2 hard problems in computer science: cache invalidation, naming things, and off-by-one errors)
<peichman>could the handler be responsible for turning the accessToUris set of URIs into a set of FedoraResources?14:08
<acoburn1>whikloj: it is possible that the ACL lives outside the fedora repo, and it may reference URIs that are also outside the repository
peichman: there should be some handler that does this14:09
<peichman>so maybe the clean solution is to have the WebACAuthorization class just returning URIs for the accessTo rules, and let some layer farther up get the FedoraResource; that keeps the WebACAuthorization class more generic14:10
<acoburn1>turning URIs into FedoraResources requires a FedoraResourceImpl object and/or a JCR node and session, and I'd prefer to keep those things as close to the Delegate class as possible
<peichman>so getAccessToUris() and getAccessToClassUris() as the method names?
<acoburn1>yes, unless you think URI should be in caps? (I don't have an opinion on that)
<whikloj>I like getAccessToURIs()14:12
(I prefer all caps for URI, but I know there are some other Java interfaces that spell it Uri in method names)
(but maybe I am misremebering that, or confusing it with HTTP/Http)14:17
* dwilcox leaves
<acoburn1>I'm looking at the spec a little more, and the Range of acl:agent is foaf:Agent, which may be a person, group, organization, etc14:26
… suggesting that groups really should be part of acl:agent
foaf:Agent is described here: http://xmlns.com/foaf/spec/#term_Agent
Also, it appears that Hydra implemented it that way, too: groups and users are put into acl:agent14:27
each having their own prefix to distinguish between groups and users
* dwilcox joins14:38
<whikloj>acoburn1: argh. https://github.com/fcrepo4-labs/fcrepo-module-auth-webac/pull/4/files14:41
* github-ff joins14:42
[fcrepo4] mikedurbin opened pull request #892: Made URIs derived from version labels the exposed ID. (master...FCREPO-1703) http://git.io/vGTN0
* github-ff leaves
<peichman>@whikloj: my only nitpick would be in the class Javadoc, it should be "WebAC Authorization objects", not "WebAC ACL objects"
<whikloj>peichman/acoburn1: ok but are we going back on acl:agent?14:43
<peichman>back to what? URIs?14:44
<acoburn1>peichman: back to putting both users and groups in acl:agent
peichman: and not using acl:agentClass
peichman: just like awoods has been telling us all along14:45
<peichman>especially given the foaf:Agent range, I think it makes sense to have users and groups in agent, since we are representing agents as strings at this phase
but my brain is a little fried from the round-and-round yesterday and today :-)14:46
<whikloj>peichman/acoburn1: I still think they should be separate. But I'll go with the consensus14:50
<acoburn1>whikloj: I think so, too, but I didn't write the "spec"14:51
<peichman>it feels like perhaps there is a mismatch between how the W3C "spec" writers think of users/groups, and how other authn systems do
<whikloj>So they what is acl:agentClass supposed to be?
<acoburn1>whikloj: apparently some URI that can be dereferenced to provide information on group membership14:52
whikloj: it would be convenient to use for external authorities. if, e.g. you queried a triplestore or some external service to get the group membership14:53
I think they are trying for a very semantic web/linked data way of doing groups, where the information can be distributed between different systems14:54
hence the URIs for everything
<acoburn1>peichman: until someone does some arp poisoning and hijacks the DNS resolution. That's my biggest real concern about linked data14:55
<peichman>acoburn1: yeah, trust of remote resources can be a weakness in LD14:56
<acoburn1>peichman: I mean it's great for public data, but for security-related resources, I continue to be very nervous about that14:57
<whikloj>I think I am going to leave the method, we can choose to not implement it right now14:58
<peichman>whikloj++ or just choose not to do anything with it14:59
even if it does return the values of accessToClass
<whikloj>ok, adding a commit to fix the javadoc
* ajs6f joins15:04
* cmills leaves15:16
* cmmills joins
* dwilcox leaves15:20
* dhlamb_ joins15:22
* acoburn1 leaves15:23
* dhlamb leaves15:24
* acoburn joins15:25
* acoburn leaves15:26
* acoburn joins15:28
* esm_ leaves15:32
* esm__ joins
* dhlamb_ leaves16:07
* esm__ leaves16:13
* ajs6f leaves
* MohamedAR joins16:15
* acoburn1 joins16:28
* acoburn leaves16:30
* github-ff joins16:53
[fcrepo-module-auth-webac] whikloj force-pushed jareds-acl-branch from 1b5f9dd to 8b04366: http://git.io/vGkSJ
fcrepo-module-auth-webac/jareds-acl-branch ad6e1cf Jared Whiklo: Change permissions to modes...
fcrepo-module-auth-webac/jareds-acl-branch fbbe8cb Jared Whiklo: Make method names closer to spec
fcrepo-module-auth-webac/jareds-acl-branch 4cc7aaa Jared Whiklo: Removing setters
* github-ff leaves
* whikloj leaves17:00
* github-ff joins17:05
[fcrepo-module-auth-webac] acoburn created delegate_impl (+1 new commit): http://git.io/vGk76
fcrepo-module-auth-webac/delegate_impl 07fab3a Aaron Coburn: strawman delegate implementation
* github-ff leaves
* mikeAtUVa leaves17:06
* github-ff joins17:07
[fcrepo-module-auth-webac] acoburn opened pull request #8: strawman delegate implementation (master...delegate_impl) http://git.io/vGk7j
* github-ff leaves
<ruebot>awoods: https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/pull/50 -- that still needs to get merged so vagrant will work.17:08
<awoods>ruebot: done17:09
* github-ff joins
[fcrepo-camel-toolbox] awoods pushed 2 new commits to master: http://git.io/vGk5g
fcrepo-camel-toolbox/master c3223b8 nruest: Updates for migrating from standalone Fuseki to fuseki.war. Address FCREPO-1467.
fcrepo-camel-toolbox/master 44eeac1 Andrew Woods: Merge pull request #50 from ruebot/FCREPO-1467...
* github-ff leaves
* github-ff joins17:15
[fcrepo-module-auth-webac] acoburn pushed 1 new commit to delegate_impl: http://git.io/vGkFn
fcrepo-module-auth-webac/delegate_impl 79156f5 Aaron Coburn: fixed syntactical error
* github-ff leaves
* travis-ci joins17:20
fcrepo4-exts/fcrepo-camel-toolbox#143 (master - 44eeac1 : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/2075359c4a4f...44eeac17fb82
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/77584434
* travis-ci leaves
* acoburn1 leaves17:27
* MohamedAR leaves17:29
* peichman leaves17:30
* jgpawletko leaves17:36
* ksclarke leaves18:22
* apb18 leaves18:56
* MohamedAR joins18:57
* the_mgt_ joins19:23
* the_mgt leaves19:26
* MohamedAR leaves19:45
* github-ff joins19:55
[fcrepo4-vagrant] philred opened pull request #20: Address #14 (master...patch-1) http://git.io/vGIwZ
* github-ff leaves
* ksclarke joins20:00
* ksclarke leaves20:05
* ksclarke joins20:21
* github-ff joins20:51
[fcrepo-module-auth-webac] whikloj force-pushed jareds-acl-branch from 8b04366 to 187f993: http://git.io/vGkSJ
fcrepo-module-auth-webac/jareds-acl-branch 187f993 Jared Whiklo: WebAC ACL Interface...
* github-ff leaves
* dhlamb joins21:29
* dhlamb leaves21:33
* dhlamb joins21:34
* awead leaves21:50
* ksclarke leaves22:21
* github-ff joins22:26
[fcrepo-module-auth-webac] awoods pushed 1 new commit to master: http://git.io/vGLfD
fcrepo-module-auth-webac/master 7b4f093 Andrew Woods: Merge pull request #4 from fcrepo4-labs/jareds-acl-branch...
* github-ff leaves
* ksclarke joins22:43
* apb18 joins23:02
* dhlamb leaves23:37
* dhlamb joins
* dhlamb leaves23:41
* apb18 leaves00:09

Generated by Sualtam