Thanks for the long thoughtful email. Some comments below. On Nov 12, 12:00 am, Mathijs <[email protected]> wrote: > 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)
These do match our permissions. > 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. This also matches our thinking. > 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". We actually implement this in a data document with a basic format of: <role participant="address">COMMENTER</role> (Actually the current implementation which is not in use and will be removed looks different.) This means we do not add any new operations to support fine grained ACLs. We avoid the race by modifying this data document first and then adding the participant. The assumption is that the data document ops are not reordered with the add participant op. This has not yet been formally confirmed with OT though. All our ops actually have an author associated with them. > 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 -~----------~----~----~----~------~----~------~--~---
