[annotator-dev] Usernames and groups

Tue Dec 10 23:14:27 UTC 2013

In fact, diversity here may be helpful for avoiding a local maximum down
the road. There's no need to agree at this time.

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

> 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/949bdcb3/attachment-0004.html>