[annotator-dev] Usernames and groups

[Mitar]

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