Re: [ogpx] Protocol for permitting policy decisions

David W Levine <dwl@us.ibm.com> Thu, 08 October 2009 13:55 UTC

Return-Path: <dwl@us.ibm.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 D16FD3A68C9; Thu, 8 Oct 2009 06:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.855
X-Spam-Level:
X-Spam-Status: No, score=-3.855 tagged_above=-999 required=5 tests=[AWL=-1.257, BAYES_00=-2.599, 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 4GatZ1u-BdJK; Thu, 8 Oct 2009 06:55:36 -0700 (PDT)
Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 35AA13A6878; Thu, 8 Oct 2009 06:55:36 -0700 (PDT)
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e7.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n98DsSDg017887; Thu, 8 Oct 2009 09:54:28 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n98DvBSV219778; Thu, 8 Oct 2009 09:57:11 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n98DvALw018938; Thu, 8 Oct 2009 09:57:11 -0400
Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n98DvAuL018913; Thu, 8 Oct 2009 09:57:10 -0400
In-Reply-To: <20091008114435.GA22204@alinoe.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> <20091008114435.GA22204@alinoe.com>
To: Carlo Wood <carlo@alinoe.com>
MIME-Version: 1.0
X-KeepSent: 17263597:F074C846-85257649:004AC591; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009
Message-ID: <OF17263597.F074C846-ON85257649.004AC591-85257649.004CA2BE@us.ibm.com>
From: David W Levine <dwl@us.ibm.com>
Date: Thu, 8 Oct 2009 09:57:04 -0400
X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Build V851_08302009|August 30, 2009) at 10/08/2009 09:57:09, Serialize complete at 10/08/2009 09:57:09
Content-Type: multipart/alternative; boundary="=_alternative 004CA2BC85257649_="
Cc: Infinity Linden <infinity@lindenlab.com>, Meadhbh Hamrick <meadhbh.siobhan@gmail.com>, "ogpx@ietf.org" <ogpx@ietf.org>, "ogpx-bounces@ietf.org" <ogpx-bounces@ietf.org>, Magnus Zeisig <magnus.zeisig@iis.se>
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: Thu, 08 Oct 2009 13:55:37 -0000

One thing to keep in mind in this whole discussion is the following: "All 
policy decisions are local" This doesn't mean they don't represent a way 
of solving a globally distributed use case, but
it highlights the fact the one software element, hosted behind and 
endpoint can't impose behavior on another such endpoint. In the case of 
how a service in an Agent Domain interacts with the services in a region 
domain, the Agent Domain is limited to controlling what *it* does. So, in 
the case of an agent domain which has the policy of not permitting its 
users to be exposed to "mature" content. The agent domain, however, 
doesn't perform the delivery of content from the region. It handles 
authentication, and global presence management, and possibly inventory 
management, but, it doesn't control what happens in the region. (In fact, 
in the current model, it doesn't even see the traffic, but seeing it 
wouldn't help) 

The decision as to what happens inside the region is local to the region. 
Just as the agent Dorian in this example doesn't see what the region is 
doing, the region doesn't see what the
agent domain is doing, nor can it influence it.

>From the point of view of the use case "Keep my agents away from "mature" 
content" the Agent Domain's leverage is limited to looking at the 
information the region exports, and deciding whether or not this is a 
region where it is safe for its agents to travel. The region, of course, 
can say whatever it wants. So.. if the Agent Domain wants certainty, it 
needs for the
region to not only export information it can use to make this decision, 
but to export it in a way that gives the agent domain increased certainty. 
 Traditionally, this takes the form of a
digital signature tied to real world, out of band assurances. 

I would argue this is all for the good. At the Protocol and Endpoint 
description level, most of what needs to happen to support this model is 
to make sure we know where services expose meta-data and how it is 
formatted. The protocol need not focus on what the meta-data represents, 
but that it is there and available for supporting policy decisions. 

>From the perspective of managing interop, I think that the bulk of our 
focus needs to be having the use cases which enable us to make sure we 
*can* export and understand
the meta-data needed to allow policy decisions to be made. 

There is a related topic, namely how we might do a distributed policy 
language permitting various services to reason about the policies 
governing a given service they wish to interact with. But.. That's not 
needed to make the protocol work. I view this as a good thing, since it is 
a decidedly non trivial problem to solve. 

I would suggest that one good way forward on this is to develop a set of 
policy use cases to drive our analysis of the protocol and specifications, 
and then look at whether we can reasonably manage these use cases.  My 
personal belief is that the bulk of our policy management is going to 
consist of checking for meta-data signed using existing PKI standards 
(x.509  is the obvious one) and making decisions based on this meta-data. 

- David W. Levine
~ Zha Ewry





Carlo Wood <carlo@alinoe.com> 
Sent by: ogpx-bounces@ietf.org
10/08/2009 07:44 AM

To
Meadhbh Hamrick <meadhbh.siobhan@gmail.com>
cc
Infinity Linden <infinity@lindenlab.com>om>, "ogpx-bounces@ietf.org" 
<ogpx-bounces@ietf.org>rg>, "ogpx@ietf.org" <ogpx@ietf.org>rg>, Magnus Zeisig 
<magnus.zeisig@iis.se>
Subject
Re: [ogpx] Protocol for permitting policy decisions






On Wed, Oct 07, 2009 at 02:07:58PM -0700, Meadhbh Hamrick wrote:
> anyway. just a though. i'm going to spend a little time trying to
> understand a couple different country's regulations for online access
> to adult materials by minors, just to get a sense for where the
> differences would lie.

Although admirable, this is just an EXAMPLE. We should look at it,
and SOLVE it, in an abstract way; so that we will tackle every
possible policy problem like it without that we have to think of
an exhausted list now.

Ie, if your investigation would show that every country in the
world handles online access to adult materials by minors in the
exact same way, than that doesn't make the abstract problem go
away, we'd just have to think of another example to tackle the
exact same problem.

-- 
Carlo Wood <carlo@alinoe.com>
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx