Ok, we can restrict creation to policies relevant to the current machine 
only. In that case:
- we have policy creation only by services or users logged in to the 
current machine.
- no other machine can create a policy relevant for the current machine
The two points impair flexibility a lot, thus I did not think this far. 
Of course, Nina is right with the efficiency argument. I had in mind the 
situation where public access was prohibited prior to policy creation, 
thus no data would be transported. But I recognize this was 
short-sighted, and overall, I agree with your proposal to use 
DNS-verification.

One more (less important) question: We could also only forward DNS 
resolution, couldn't we? Are host names not available with the request? 
If yes, we could resolve both host names of requesting webservice and 
target webservice and check whether the two IP addresses match.

Greetings
Andreas


Luchesar V. ILIEV wrote on 06/28/2010 09:54 PM:
> On Mon, Jun 28, 2010 at 22:27, Luchesar V. ILIEV
> <luchesar.iliev at gmail.com>  wrote:
>> [...snip...]
>>
>> In other words, if the service gets a request for the resource above
>> from an address, which reverse-resolves to, say, badguy.aol.com, then
>> the policy service will reject the request straight away.
>
> That was ambiguous, sorry. Should have read instead:
>
> In other words, if the _policy_ service gets a _policy_creation_
> request for the resource above from an address that reverse-resolves
> to, say, badguy.aol.com, then the policy service will reject the
> request straight away (because badguy.aol.com !=
> serviceA.opentox.org).
>
> L.
>
> P.S. And, in the case of SSL/TLS, it would read:
>
> In other words, if the _policy_ service gets a _policy_creation_
> request for the resource above via a secure connection where the
> client certificate has been issued to badguy.aol.com, then the policy
> service will reject the request straight away (because badguy.aol.com
> != serviceA.opentox.org).
>
> Of course, if the bad guy doesn't present valid certificate in the
> first place (that is, issued by a trusted certification authority),
> then no connection would happen at all.
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>