Hi all, I'm in the process of implementing a more fine-grained access control mechanism for use within wavelets. Inspired by the "confidential" and "commenter" roles that are mentioned in the access control whitepaper, I came up with the following:
Basic permissions: - read (a participant is allowed to read data the wavelet) - append (a participant can add blips to the wavelet, but not modify existing ones (including his own)) - edit_self (a participant is allowed to edit his own blips, but not those of other participants) - edit_all (a participant can edit any blip in the wavelet. - add_participant (a participant can invite others to the wave(let)) - remove_participant (a participant can remove participants from the wave(let)) - change_access (a participant is allowed to change the wavelet-access permissions of other participants) With these I define 4 "roles" (which are mainly used to ease up the interface and not used internally): - creator = all above permissions (full access, given to initiator of the wave) - writer = edit_all + append (so write the wave, but don't be involved in managing participants/permissions) - commenter = edit_self + append - reader = read All roles can be accompanied by the "add participant" permission which allows participants to invite others. When inviting someone, the new participant will at most get the same permission as the inviter. So if a commenter adds a participant, the new participant can be either reader or commenter. Also, if a participants uses his ADD_ME permission (address access edge), he wil have the same permission as the participant to whom he has ADD_ME. (So if I add participant "group b" as writer, members of group b who use add_me to add themselves to the wave, wil be writers as well). That's the concept of it. Obviously to implement this, I will need to extend the current protocol a bit. I know google hasn't confirmed anything other than what's in the whitepapers, so I know I'm somewhat on my own. The reason I'm bringing this up, is that I don't want to shoot myself in the foot when google finally releases specs about acl-like issues. So I want to go with a solution/extension that will first just be used between my own servers, but when google takes some steps in this direction, I want to make sure I'm at least somewhat compatible and I mostly have to map my permissions on the new types. I can extend the "add participant" operation to optionally carry permissions (so I can add someone as commenter). "add participant" without a permission will just add a participant and give it the same permissions as the author of the "add participant" operation. This sounds like a sane default to federate with waveservers that don't have this extension in place. I will also need a "change participant permissions" operation to change permissions afterwards. Now I hoped I could skip the extension to "add participant" and just use "change participant permissions" after adding someone (more atomic), but this would make it very difficult to verify the operation since someone might have the permission to add others (and choose their initial permission), but not to modify it afterwards. Also, keeping track of who added who feels like overkill, so I think I'll settle on the new operation + extension of "add participant". I would like to hear some opinions on this subject. Did I miss something? Can I make some parts easier? My goal was to be as fine-grained and atomic as possible to later be mappable to any official standard. Did anyone else already come up with a similar idea? Thanks, Mathijs --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
