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?