Sorry for the delayed response Tad. As I'm sure you're aware the access control white paper is more of a design idea than an actual specification. We've yet to implement it properly for our federation servers even if have some of it implemented internally.
I'll try to answer your questions below and please forgive me if I misunderstand anything. On Wed, Feb 3, 2010 at 1: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. Yep, that's it. > 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. Yes, this is obviously quite expensive so should generally be avoided. We want the WRITE edges to be primarily used inside a wave provider for alternate addresses. For example I could have a canonical address [email protected] but also WRITE edges to [email protected] and [email protected]. Slightly related to this is that we have also been discussing "hidden" and "open" authorization path edges in a delta. If I for example submit ops with an account of [email protected] but I'm on a wave as the participant [email protected] I don't necessarily want to disclose my canonical address. In this case the tirsen -> jon.tirsen edge in the delta would be marked as hidden, authorized by the wave provider which removes the hidden edges before signing the delta and making it part of the wave history. It would seem that hidden edges can only be made to work between addresses in the same wave provider. > 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. Yeah, when the wave provider bar.com creates and edge [email protected] -> [email protected] he needs to public this wave to foo.com. [email protected] would most likely need to be a read-only participant of the wavelet containing this edge. The way want this to happen is that each wave provider indexes all access edges for each external address that has an inbound edge to local addresses. These are all denormalized into one wave per external address and then published to that external address. The foo.com wave provider then needs to index and denormalize all these edges again into one wavelet containing all access edges for [email protected]. > 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. I think I'm either misunderstanding your question or I've simply written incorrectly about the GRANT edge in the white paper. The GRANT edge is for third party addresses and is only required for the target of the access edge. So in order for [email protected] to create the edge [email protected] -> [email protected] he needs a GRANT edge to [email protected]. A GRANT edge to [email protected] is not required. I think the chicken-and-egg problem is "Who can great the edge [email protected] -GRANT-> [email protected]?". Well, we're kind of cheating there. The GRANT edge is only authorized by the wave provider at delta submit time. If incoming edges to [email protected] is encountered at wavelets with the bar.com domain then the bar.com wave provider is expected to have made the proper authorization of that edge before signing the delta. Given that the wave provider at bar.com can simply create edges authored by some super user. How this would probably work is that when a user creates a group at a wave provider the system would automatically create the initial GRANT edge to the user that created the group. Given that the creation of access edges aren't authorized across wave providers it seems likely we would not need to standardize this and simply leave the authorization of access edges wave provider specific. > 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. Ah yes, I think you've run into an open question with how federated groups would work with the federated wave protocol. We do need the ability to search a groups archives on a remote wave provider. I have a few ideas on how to support this without requiring significant extensions to the wave federation protocol but it's still a bit too early to talk about this. Hopefully this answers some of your questions. > > -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. > > -- 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.
