Re: [ogpx] Protocol for permitting policy decisions

[Vaughn Deluca <[e-mail]>]

Yes, this all sounds good!-Vaughn


On Fri, Oct 9, 2009 at 6:16 AM, David W Levine <[e-mail]> wrote:

>
> 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 <[e-mail]>*
> Sent by: [e-mail]
>
> 10/09/2009 12:10 AM
>   To
> "[e-mail]" <[e-mail]>
>  cc
>   Subject
> Re: [ogpx] Protocol for permitting policy decisions
>
>
>
>
> On Fri, Oct 9, 2009 at 12:56 AM, Carlo Wood <*[e-mail]*<[e-mail]>>
> 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 <*[e-mail]*<[e-mail]>>
> 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 <*[e-mail]* <[e-mail]>>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>