Call will use skype
[13:59:15 BST] David De Roure: Hi
[13:59:32 BST] Piotr Holubowicz: Hi!
[13:59:39 BST] Raul Palma: Hi
[13:59:41 BST] kevin.page: Hi
[13:59:43 BST] David De Roure: Hi
[13:59:53 BST] kevin.page: invite anyone who should be here? ;)
[14:00:18 BST] David De Roure: Anyone else to add?
[14:00:38 BST] kevin.page: who from iSoco?
[14:00:48 BST] David De Roure: Jose is online... (?)
[14:00:49 BST] gklyne: Hi
[14:01:12 BST] Rafael González-Cabero: hi all
[14:01:24 BST] David De Roure: Hi Rafa. Should we be adding anyone else from UPM?
[14:01:48 BST] Rafael González-Cabero: No, it is not necesary
[14:01:51 BST] David De Roure: tx
[14:02:10 BST] David De Roure: Rafa, do you know if there's someone in isoco we should be adding?
[14:02:52 BST] Rafael González-Cabero: I don't know who, but my guess that at least one
[14:02:58 BST] gklyne: (As far as API discussiomn is concerned, I'm working closely with Esteban and Aleix for next sprint)
[14:03:27 BST] David De Roure: Estaban is online, I'll check
[14:04:57 BST] gklyne: @piotr - while we're spinning up, I piut a copy of my RO dereferencing notes in the wiki - http://www.wf4ever-project.org/wiki/display/docs/RO+dereferencing
[14:05:50 BST] * David De Roure invited egarciacuesta
[14:06:16 BST] David De Roure: Okay, I think we're ready. ALeix would join us if it were before 3pm CET, so future meetigns in the mornign will be ok - Esteban is standing in
[14:06:39 BST] kevin.page: Draft agenda to bash:
[14:06:41 BST] kevin.page: - Scope of call and topic list for future calls
- Decide topic for 24th
- Today's topic: Distributed User Policy and Access Control. How will
user policy and access control be standardised or shared across the
Wf4Ever architecture? Will there be a distributed enforcement mechanism?
- Other topics for today:How to dereference an RO Elephant; Checklist evaluation API
[14:07:01 BST] gklyne: Audio's poor here
[14:07:50 BST] Stian Soiland-Reyes: sounds good to me
[14:09:58 BST] gklyne: We in WP4 are working towards integrating our I&A work for M20 (July) - this is why we need the checklist API
[14:10:27 BST] gklyne: ... and this depends on RO dereferencing
[14:11:18 BST] kevin.page: Q: any "burning issues" that we *must* have straight before the July deadlines
[14:12:02 BST] kevin.page: Piotr: agreement on how services (and clients) interact? e.g. as background processes?
[14:12:13 BST] gklyne: I don't quite get the distinction here
[14:12:48 BST] gklyne: (The code has to implement some services, though)
[14:13:12 BST] gklyne: We haven't really had an integrated deliverable, IMO
[14:13:23 BST] kevin.page: Yes, this is the first integration
[14:13:49 BST] gklyne: What is meant by "in the sandbox"?
[14:13:55 BST] Piotr Holubowicz: @Graham: my point is about sth like a sequence of interactions between services, RODL, myExperiment and... the users/curators
[14:14:17 BST] Piotr Holubowicz: But I agree that maybe it's not a topic for the M20 deliv
[14:15:40 BST] gklyne: @piotr - sorry, still not seeing the issue -- interactions between services as opposed to ... what?
[14:16:09 BST] Esteban García Cuesta: I guess that client pushes vs. backgournd processes
[14:17:32 BST] gklyne: And if we deliver a document, they might ask us to change it?
[14:17:46 BST] kevin.page: @gklyne: again :)
[14:18:21 BST] Piotr Holubowicz: @Graham: it's what Esteban said, the service might work as an agent updating RODL, or RODL might call the service periodically. My bottom line is that we don't actually have a fixed scenario that would define how the users benefit from the services - what should be handled automatically, what manually, etc
[14:18:41 BST] Piotr Holubowicz: But let's move this discussion for another time :)
[14:19:02 BST] Esteban García Cuesta: p.e. curation service should be working on background, isnt it?
[14:19:12 BST] Esteban García Cuesta: once is wokring
[14:19:16 BST] gklyne: @piotr... I think I get it now. It's a distrubited C/S vs a kind of blacknoard model?
[14:19:41 BST] gklyne: @kevin +1 (postpone)
[14:19:44 BST] Piotr Holubowicz: +1
[14:20:44 BST] Piotr Holubowicz: @Graham: yes, I think you've put it correctly
[14:21:01 BST] kevin.page: could we do a round table on which services will exist by july:
[14:21:29 BST] kevin.page: gklyne: checklist evaluation service (WP4) and some kind of authenticity and integrity services
[14:21:56 BST] Esteban García Cuesta: +q
[14:22:17 BST] Esteban García Cuesta: yes
[14:22:40 BST] Piotr Holubowicz: (kevin, can you mute?)
[14:23:20 BST] Esteban García Cuesta: I think that Rafa is down
[14:23:21 BST] kevin.page: recommender services?
[14:23:38 BST] Rafael González-Cabero: yes
[14:23:46 BST] Rafael González-Cabero: try again to call me
[14:24:42 BST] David De Roure: seem to have lost Rafa
[14:24:45 BST] kevin.page: Ok, but some kind of examination of recommend. is on the queue
[14:25:51 BST] kevin.page: Then ROSR
[14:25:57 BST] kevin.page: and Evolution
[14:25:57 BST] gklyne: Elephants! (ROSRS)
[14:25:58 BST] Rafael González-Cabero: hi?
[14:26:27 BST] gklyne: @Rafa, Kevin was asking about recommender services before you dropped out
[14:26:30 BST] kevin.page: piotr: idea of notification service
[14:26:48 BST] Rafael González-Cabero: can you call me?
[14:27:05 BST] gklyne: Re: notification services - there's som,e DL work (ResourceSync) that is addressing related issues (not by July!)
[14:27:20 BST] kevin.page: notification on the topic queue, but not for July deliv.
[14:27:49 BST] kevin.page: dder: also workflow execution
[14:29:21 BST] Stian Soiland-Reyes: I dropped out :(
[14:29:59 BST] Stian Soiland-Reyes: tnx
[14:30:11 BST] kevin.page: rafa: recommender just one API
[14:31:14 BST] gklyne: (To clarify an earlier response about I&A, I imagine at least two service endpoints but probably with similar style of interface.)
[14:31:29 BST] kevin.page: piotr: RODL has some implementation to identify users, using dlibra on the backend
[14:31:44 BST] kevin.page: keeping it simple, not so much model and theory :) Using openid to id themselves
[14:32:08 BST] kevin.page: some personal details retrived from the openid provider when the user logs in
[14:32:08 BST] Esteban García Cuesta: +1 @graham, each service == 1 funcionality
[14:33:30 BST] gklyne: Different id or different auth token?
[14:34:31 BST] kevin.page: piotr: not perfect because: store URIs of users (i.e. openid) but if these are dereferenced you go to that openid provider
[14:35:00 BST] kevin.page: we could duplicate (or cache) this in RODL
[14:35:29 BST] kevin.page: exploring... using the resource that RODL creates for the user
[14:36:30 BST] kevin.page: kevin: could there be a distinction between user and user account (on a service e.g. on RODL)
[14:37:26 BST] gklyne: SECURE project did some work on entity recognition in distributed environments: http://www.cl.cam.ac.uk/research/srg/opera/projects/secure/
[14:38:16 BST] gklyne: Buzzword was "entity recognition"
[14:40:38 BST] gklyne: Some people would regard exposing their name when accesisng information as a privacy violation.
[14:41:08 BST] gklyne: (SECURE project dealt with pseudonomynous recommenders .. that was their thrust)
[14:42:26 BST] kevin.page: what requirements for identifiers come from collab spheres?
[14:42:31 BST] gklyne: The answer is "URI" ... now what was the question?
[14:43:38 BST] Esteban García Cuesta: what is the question about collab spheres exactly?
[14:43:54 BST] Esteban García Cuesta: we are not treating access policies so far
[14:44:37 BST] kevin.page: @esteban: q was about identity requirements (e.g. common identifiers shared with RODL?) from collab spheres
[14:46:23 BST] kevin.page: rafa: recommender needs for identification, URI for each user, also myExperiment ID
[14:46:47 BST] gklyne: For WP4 ... checklist evaluation just needs access to resources, but the I&A component will probably need to be aware of, e.g., user preferences - hence know something about the requesting user.
[14:47:11 BST] Esteban García Cuesta: +q
[14:48:08 BST] Raul Palma: http://www.wf4ever-project.org/wiki/display/docs/User+identification+in+RODL
[14:48:47 BST] Raul Palma: Please comment it
[14:48:59 BST] gklyne: @raul - that suggests that if we have the RODL URI for a user, then RODL could act as a hub for access to othert information.
[14:49:31 BST] Raul Palma: it could, does it make sense to you?
[14:50:00 BST] kevin.page: @gklyne: yeah, that was what I was thinking
[14:50:09 BST] gklyne: @raul seems reasonable, but I'm not aware of the full range of requirements that may bear. I thimnk it's a useful starting point.
[14:51:07 BST] gklyne: ni://wf4ever-project.org/MD5;xxxxxxxxxxx ?? for user id?
[14:51:22 BST] Esteban García Cuesta: for collab spheres the need is to access user preferences, and RODL to be able to retrieve for instance friends of a user...the visual metaphor is indepent of its use but its going to rely on recommendation for visualizing which would need it also , right Rafa?
[14:52:08 BST] Rafael González-Cabero: @raul IMHO this is the best approach
[14:52:42 BST] Raul Palma: @graham, the format we were thinking was a bit different (see wiki page), but this can be improved
[14:53:03 BST] kevin.page: so it seems we have a clear need for a directory resource/service, and RODL seems like the best place to put it (different users IDs could be reconciled threre)
[14:53:18 BST] kevin.page: dder: do we obscure/hash the URIs?
[14:53:20 BST] Raul Palma: yes
[14:53:48 BST] gklyne: Might consider: http://tools.ietf.org/html/draft-farrell-decade-ni (ni: URIs)
[14:54:26 BST] Raul Palma: will take a look
[14:54:31 BST] gklyne: What we haven't discussed is access control policy - centralized or distributyed?
[14:54:39 BST] gklyne: OK.
[14:55:03 BST] Raul Palma: http://www.wf4ever-project.org/wiki/display/docs/Access+control+policy
[14:55:17 BST] Raul Palma: initial ideas
[14:55:44 BST] gklyne: (I mention ed that because I think it may bear on the suitability of a central point like RODL for distributing user info)
[14:56:32 BST] gklyne: In AAA terms, this would be a PDP? (policy decision point)?
[14:58:18 BST] kevin.page: @raul: that looks like an access control policy that isn't distributed... it's just for RODL
[14:58:26 BST] Raul Palma: true
[14:58:38 BST] kevin.page: so a question is whether RODLs internal access control is derived from a Collab Sphere policy?
[14:59:50 BST] gklyne: I think it may come down to (1) get authz token, (2) access service ... or (1) access service, (2) handoff to federated authz, (3) get authz token ... ?
[15:00:23 BST] Rafael González-Cabero: someone is in its car?
[15:00:23 BST] Esteban García Cuesta: no
[15:01:01 BST] kevin.page: esteban: not working towards access policy
[15:02:22 BST] kevin.page: ... difference between visualisation metaphor and how it can be used
[15:02:29 BST] gklyne: Distributed access control can get tricky when using handoff to non-interactive services; e.g. Shibboleth doesn't easily handle this.
[15:03:43 BST] Piotr Holubowicz: @Graham: AFAIK both scenarios are valid for OAuth. The 1st is for web apps (interactive), the 2nd for others such as CLT
[15:04:03 BST] Piotr Holubowicz: Sorry, the other way round
[15:04:39 BST] gklyne: @piotr - I need to come up to speed on OAuth, but I thought it depended on being able to redirect a user to their identity provider.
[15:05:14 BST] Piotr Holubowicz: No - we are using OAuth with command line tools, and 1st scenario is applied
[15:06:13 BST] gklyne: Does it work like Kerberos... requires token-access logic in the client?
[15:06:23 BST] kevin.page: esteban: in near term, access policy not a priotity in collab spheres
[15:08:42 BST] Piotr Holubowicz: @Graham: it probably may, I'd need to check... I suggest we move it to another discussion :)
[15:09:24 BST] Stian Soiland-Reyes: I think I'll drop out as my connection is not very well today.. sorry
[15:09:33 BST] * Stian Soiland-Reyes left the chat (Unsubscribed).
[15:09:57 BST] gklyne: @piotr ack.
[15:09:59 BST] kevin.page: ok, so a need for a showcase to work out the what how policy for sharing (whether distributed or not) will be generated... what's the interface to build it?
[15:10:45 BST] kevin.page: push back to a discussion at the plenary?
[15:11:28 BST] gklyne: Even *using* data needs access control.
[15:12:05 BST] kevin.page: @gklyne: +1
[15:12:24 BST] gklyne: A key question is: what's the trust model?
[15:12:29 BST] Esteban García Cuesta: The access policy has to be at the physical level , infrastructure, data, services, etc.
[15:12:39 BST] Esteban García Cuesta: from down to up not the opposite
[15:14:24 BST] gklyne: @esteban security can't be top down or bottom up - it needs to be pervasive (cf. Ross Anderson dictum "Progamming Satan's Computer")
[15:14:55 BST] Rafael González-Cabero: something is wrong again with my connection
[15:16:01 BST] gklyne: Almost by definition, I think policy in collaboration spheres needs to be shared to some extent.
[15:16:49 BST] gklyne: q+
[15:18:06 BST] Esteban García Cuesta: rwx
[15:19:24 BST] gklyne: Here's the security model work I did for ADMIRAL - it's not very good, but it's something: http://imageweb.zoo.ox.ac.uk/wiki/index.php/ADMIRAL_LSDS_security_model
[15:22:34 BST] gklyne: http://www.wf4ever-project.org/wiki/display/docs/RO+checklist+evaluation+API
[15:23:37 BST] gklyne: http://www.wf4ever-project.org/wiki/display/docs/RO+dereferencing
[15:28:52 BST] Piotr Holubowicz: Commenting on access control: many users use Dropbox. If we can propose a similar policy (sharing individual resources with selected users) I think it would be a very good start
[15:32:29 BST] gklyne: @esteban - that last question from Kevin may be something to think about in the I&A components