[annotator-dev] Reading about authn and authz

[Jamie M Folsom]

Hi Folks,

>> I agree with the article in that I imagine these two methods provide
>> enough flexibility to implement most types of control mechanism including
>> groups. So, I wonder if the problem lies more in the documentation not
>> being clear in how these different systems could be implemented or even
>> that there is possibly significant work involved for the consumer to
>> implement these hooks.
>> 
> 
> I think it may just be documentation. It also might be that we should
> change the expand the userAuthorize function in a backwards-compatible way
> by accepting either a userid or an Array of principals.
> 
> Then I think we'd more or less have group support for free.

Agreed all around. I really like the simplicity of how the annotator manages permissions, and the clear separation of concerns. Since users are handled by the implementing application, it’s in the configuration of the annotator that most of the work is done to implement groups. In light of that, I agree that additional documentation is likely the key next step, and I will help on that.

A few bits of context. First, an excellent overview of the group schemes that one might want to implement, compiled by Dan and Jake (https://docs.google.com/document/d/17HDaujAt5P9o5x2Yinr8jL_tZS_3Zd36VBYbpPz-bkM/edit). 

I have copied the list of “possible variations” from page one. Nick has said that he doesn’t see anything on that list that can’t be implemented with the current permissions mechanism.

Visibility of annotations:
	• Public: Annotations are visible to everyone.
	• Private: Annotations are visible only to members of the group. 
	• Moderated Public: Certain annotations that have been moderated by an administrator are visible to the public, the rest are private to the group. 

Membership access
	• Open: Anyone can join the group 
	• Restricted: Anyone can request to join the group. 
	• Closed: Members have to be added by an administrator. 

Membership Visibility
	• Public: Outsiders are able to see who is a member of the group.
	• Private: Outsiders cannot see who is a member of the group. 
	• Optional: Users can choose whether people can see if they are part of a group.
	• Private Admin-only: Outsiders cannot see members. Members cannot see eachother, only admins can. (Useful as a peer-review mode).

Participation
	• Voluntary: Group members can choose whether they are a member of a group or not. 
	• Involuntary: Members have no control over whether they are in a group or not. Example: Lists on Twitter. 

That doesn’t mean that it’s obvious how one would implement any combination of values from those sub lists, especially assuming a wide range of different user/authentication backends (every application does it somewhat differently). So here’s my proposed outline for how to proceed. Let me know if this makes sense.

https://docs.google.com/document/d/1Pp6Q7PGS4rLykyZOivlnhVF2DVkEY77QPfcpl_jWqUU/edit

I am happy to lead on the documentation piece, and if people like the idea, the configurator.

Thanks,

Jamie




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1579 bytes
Desc: not available
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20140407/9b99c814/attachment-0004.bin>