[annotator-dev] Usernames and groups

Tue Dec 10 23:11:56 UTC 2013

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/19660b94/attachment-0004.html>