Re: [ogpx] Protocol for permitting policy decisions
Morgaine <morgaine.dinova@googlemail.com> Fri, 09 October 2009 04:41 UTC
Return-Path: <morgaine.dinova@googlemail.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 54EAF3A6403 for <ogpx@core3.amsl.com>;
Thu, 8 Oct 2009 21:41:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.582
X-Spam-Level:
X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[AWL=0.394,
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 BBu7CXRXBZA7 for
<ogpx@core3.amsl.com>; Thu, 8 Oct 2009 21:41:19 -0700 (PDT)
Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com
[209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id DADFD3A635F for
<ogpx@ietf.org>; Thu, 8 Oct 2009 21:41:18 -0700 (PDT)
Received: by ewy4 with SMTP id 4so301911ewy.37 for <ogpx@ietf.org>;
Thu, 08 Oct 2009 21:43:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type;
bh=Fa4/w0ZfE0p37fKpNQDhozabGTmVrV636lVPeuoF5rk=;
b=SrFf+1Gizjs1E0QNGkJOyKqbUUd44Qmr84GuGe7XyjU8VKXITtaf7Y/LN8DIFc37Ja
AxX21hZE2zlW1x0JthxwVCdwjMAKCecfNxW1bdOeuE/HaMpH5w7cf7Ge6DPm+CqMoSJM
ubiEY3kX0NFzX7gV3hacNiQkVr6aRe/Oaudgs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
b=iS4rL8L6/EzBnB0R4Cl8LiiPqg/BQudYoGwzcsiTZaDgwFDQ+zcTxq2avYp8Ma3Ftq
pply8xFUeH+l/JFxqKWmHpXCINSW6giCl23UQnyzv7tc9tv/pOz1iZNo705rmdVrFn+z
x9rku4Hdy9TAZVNJ1nU7ckAara2Vrg9FU/h3U=
MIME-Version: 1.0
Received: by 10.210.2.19 with SMTP id 19mr2555365ebb.94.1255063380323;
Thu, 08 Oct 2009 21:43:00 -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>
Date: Fri, 9 Oct 2009 05:43:00 +0100
Message-ID: <e0b04bba0910082143o4bc0a47ckdaa39f3cbe00ece7@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: David W Levine <dwl@us.ibm.com>
Content-Type: multipart/alternative; boundary=000e0cdff6f6f46d49047579368f
Cc: "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 04:41:21 -0000
A big +1, David! And yet, despite knowing that non-local policy enforcement is a fiction because it's *services* that express policy, I still see people attached to the delusion that a safe, protected environment will be achieved through some kind of transitive or viral contagion of local policy to create a widespread non-local policy, as if domains spread policy by contact. The implication permeates this thread, and we're going to have to examine it in detail to see who is right. Morgaine. ===================================== On Fri, Oct 9, 2009 at 5:16 AM, 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. 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] 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