[annotator-dev] annotator-dev Digest, Vol 32, Issue 13

Wed Dec 11 19:30:20 UTC 2013

My two cents:

http://www.w3.org/wiki/WebID
more concrete example: http://my-profile.eu/
www.stample.co is working on a distributed authentication and privacy
control system.
It's a bit out of my technical scope, but if anyone's interested, I can
organise a remote conference thingy where we can talk with Henry Story
about the solution he's offering.

Dor

On Wed, Dec 11, 2013 at 1:00 PM, <annotator-dev-request at lists.okfn.org>wrote:

> Send annotator-dev mailing list submissions to
>         annotator-dev at lists.okfn.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.okfn.org/mailman/listinfo/annotator-dev
> or, via email, send a message with subject or body 'help' to
>         annotator-dev-request at lists.okfn.org
>
> You can reach the person managing the list at
>         annotator-dev-owner at lists.okfn.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of annotator-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Usernames and groups (Mitar)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 11 Dec 2013 02:01:11 -0800
> From: Mitar <mmitar at gmail.com>
> To: Randall Leeds <tilgovi at hypothes.is>
> Cc: "annotator-dev at lists.okfn.org" <annotator-dev at lists.okfn.org>
> Subject: Re: [annotator-dev] Usernames and groups
> Message-ID:
>         <CAKLmikOeKMd=
> 6hmQnTadVu7Dq_fgCBn1wW6m78Tb3gWA-cAMWg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi!
>
> On Tue, Dec 10, 2013 at 3:11 PM, Randall Leeds <tilgovi at hypothes.is>
> wrote:
> > Of course, the other approach is to lift all of this out of the
> annotation
> > itself and manipulate n ACL as a separate object with its own API. The
> data
> > of the annotation, then, never crosses a server boundary in a federated
> > environment. It is purely local.
>
> You mean, ACL data for the annotation then never crosses the boundary
> in a federated environment. Probably we want annotation data to be
> federated. ;-)
>
> As I said, I think this is not good from usability perspective. If
> distributed and federated system want to compete with centralized
> cloud services we have to make usability seamless. When you block all
> users in one system, then you can assure that privacy and permissions
> are respect everywhere inside your system. Being this shared on
> YouTube, Google+, Google Scholar, Google Docs ... But if hope to open
> this data and not close it into silos, we still have to assure that
> user experience feels the same. For authentication there are some
> solutions like OpenID and Persona. And for permissions something
> similar is needed. I agree that maybe we are not the right group to
> design something like this, but we should definitely have to keep it
> in mind. This is why I asked the initial question. I hopped that the
> permissions are part of to me unknown standard for exactly this. I am
> sad to learn that this is not so.
>
> Because past distributed systems like Usenet and e-mails were maybe
> distributed, but they were completely lacking any permissions and
> identity control. You can pretend to be anybody and can manipulate
> content in the name of anybody.
>
> What we have to think about is to keep such federated model, but we
> have to introduce permissions and privacy controls as well.
>
> Maybe projects like Diaspora, XMMP and pump.io addressed this in some
> way already?
>
> > If (I believe this is an if, and not a
> > when) there are common interface components around manipulating the
> > permissions of an annotation (or really any web resource), then a
> standard
> > would be useful.
>
> Yes, I like the idea of general standard of permissions on web
> resources. Web is already a distributed system. We might attach
> permissions on top of that as well.
>
> > So, to clarify, by "code over discussion" I mean you should probably do
> whatever you want. It's not likely to matter in the
> > short to medium term.
>
> Yes, I see now. I was hoping that this is already something existing.
>
> > In fact, diversity here may be helpful for avoiding a local maximum down
> the road. There's no need to agree at this time.
>
> Yes. But we should think that in the longer term we do need
> interoperability on permissions as well. I hope you agree with that.
>
>
> Mitar
>
> > I'm going with the URI-ish approach for now, but I think storing
> permissions
> > in the annotation is ultimately a bad idea.
> >
> >
> > On Mon, Dec 9, 2013 at 8:38 PM, Mitar <mmitar at gmail.com> wrote:
> >>
> >> Hi!
> >>
> >> I mostly agree. I am posing this question just to now throw this idea
> >> away by default, which  I almost did when I was thinking about it
> >> myself.
> >>
> >> Because I was thinking about use cases. And imagine we have a
> >> PeerLibrary where people can annotate scientific publications
> >> (http://peerlibrary.org/) and we federate with others providing
> >> annotations. Then when a user users PeerLibrary it would be great to
> >> be able to display existing his annotations and allow the user to
> >> interact over them. Even more, if annotations are collaborated upon, a
> >> group work, it would be great if users would be able all to use it
> >> anywhere they are. Just imagine that you have a common pool of
> >> annotations and different clients for different platforms. What would
> >> be amazing is to be able for users to use different clients/platforms,
> >> but still be able to work on same common resource.
> >>
> >> So in a similar way to selectors, where by defining common schema how
> >> we store targets we can allow easier federation, we might decide to
> >> just agree on a common schema for permissions. If clients/platforms
> >> then take care to map those permissions to local permissions or not is
> >> another issue. Same as if they want to map author to local author.
> >>
> >> But it is just an idea and poking community a bit, for temperature
> >> check. If there is no interest then nothing. :-)
> >>
> >>
> >> Mitar
> >>
> >> On Mon, Dec 9, 2013 at 1:41 PM, Randall Leeds <tilgovi at hypothes.is>
> wrote:
> >> > On Dec 8, 2013 5:03 AM, "Mitar" <mmitar at gmail.com> wrote:
> >> >>
> >> >> "Hi!
> >> >>
> >> >> Are those permissions which are done by Annotator (the extended ones,
> >> >> which have things liks "group:__world__") based on any standard? How
> >> >> could we assure interoperability between systems? So that if we
> >> >> federate annotations among systems there would be a way to map
> >> >> permissions as well?
> >> >
> >> > No.
> >> >
> >> > I haven't been tempted to raise the standardization issue because I
> >> > assume
> >> > access control can be delegated, and assumed local, to the repository.
> >> >
> >> > I might argue that it's not really a property of the annotation, but
> >> > local
> >> > server metadata. I'm not aware of anyone in the Annotator community
> >> > enforcing authorization outside of the HTTP API layer, which means
> it's
> >> > not
> >> > really annotation data but a property of its particular representation
> >> > at a
> >> > particular web resource. If it moves to another server, through some
> >> > federation protocol, it would be subject instead to the authorization
> >> > logic
> >> > of that host, which may or may not have access to the relevant group
> >> > membership information or be able to authenticate the principals
> >> > mentioned
> >> > in the ACLs.
> >> >
> >> > I don't think it's sane to pursue interoperability here.
> >>
> >>
> >>
> >> --
> >> http://mitar.tnode.com/
> >> https://twitter.com/mitar_m
> >
> >
>
>
>
> --
> http://mitar.tnode.com/
> https://twitter.com/mitar_m
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> annotator-dev mailing list
> annotator-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/annotator-dev
> Unsubscribe: http://lists.okfn.org/mailman/optionss/annotator-dev
>
>
> ------------------------------
>
> End of annotator-dev Digest, Vol 32, Issue 13
> *********************************************
>

-- 
Get some insight of what makes me tick:
My twitter <https://twitter.com/#!/garbash>
Knownodes mailing list <https://groups.google.com/forum/#!forum/knownodes>

Dor Garbash
108 Rue du faubourg du temple, Paris 75011
+33-652919878
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20131211/aa2d2269/attachment-0003.html>