[annotator-dev] Usernames and groups

Tue Dec 10 23:13:10 UTC 2013

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.

On Tue, Dec 10, 2013 at 3:11 PM, Randall Leeds <tilgovi at hypothes.is> wrote:

> I think this is one of those places where I would prefer to see code over
> discussion.
>
> For our part, at Hypothes.is, I adopted
> "acct:<username>@<identityprovider>" for user principals and kept with
> "group:<groupname>" for groups, with "__doubleunderscore__" being reserved
> (e.g., "group:__public__").
>
> The "acct:" comes from proposals originating in the WebFinger community.
> There's ongoing debate on whether it's useful or not. I like it because it
> makes everything "URI-like", which reduces the potential for some kinds of
> collisions or confusions, such as mis-parsing a user whose name starts with
> "group". The first step is *always* to split on the colon character.
>
> Also, there's been some activity in the W3C around WebID. In accordance
> with their web-centric view of all things WebIDs are URLs of documents.
>
> WebFinger is all about resource discovery: given a short <user>@<host>
> string, find the URI of (profiles, services used, homepage, etc). So,
> naturally, a WebID might be linked from a WebFinger profile, which is
> locatable as a .well-known URI constructed from the WebFinger identifier.
> The community has at times rendered these as "acct:", but dropped it from
> the spec to keep it simple.
>
> I happen to like "acct:" for the reason above. It means we don't really
> have to care about federated identity. Identities (or principals) are URIs.
> The task of resolving them to profiles, discovering identity provider
> details, or authenticating them can be different depending on their scheme
> or the document they ultimately resolve to.
>
> 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. 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.
>
> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20131210/49d868e8/attachment-0004.html>