Great, a datadoc is indeed a far better place. That way users can see what their role is too without additional modifications, and I can put in meta-info about the acl model in use for the wavelet.
Thanks On Nov 12, 12:59 am, tirsen <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
