Re: [ogpx] Protocol for permitting policy decisions
"Infinity Linden (Meadhbh Hamrick)" <infinity@lindenlab.com> Fri, 09 October 2009 13:38 UTC
Return-Path: <infinity@lindenlab.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 4DB3C28C150; Fri, 9 Oct 2009 06:38:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.811
X-Spam-Level:
X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=0.165,
BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TriAzMm-mES0;
Fri, 9 Oct 2009 06:38:01 -0700 (PDT)
Received: from mail-px0-f176.google.com (mail-px0-f176.google.com
[209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id DD63E28C0DD;
Fri, 9 Oct 2009 06:38:00 -0700 (PDT)
Received: by pxi6 with SMTP id 6so7787072pxi.32 for <multiple recipients>;
Fri, 09 Oct 2009 06:39:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.75.17 with SMTP id x17mr219377wfa.154.1255095583099;
Fri, 09 Oct 2009 06:39:43 -0700 (PDT)
In-Reply-To: <OFAF7E773D.828624D6-ON8525764A.001736F4-8525764A.0017813A@us.ibm.com>
References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se>
<3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com>
<20091007203535.GA13882@alinoe.com>
<983F17705339E24699AA251B458249B50CC48CB683@EXCHANGE2K7.office.nic.se>
<e0b04bba0910080241x548b6ff9tbc558aaa069b15be@mail.gmail.com>
<20091008235638.GE13882@alinoe.com>
<e0b04bba0910082110r120148e7ua6975a110890651a@mail.gmail.com>
<OFAF7E773D.828624D6-ON8525764A.001736F4-8525764A.0017813A@us.ibm.com>
From: "Infinity Linden (Meadhbh Hamrick)" <infinity@lindenlab.com>
Date: Fri, 9 Oct 2009 06:39:23 -0700
Message-ID: <3a880e2c0910090639v281c96ebq379b8ce6a8400281@mail.gmail.com>
To: David W Levine <dwl@us.ibm.com>
Content-Type: multipart/alternative; boundary=001636e1fb6063cdf5047580b68c
Cc: ogpx-bounces@ietf.org, "ogpx@ietf.org" <ogpx@ietf.org>
Subject: Re: [ogpx] Protocol for permitting policy decisions
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>,
<mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>,
<mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2009 13:38:02 -0000
On Thu, Oct 8, 2009 at 21:16, David W Levine <dwl@us.ibm.com> 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. +1. i don't know how we got off on talking about distributed policy, but yes, in my view of the world, "policy" describes the decisions that a domain's authorities have made for a particular entity accessing resources via service interfaces, not the description of decisions that one domain's authority wants services in another domain to make. > 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*<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*<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* <carlo@alinoe.com>> > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > >
- [ogpx] Protocol for permitting policy decisions Magnus Zeisig
- Re: [ogpx] Protocol for permitting policy decisio… Dickson, Mike (ISS Software)
- Re: [ogpx] Protocol for permitting policy decisio… Meadhbh Siobhan
- Re: [ogpx] Protocol for permitting policy decisio… Dickson, Mike (ISS Software)
- Re: [ogpx] Protocol for permitting policy decisio… Morgaine
- Re: [ogpx] Protocol for permitting policy decisio… Morgaine
- Re: [ogpx] Protocol for permitting policy decisio… Dickson, Mike (ISS Software)
- Re: [ogpx] Protocol for permitting policy decisio… Infinity Linden
- Re: [ogpx] Protocol for permitting policy decisio… Infinity Linden
- Re: [ogpx] Protocol for permitting policy decisio… Infinity Linden
- Re: [ogpx] Protocol for permitting policy decisio… David W Levine
- Re: [ogpx] Protocol for permitting policy decisio… David W Levine
- Re: [ogpx] Protocol for permitting policy decisio… Infinity Linden
- Re: [ogpx] Protocol for permitting policy decisio… Infinity Linden
- Re: [ogpx] Protocol for permitting policy decisio… Magnus Zeisig
- Re: [ogpx] Protocol for permitting policy decisio… Carlo Wood
- Re: [ogpx] Protocol for permitting policy decisio… Carlo Wood
- Re: [ogpx] Protocol for permitting policy decisio… David W Levine
- Re: [ogpx] Protocol for permitting policy decisio… Vaughn Deluca
- Re: [ogpx] Protocol for permitting policy decisio… Carlo Wood
- Re: [ogpx] Protocol for permitting policy decisio… Vaughn Deluca
- Re: [ogpx] Protocol for permitting policy decisio… Carlo Wood
- Re: [ogpx] Protocol for permitting policy decisio… Carlo Wood
- Re: [ogpx] Protocol for permitting policy decisio… Meadhbh Hamrick
- Re: [ogpx] Protocol for permitting policy decisio… Meadhbh Hamrick
- Re: [ogpx] Protocol for permitting policy decisio… Morgaine
- Re: [ogpx] Protocol for permitting policy decisio… Joshua Bell
- Re: [ogpx] Protocol for permitting policy decisio… Meadhbh Hamrick
- Re: [ogpx] Protocol for permitting policy decisio… Dickson, Mike (ISS Software)
- Re: [ogpx] Protocol for permitting policy decisio… Morgaine
- Re: [ogpx] Protocol for permitting policy decisio… Meadhbh Hamrick
- Re: [ogpx] Protocol for permitting policy decisio… Magnus Zeisig
- Re: [ogpx] Protocol for permitting policy decisio… Morgaine
- Re: [ogpx] Protocol for permitting policy decisio… Magnus Zeisig
- [ogpx] VWRAP future (mostly out of protocol rambl… Magnus Zeisig
- Re: [ogpx] Protocol for permitting policy decisio… Carlo Wood
- Re: [ogpx] Protocol for permitting policy decisio… Morgaine
- Re: [ogpx] Protocol for permitting policy decisio… Magnus Zeisig
- Re: [ogpx] Protocol for permitting policy decisio… David W Levine
- Re: [ogpx] Protocol for permitting policy decisio… Magnus Zeisig
- Re: [ogpx] Protocol for permitting policy decisio… Carlo Wood
- Re: [ogpx] Protocol for permitting policy decisio… Joshua Bell
- Re: [ogpx] Protocol for permitting policy decisio… Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Protocol for permitting policy decisio… David W Levine
- Re: [ogpx] Protocol for permitting policy decisio… David W Levine
- Re: [ogpx] Protocol for permitting policy decisio… Carlo Wood
- Re: [ogpx] Protocol for permitting policy decisio… Carlo Wood
- Re: [ogpx] Protocol for permitting policy decisio… Carlo Wood
- Re: [ogpx] Protocol for permitting policy decisio… Dickson, Mike (ISS Software)
- Re: [ogpx] Protocol for permitting policy decisio… Morgaine
- Re: [ogpx] Protocol for permitting policy decisio… Morgaine
- Re: [ogpx] Protocol for permitting policy decisio… David W Levine
- Re: [ogpx] Protocol for permitting policy decisio… Morgaine
- Re: [ogpx] Protocol for permitting policy decisio… Morgaine
- Re: [ogpx] Protocol for permitting policy decisio… Vaughn Deluca
- Re: [ogpx] Protocol for permitting policy decisio… Magnus Zeisig
- Re: [ogpx] VWRAP future (mostly out of protocol r… Vaughn Deluca
- Re: [ogpx] Protocol for permitting policy decisio… Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Protocol for permitting policy decisio… Morgaine
- Re: [ogpx] Protocol for permitting policy decisio… Vaughn Deluca
- Re: [ogpx] Protocol for permitting policy decisio… Carlo Wood
- Re: [ogpx] Protocol for permitting policy decisio… David W Levine
- Re: [ogpx] Protocol for permitting policy decisio… Morgaine
- Re: [ogpx] Protocol for permitting policy decisio… Vaughn Deluca