[annotator-dev] Usernames and groups

[Mitar]

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