Policy Intersection : design or runtime

Hi

Perhaps this email can be considered off-topic.
I'd like to ask, do people see  the policy intersection being executed at the design time or runtime ?

The requestor initiating the intersection needs its own policy source so that it can match it against the provider's policy. I can see how a client (design tool) can obtain its own set of policy requirements at design time, from some sort of repository for ex.

What about runtime time ? Typically the client runtime would already be initialized with the provider service's contract (probably with the policy expression attached which passed the intersection check) before it will do the invocation on the provider's service. While talking to the provider's service the client may encounter new policy expressions, perhaps while processing those attached to dynamically obtained EPRs. 
I'm kind of find it difficult to imagine when and why the client will do the intersection at the runtime time. I can imagine that, when dealing with policies attached to EPRs the client runtime may consult some policy manager (which will do the intersection) on whether a given EPR is allowed to be used or not but is it what the main utility of interesction would be all about ? 

Can someone think of/describe the usecase/scenario where a runtime time intersection may occur ? Is intersection primarily a design time activity ? 

Thanks, Sergey 

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland