See also: IRC log
<azaroth> RESOLUTION: Teleconference minutes from 6 May 2015 approved, see
<azaroth> http://www.w3.org/2015/05/06-annotation-minutes.html
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
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