Web Annotation Working Group telco

<azaroth> RESOLUTION: Teleconference minutes from 6 May 2015 approved, see

<azaroth> http://www.w3.org/2015/05/06-annotation-minutes.html

Protocol: Authentication Requirements?

For the protocol Requirements for authenticatoin and authorization. For model, look at annotation sets and ordering of list.

zakim: ^^

zakim: On the use cases on which of the possible ways to ordering.. actually as the.. (?)

(sorry, I'm mixing up nicks with z)

azaroth: ..also any cross-over work with social networking group
... how does authentication relate to the protocol?
... working on the protocol draft, there was no mention of authentication or authorization
... we would not want a protocol where anyone can mess with anyones annotation
... so we would need to address a&a
... discussion about the proposal (?), brainstorm, requirements, how it is in your own systems
... interactions between clients and server via (??)
... @paoloC - what are the Domeo requirements?

paoloC: We started some time ago with working with pharmaceutical companies, which have 3 requirements
... we integrated with LDAP for users/groups
... both needed
... step 1 was to include an API key, a low-level entry, to detect the client, and system just trusted client
... then moved to OAuth
... retrieve users through LDAP on server and client, and use OAuth for authentication
... the LDAP is just the way we retrieve the user.. the authentication layer is separate

TimCole: Do we need a authentication protocol? Finding a way that the annotation are associated with a user. Not trying to get into how the user is determined

paoloC: there are two issues - the model is already including Who created the annotaion.
... so technically the OAuth should check the credential against the payload
... or the payload might not include author, this can be added by server
... obviously the annotatoin includes the author already, so the requirement could be light.. communication should happen through an authenticated layer and check annotation against it
... this works unless you allow users to send in annotatipns made by other people
... this might sound weird, but I might want to enter an annotation that is said by someone else
... so he is the Author, but I am adding the Annotation

(e.g. Creator vs. Author ?)

azaroth: so as a first step.. (?)

<paoloC> yes, Stian, in fact I was using PAV for that

shepazu: another similar thing where there might be more than one person annotating under the same username
... I don't think it's a huge deal
... who has logging credentials.. provenance can be different

accounts vs people

<azaroth> scribenick: azaroth

Stain: Have a lightweight requirement, hard to determine author vs annotator
... permission schemes are hard and could be out of scope
... rely on existing mechanisms, server specific

<bigbluehat> +1

<scribe> scribenick: stain

azaroth: could paoloC tell us more about the OAuth workflow?

paoloC: we use libraries that does OAuth, and then OAuth combines the API Key of the client and a secret key of the user, which generates a user key for the transaction.. this expires now and then so you have to handshake again

azaroth: right, that workflow of the key exchange

paoloC: that comes down to the technology used.. there is usually machinery for that
... all you need to do then is to match the key to the person
... but if you have to implement OAuth yourself as a provider, then it's a bit more work!

TimCole: (?) read authorization? Who is authorized to read an annotation vs. update or delete

my apologies

TimCole: what do we need to add to the protocol to support that basic level of authorization?
... (?)

<paoloC> Example of permissions (derived from Annotator) https://github.com/Annotopia/AtSmartStorage/wiki/Model-Permissions

paoloC: I think that's a good point.. when we start with Annotopia I looked at Annotator which says what is possible or not.. I added just one think
... in Annotator you can say Who can read it, update it, delete, admin it. Users and groups. In Domeo I also added Comment.
... if you think of cases where you do not want comments.. e.g. say CNN might shut down comments on a particular article
... and I wanted a similar feature.. you can read this annotation.. you can't edit or delete.. and you can't comment on it
... but of course in the open world assumption anyone could annotate it
... but you could refine this better.. the actual authentication technology is probably more temporal, OAuth is popular right now, but who knows in 5 years

shepazu: another permission is to Share
... I'm not sure we mentioned that.. and what does it mean?
... If I Share it.. am I just republishing? Can I change something? Or can I just say what *I* say?
... sharing is kind of quoting.. you might want to permit sharing without edit

<paoloC> share or embed?

<paoloC> that is related also to copyrights?

shepazu: I don't think this works too well for aggregation and confededatoin
... tumblr model
... you can put something someone else wrote onto your feewd
... twitter and retweets
... which is an important functionality
... sharing should be cross-service -- e.g. pinterest shared on twitter
... the provenance should be observed
... we've not talked about this in depth
... if we have what paoloC said, the ability to say "You can't comment on this", first of all I disagree about that philosophically as a use-case
... but acknowledge there are some use-cases
... it troubles me.. but I don't think we should define that capability (?)
... but in permission models there could be "Don't share this"

paoloC: I think this is a good discussion.. technically when an annotation is public, you can read it
... as Benjamin was saying, if you can read it, sharing is automatic
... another thing is copyright.. who owns the copyright on sharing? Embedding? Other things?
... say Twitter, the model is simple, once you tweet, anyone can retweet it and embed it
... if the annotation keeps it all open, then .. Let's say an annotation is public, technically you can retrieve it
... if is available only to a group, but you share.. what does that mean then?
... is it then only available still to the same group?
... this gets complicated!

(Google+ syndrome!)

paoloC: another example is the Non Comment. That is why I was myself sceptical.
... In this environment, I would not want people to comment on it. Of course globally it can be broken.
... not sure how that would play out

<Zakim> azaroth, you wanted to distinguish license for reuse and authorization to modify in place

azaroth: looking at what paoloC said.. at what (?) is this being used
... from authorization requirements
... (?) authorizatoin and permissions are keys.. and what can I do with this? Like a license.
... e.g. you can share, etc.. but you have to tell me

<shepazu> http://www.canyoucopyrightatweet.com/

azaroth: this sounds distinct from permissions on the annotation

<paoloC> I am not sure 'copyright' is the right term

<azaroth> Stian: +1, can they be shared is more advisory. Part of the annotation description and model.

<paoloC> I am referring to for instance a CC model

<azaroth> ... Trying to model the sorts of things there is difficult. More like advisory in the open world.

<azaroth> ... Can't comment is definitely possible at an individual server level, e.g. you can't do this here

shepazu: I think that summarized it well. The azaroth was right with license. Leave it for the most part of up to the sytem how it enforces the license or not.

<paoloC> +1

<azaroth> +1

shepazu: not a technological way

+1

<TimCole> +1

shepazu: on the other hand I feel like the protocol should explicitly say something about Sharing
... I think it should be one of the verbs

(stain:.. or is Sharing just a Meta-annotation?)

<bigbluehat> huge +1 for collaborating with Social on AS 2.0 for sharing

azaroth: (?) Social

(audio from azaroth is very small-room-ish.. )

<Kyrce> +1 to collaborating with Social Media as well.

Matt_Haas: from an education public PoV this is important.. student and teacher. Ability for that dynamic. Role might not be right to describe Teacher and Student.

<azaroth> azaroth: Should collaborate with social web working group on the sharing aspect as closely related to the activity streams work

(thanks azaroth )

TimCole: it sounds like what will happen is that the service is going to enforce a lot of these limits
... who can edit, update, delete
... what does the protocol need to do..
... can the protocol allow for the LDP Container to express "annotations who lives here are governed by this license, and this policy for reading, this for updating, etc"
... a container could say Bob and Doug is allowed to update, etc.
... and reuse according to CC-BY license

azaroth: good point, TimCole

<tbdinesh> +1 TimCole

azaroth: distinction between permissions on containers, and on annotations and results

<Kyrce> +1 TimCole

<davis_salisbury> +1

<bigbluehat> +1

azaroth: if permission and authorizatoin was associated with containers, and all in that container were by that requirement.. would that be sufficient? Or should an individual annotatoin carry this?
... Benjamin has something along those lines (?)

<Zakim> azaroth, you wanted to discuss container vs annotation scoping

bigbluehat: we've been looking at container based access permissions the way the Annotator store annotations know, we do what paoloC mentioned earlier on the Annotatoin Package we send the Annotator
... the disadvantage for federation then is huge, as people need to read the access regulation and abide by the rule on the annotation
... if it's by box, then it's much easier to federate as you don't nee to check each annotation on the way out
... cleaner federation stories, containers can live all kinds of places and move around the web with the same content
... you could make things that took annotations out of one container and put it another to share it with another group
... and then get particular permission systems per container

paoloC: this is an interesting point, going down to implementation. We have it on the Annotation level
... but we use Annotation Set, and so what we really do is to check permission on the set level, e.g. the same about the container
... but in our system each container carry their own permissions
... specially if it contains multiple annotations with the same
... but I'm not sure about the real benefit otherwise.. philosophical point
... so every container will need to go with it.. permissions.. etc
... if each annotation is shipped with the container, that is probably the way to go

tbdinesh: what we do in the SweeT (?) case, every one that goes out.. (?) -- you can only see per container
... you can choose where your annotation gioes
... (?)

<azaroth> Stain: For the annotopia case, keeping it on the container level is simpler, the container should enforce the permissions as its configured

<azaroth> ... makes things more complicated for the client

stain: it is more complicated for the client if it is forced to figure out which permissions to set

azaroth: (?) We have an LDAP service where we use OAuth
... with the token to the client
... token to the annotation server each annotation is a message that is sent to the container and the its up to the container to merge or consider it as an edit of the earlier one.
... (?) We went for a single group with each container
... so anyone in that group can access and modify annotations in the container
... (?)
... so in case of the permissions on the container, if we agree that is the way to go.. then.. license can be associated with the container (?)

(my apologies, I can only hear the reverb of the room)

azaroth: thanks for this discussion

Model: Ordering in Annotation Lists

no

azaroth: from this about the protocol.. what we should add.. license under which an annotation can be reused.
... we should enable on container-level initially
... permissions (??)
... we should work with Social Media WG on this
... OAuth pattern seems valuable to mention

<TimCole> +1

azaroth: is that summary reasonable?

<tbdinesh> +1 azaroth

paoloC: so we are just settling on the Container that has to exist..? Is that what you are saying?

azaroth: so I heard that we should try to do it at container level first
... if we end up including it per annotation.... (?) each annotation has a container?

paoloC: as I was explaining Annotation Set earlier, I mentioned it can be used both as Grouping By Task, or by Grouping By Restrictions
... those can conflate.. and complicate
... I don't know how you would handle that in our container model
... e.g. 10 annotations in the same task with different permissions
... would that be two containers (task/permission)? One single? Then which annotatoin has which permission?
... working at container level.. if I understand.. can also be used to group annotations

<Kyrce> +1 paoloC

azaroth: I would treat the Container as the Service to which the client would use
... there could be a separate annotation (?) that includes it in a task

paoloC: so we are asking if the model level or protocol level.. to ask to have 3 levels.. one container for Set, one for Permission.. and one for (?)
... I understand it's easier to apply the permission, but it sounds to me more complicated

shepazu: could we model this as saying there could be a Container which is an Annotation of 1
... a container can contain Any Number of Annotations, e.g., 0, 1, 2, 1000

azaroth: shepazu that does make sense.. one container pr annotation
... do continue the discussion on the mailing list
... we do NOT meet next week
... regroup on 2015-05-27
... with internationalization group