Re: [ogpx] Protocol for permitting policy decisions
Joshua Bell <josh@lindenlab.com> Wed, 07 October 2009 22:12 UTC
Return-Path: <josh@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 2B46F3A6A12 for <ogpx@core3.amsl.com>;
Wed, 7 Oct 2009 15:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.761
X-Spam-Level:
X-Spam-Status: No, score=-0.761 tagged_above=-999 required=5 tests=[AWL=-0.644,
BAYES_20=-0.74, 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 wSW4rsdp8X4x for
<ogpx@core3.amsl.com>; Wed, 7 Oct 2009 15:12:03 -0700 (PDT)
Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com
[209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 00F203A69B4 for
<ogpx@ietf.org>; Wed, 7 Oct 2009 15:12:02 -0700 (PDT)
Received: by pzk6 with SMTP id 6so38299pzk.29 for <ogpx@ietf.org>;
Wed, 07 Oct 2009 15:13:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.141.35.12 with SMTP id n12mr60813rvj.237.1254953620944;
Wed, 07 Oct 2009 15:13:40 -0700 (PDT)
In-Reply-To: <b8ef0a220910071407w14040de4ka198375a70896b@mail.gmail.com>
References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se>
<3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com>
<OFE55CFEA3.6AD0DA74-ON85257646.006FC774-85257646.0070F176@us.ibm.com>
<3a880e2c0910051638p393b20d1vc12763b59ae17e00@mail.gmail.com>
<983F17705339E24699AA251B458249B50CC48CB1CB@EXCHANGE2K7.office.nic.se>
<20091007204917.GB13882@alinoe.com>
<b8ef0a220910071407w14040de4ka198375a70896b@mail.gmail.com>
Date: Wed, 7 Oct 2009 15:13:40 -0700
Message-ID: <f72742de0910071513o4630fa9s87b333702c84c697@mail.gmail.com>
From: Joshua Bell <josh@lindenlab.com>
To: ogpx <ogpx@ietf.org>
Content-Type: multipart/alternative; boundary=000e0cd1530ac9392804755fa854
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: Wed, 07 Oct 2009 22:12:04 -0000
On Wed, Oct 7, 2009 at 2:07 PM, Meadhbh Hamrick <meadhbh.siobhan@gmail.com>wrote;wrote: > oh. hey. so i was just thinking about the "should we define global > keys for region meta-data?" question. > > i think if we were to move forward with the AD telling the RD what > it's concerned about plan, we _should_ have global identifiers. i just > think that if everyone had different identifiers for the same concept, > you would get protocol interop, but you would still have systems that > don't know what each other are talking about. > Thinking while I type here - these aren't finished thoughts, just some brainstorms: So fundamental to this, we're talking about one system making policy decisions based on data from another system that's in a different trust domain (e.g. separate organizations). That implies to me that they must have done an out-of-band trust negotiation, otherwise they have no reason to, er, trust the data, so the policy decision is advisory at best. And at that point, wouldn't we assume they're attempting to actively enable system interop and would therefore also have that opportunity to agree on a concept/identifier set? IMHO, that wouldn't live in the protocol itself, but perhaps a standard set of interchange profiles... Sample scenario (using the VW1=AD1+RD1, VW2=AD2+RD2 rough terminology we've been batting about): VW1 and VW2 want to enable inter-VW tourism (i.e. AD1 agents can visit RD2). VW2 has a policy that they only allow in users of a certain quality (e.g. "speaks Latin"). Only a subset of AD1 agents have that quality. Therefore, RD2 would only accept teleports of AD1 agents that have that quality (based on the sort of handshake discussed earlier in this thread). However, RD2 needs some trust relationship with AD1, otherwise malicious AD3 can come along which claims all of its users speak Latin and its users slip in. So VW1 and VW2 trade keys and sign some paperwork, and at that point (while the lawyers are busy) they could handshake on sharing "agent linguistic information profile v2.3" data. On the other hand, there might be more hard-core requirements (age, security clearance, etc) that would use different profiles. Hopefully there's also the nil-trust case where this information might be shared on a purely informational basis - e.g. even ADx asserts some quality about an agent to RDy, ADx feels comfortable broadcasting that information (since it can't trust that RDy will keep it confidential) and RDy feels comfortable using that information even without trusting it (since it has no reason to believe ADx is telling the truth). Now... this all doesn't sound like it should new. I'm vaguely reminded of W3C's PICS (which died quietly after negligible adoption), but there weren't two active (and potentially liable...) entities involved in that, just the single provider and user. Surely there are other examples?
- [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