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.
