Re: [ogpx] Protocol for permitting policy decisions

I actually kind of defy anyone to impose a policy on a separately hosted 
remote service. Policy is enforced locally, Attempting to make other 
software components obey a
policy you have is pretty much a non starter. You can request they do 
things, and you can insist they exhibit certain properties when choosing 
to interact with them, but
you get no say in their workings.  (Yes, there are systems with remote 
policy execution engines and such, but they still don't impose the 
policies on the services which use
them, the services chose to invoke them)

- David
~ Zha

Morgaine <morgaine.dinova@googlemail.com> 
Sent by: ogpx-bounces@ietf.org
10/09/2009 12:10 AM

To
"ogpx@ietf.org" <ogpx@ietf.org>
cc

Subject
Re: [ogpx] Protocol for permitting policy decisions

On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <carlo@alinoe.com> wrote:

Morgaine,

I'm pretty sure nobody on this list wants AD2 to be involved in anyway.

Yes, I think that everybody agrees with this, which is why I'm making sure 
that the implications are understood.

I am highlighting this point of logic very strongly so that it is clear to 
everyone that if we don't want AD2 to be consulted, then AD1 cannot be 
allowed to express region policy.  AT ALL.  EVER.  UNDER ANY 
CIRCUMSTANCES.

Because if AD1 is allowed to, then so is AD2, and hence AD2 will have to 
be consulted, :-)

I hope we can end this here with total agreement. :-)

I will however be referring back to this point if someone tries to give 
AD1 the power to set region policy over RD2.  If that happens, then we're 
back to consulting AD2, no alternative, because W2 is not in any way 
inferior to W1.

It's a crucial point, because it establishes a limit to the power of an AD
.  Think of it as a mini Constitution. ;-)

Morgaine.

===================================

On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <carlo@alinoe.com> wrote:
On Thu, Oct 08, 2009 at 10:41:54AM +0100, Morgaine wrote:
> Magnus,
>
> If ADs are involved in region policy, then in the multi-world deployment
> pattern, AD2 will have to be consulted when agent A1 teleports from RD1 
to RD2,
> because AD2 will be involved in region policy too.  It's symmetric with 
AD1.

Morgaine,

I'm pretty sure nobody on this list wants AD2 to be involved in anyway.
I'm also convinced that there is some misunderstanding involved here,
and it would be good to correct that...

The following isn't consensus yet, but I feel it's basically the truth,
and written down here as such because at least it is simple:

In the end there are only services. Services can be grouped as 'domain'
to make clear they are run by the same authority and therefore likely
will have use the same policies, but for the sake of the protocol you
can ignore that.

There are several types of services, so far we only concentrated on two
types:

1) A region (R1, R2, ...)
2) An authentication service (A1, A2, ...)

in principle, every service can be run by a different authority and thus
have different policies.

One user only uses a single authentication service at a time, every other
authentication service is not relevant (for that user).

If a user wants to teleport from R1 to R2, while using A3, only A3 and R2
have a say in this.

The only say that A3 has is true or false: yes or no allow the user to go
to R2. Once the user gets into R2, no policy of A3 matters anymore.

It makes no sense whatsoever to group A's with R's for the sake of 
understanding
or designing the protocol.

For a teleport decision (or initial connect) only ONE Agent service and 
ONE
region are involved.

Almost every policy (of both parties) can be negotiated out of band,
yet some of us (including me) are arguing that we need to keep the 
possibility
open for a region to change some abstract policies (based on trusted 
information
from the agent service) more real-time. Here trust is needed in both 
directions:
the region must trust the agent service to answer it's questions correctly
and the agent service must trust the region not to fool it into allowing
users in that the agent service based on it's own policy doesn't want to
allow in.

--
Carlo Wood <carlo@alinoe.com>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx