On 1/30/08, Brian Eaton <[EMAIL PROTECTED]> wrote: > > OK, I think the answer to this question is that the container and the > gadget server need to collaborate closely. If the gadget server has > enough information to validate and decrypt the security token it is > already tightly coupled (sharing keys) with the container. They need > to have a common understanding of policy as well. > > There's more than one way to pass that policy information between the > container and the gadget server. Depending on how much information > there is it might fit into the security token, or you might want to > have them share a backend data store that they use to reference > policy. > I think I'm staring to get it. Still, there may be situations that the permission to view the viewer information is obtained client side (so neither the container nor the gadget server have any knowledge of this) though opensocial.requestPermission. I can imagine that in quite some implementations, this call will pop up something on the container-page (through rpc/ifpc) asking for permission to send viewer data to the gadget. As I come to think of it, if you don't want to route your opensocial dataRequest calls through ifpc to the container page, you're going to need some extra token there to let the dataRequest call know that permission was obtained. This same token can (should?) then be used to let the gadget server know that the gadget has access to the viewer information.
I'm actually not quite sure on how much of the requestPermission has already been implemented in shindig; perhaps I'm just stating the status quo here.
