Has anyone at Google read this? The first part is mainly a question of clarification, but the rest covers what appears to be a serious chick-and-egg problem.
-Tad On Tue, Feb 2, 2010 at 6:09 PM, Tad Glines <[email protected]> wrote: > I was reading the access control paper and want to make sure I > understand how it is intended that this should work. > > Given the access edges: > [email protected] -> (READ, INDEX, ADD_ME) -> [email protected] > [email protected] -> (READ, INDEX, ADD_ME) -> [email protected] > > And that [email protected] is a participant of wavelet example.com!ExAmPLe > > Then the sequence of steps to add joe as a participant would be: > 1. Joe creates a delta with an AddParticipant([email protected]) operation, > sets the delta author as [email protected] and sets the address path > as [[email protected], [email protected]]. > 2. Joe sends the delta to foo.com > 3. foo.com signs the delta and sends it to bar.com > 4. bar.com verifies the foo.com signature, verifies that joe still has > ADD_ME access to group1 and then signs the delta and sends it to > fizzle.com > 5. fizzle.com verifies the foo.com and bar.com signatures, verifies > that group1 still has ADD_ME access to group2 and then signs the delta > and sends it to example.com > 6. example.com verifies the foo.com, bar.com and fizzle.com > signatures, verifies that group2 is still a participant of wavelet > example.com!ExAmPLe and then performs the operation. > 7. example.com sends the applied delta to all participants servers. > > Once joe is a participant, then he sends deltas to foo.com which will > send them directly to example.com. > > If on the other hand the access edges where: > [email protected] -> (READ, INDEX, WRITE) -> [email protected] > [email protected] -> (READ, INDEX, WRITE) -> [email protected] > > Then joe would not perform an AddParticipant, but would submit > document operations and all deltas would have to pass through all edge > address servers. So each delta would have to go through steps 2-7 > above. > > The thing that still seems a bit fuzzy is how access edges are > created. The access control paper states that each account would have > a special wave associated with it's cannonical address that contains > all edges associated with that address. And implies that this access > wave's contents would be obtained by indexing the content of other > waves and parsing our any access edge document. But it says nothing > about how a server would become aware of access edges added to waves > for which it has no participants. For example how would foo.com know > that joe has been granted READ, INDEX to [email protected] if foo.com has > no participants of any wave hosted by bar.com. Is it assumed that wach > group would have an associated wave where access edges are added and > the members are made participants. Or is there to be some other > mechanism for communicating access edges. > > Also, there seems to be a chicken-and-egg problem.The access control > paper states that an access edge is not valid unless it is contained > in a document operation performed by an address that has the GRANT > access to the grantee address. For example, in order for > [email protected] to create the access edge "[email protected] -> (READ, INDEX, > ADD_ME) -> group1.bar.com", group1 would need to already have the > access edge "[email protected] -> GRANT -> [email protected]". Joe cannot > create that edge because he would need "[email protected] -> GRANT -> > [email protected]". The edge graph WRT GRANTs has to be bootstrapped > somehow. > > One final question: In the situation where [email protected] has READ access > to a wavelet via access edges, but that wavelet has no direct > participants from foo.com, how would the wave host know to send deltas > to foo.com. Is it assumed that each server will send deltas to not > only the participant's servers but also any server identified from the > wavelet's edge graph? Or is it assumed that the group's server (e.g. > [email protected]) would forward the deltas to the servers of it's group > members? Neither seems optimal but the former would at least avoid the > case where a server is getting the same delta from several other > servers due to group memberships. > > -Tad > -- 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.
