[annotator-dev] Usernames and groups

Wed Dec 11 15:49:10 UTC 2013

I agree with Randall.  If an Annotation (or any web resource) requires
authentication and/or authorization, then it cannot be meaningfully
federated except within systems protected by that same auth system.

As soon as something is federated outside of its home domain, no amount of
description of ACLs, users, groups and permissions will prevent a system
from ignoring all of it and just making it openly available.

The answer is, clearly, don't do that then :) and just allow annotations to
be either open and federated, or private in a single, trusted location.

Rob

On Wed, Dec 11, 2013 at 3:01 AM, Mitar <mmitar at gmail.com> wrote:

> 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
> _______________________________________________
> annotator-dev mailing list
> annotator-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/annotator-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/annotator-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20131211/3d6966cb/attachment-0004.html>