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

Wed Dec 11 20:26:44 UTC 2013

Thanks!

Dug into the stample docs and found http://www.w3.org/wiki/WebAccessControl
Didn't know about it. Very helpful.

On Wed, Dec 11, 2013 at 11:30 AM, dor garbash <dor.garbash at gmail.com> wrote:

> 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
>
> _______________________________________________
> 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/ccb9bd27/attachment-0004.html>