RE: Client policy processing

Earlier I suggested that it might be possible that a client could submit its policy to a server, and have the server return the intersection. At the time I suggested that the server might do this to avoid revealing its full policy - I wasn't happy with that as a use-case, though. I have since realised that there is a more convincing use-case for such behaviour - a low-powered client (telephone, PDA, etc) might do this so that it didn't not have to compute the policy intersection, particularly if the server offered a large and complex policy (one with a myriad of encryption options, for example). Having a low-powered client send its policy (probably fairly small) to the server and having the server return the intersection would be a practical solution. The low-powered client, as I suggested, knows what it "asked" for, and would not use any behaviours not included in the intersection the server supplied. Yes, this is asymmetric, but it seems quite appropriate when there's an asymmetry in computational power.
 
Someone (I'm sorry, I don't recall who) objected to this idea, saying that the client must be aware of the server's full policy, because there might be something very important in it. At the time, I was unconvinced, but I didn't have a good counter-argument. It has since occurred to me (I guess I think slowly!) that if something was very important to the server, it should appear in the policy intersection, or the intersection should be empty. If a server, for example, will refuse to serve anyone not complying with a particular behaviour, surely that behaviour must be present in any non-empty intersection?
 
Additionally, I stand by my earlier suggestion, that the server could also reject any request that does not comply. 
 
Tony Rogers
CA, Inc
Senior Architect, Development
tony.rogers@ca.com
co-chair UDDI TC at OASIS
co-chair WS-Desc WG at W3C