Re: [ogpx] VWRAP Draft Charter - 2009 09 01

Infinity Linden <infinity@lindenlab.com> Fri, 02 October 2009 16:31 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 808F63A672F for <ogpx@core3.amsl.com>; Fri, 2 Oct 2009 09:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level:
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 F1Bpx6kXKAjy for <ogpx@core3.amsl.com>; Fri, 2 Oct 2009 09:30:59 -0700 (PDT)
Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by core3.amsl.com (Postfix) with ESMTP id 519A73A6405 for <ogpx@ietf.org>; Fri, 2 Oct 2009 09:30:59 -0700 (PDT)
Received: by pzk35 with SMTP id 35so1786029pzk.29 for <ogpx@ietf.org>; Fri, 02 Oct 2009 09:32:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.61.41 with SMTP id j41mr345919wfa.298.1254501142674; Fri, 02 Oct 2009 09:32:22 -0700 (PDT)
In-Reply-To: <e0b04bba0910012252v540dd170k4b81e30052e6c974@mail.gmail.com>
References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.com> <20090914084420.GA25580@alinoe.com> <9b8a8de40909291316i19c79a96h111d88e73a64cc79@mail.gmail.com> <e0b04bba0909291751g157d2043g1c15e8d8ac417ccf@mail.gmail.com> <f72742de0909300910t23131532i1719d2c86423fa41@mail.gmail.com> <e0b04bba0910011434i13f890bfodd22cd15eef17697@mail.gmail.com> <f72742de0910011457o5e757135rd9db7fc7f4a1389@mail.gmail.com> <e0b04bba0910011613w6f25b684w1b0f2e8c7187b3de@mail.gmail.com> <f72742de0910011632n3488ff6aqbf93edbda2a51637@mail.gmail.com> <e0b04bba0910012252v540dd170k4b81e30052e6c974@mail.gmail.com>
Date: Fri, 02 Oct 2009 09:32:22 -0700
Message-ID: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com>
From: Infinity Linden <infinity@lindenlab.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: ogpx@ietf.org
Subject: Re: [ogpx] VWRAP Draft Charter - 2009 09 01
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, 02 Oct 2009 16:31:00 -0000

i am vaguely confused by the path we're taking. a lot of what we're
fretting over was discussed over the summer.

i am also disappointed that morgaine believes that simply making a
fiat statement like "we are arriving at DDP" makes it true. it is not
true. BOTH the agent domain and the region domain MUST have an
opportunity to express their policy.

the problem outlined by carlo above is interesting, but tractable.

the agent domain is the entity with a direct relationship with the
user. we should not require the region domain to have information
about the user (such as the user's age.) and here's why...

in VWRAP, as discussed before, it is the agent domain that acts as a
trust broker. the user trusts the agent domain and the agent domain
trusts the provider of other services (such as the agent presence
service running on a host in the region domain.) we do not require the
user to have a direct relationship with the region domain. instead, we
define trust transitively.

if the agent domain must ensure that underage users do not visit
regions with adult content, then they should disallow underage user's
avatars from visiting those regions. if this is an organizational
policy that must be adhered to, then the agent domain should have
information to make that decision: the user's age and whether a
specific region (or entire region domain) allows adult content.

if the region domain operator believes that the agent domain operator
may believe that an acceptable age to view adult content is lower than
they are comfortable with, they should communicate this concern at the
time that they are negotiating access. please note that in this
scenario, the evaluation of organizational policies is something that
is performed by humans, not automated systems.

the policy enforcement tool the AD can use in this scenario is to
decide to not place a user's avatar in a particular region. the
information the AD uses to evaluate whether they want to allow or deny
a teleport request is largely not a concern of the protocol. though..
if the decision depends on the state of a region in the region domain,
then there has to be a way to communicate this information from the
region domain to the agent domain. and that _is_ definitely a protocol
concern.

the situation with the region domain is largely similar. the tool the
RD has to enforce policy in this scenario is to disallow an agent
domain from placing an avatar in one of it's regions.

but i really like this example, so i created a diagram from this
example at https://wiki.secondlife.com/wiki/File:VWRAP_adult_content_evaluation_example.jpg
.

it shows two agent domains and two region domains. one of the agent
domains and one of the region domains define adult content as being
viewable by those 18 and older, the others think adult content is
viewable by those 21 and older. each has two regions; one of which has
adult content, the other does not. lets assume that the user is 19.
when the agent domain attempts to place an avatar in each of the
regions, you get 8 scenarios.

A - no adult content in the region, AD allows transfer, RD allows transfer
B - adult content, but both the AD and RD agree that if you're 19,
you're okay to view adult content. AD allows transfer, RD allows
transfer.
C - no adult content in the region, AD allows transfer, RD allows transfer
D - adult content, but AD2 believes the user isn't old enough. AD does
not allow transfer.
E - no adult content in the region, AD allows transfer, RD allows transfer
F - no adult content in the region, AD allows transfer, RD allows transfer
G - adult content. AD1 believes the user is old enough, begins
transfer. RD believes the user is not old enough, disallows transfer.
H - adult content, but both AD2 and RD2 believe the user is old
enough. AD allows transfer, RD allows transfer.

i think the most vexxing scenario is scenario G. it forces the RD to
make a policy decision based on information about the user maintained
by the agent domain. there are a couple of ways to handle this.

1. the agent domain and the region domain hash out an agreement
beforehand where the region domain operator tells the agent domain
operator the equivalent of... "whoa dude, you'll get me in trouble
with the state if you let 19 year olds into my adults only sim, PLEASE
block them from entering sims i mark as adult." this effectively turns
scenario G into scenario D for the AD2 / RD2 pairing.

2. the agent domain offers information in the teleport request about
the user's age to the RD, allowing the RD to disallow the transfer of
agent presence into adult regions.

3. the agent domain offers an interface the RD that lets the RD query
information about the user (including their age.)

all of these have some drawbacks. my employer is probably most
interested in solution 1. linden views the relationship of agent
domain to region domain as a long-term trust relationship with a fair
amount of effort involved in setting it up. still, there are people
that want to have more of a tourist model where the user enters the
URL of a region into the client app and off you go without a
previously established agreements on policy enforcement.

for the tourist model, you could do either 2 or 3. 2 has the advantage
that the RD doesn't need to make a request back to the AD before
deciding whether to complete the teleport. it has the disadvantage
that it requires the AD to give information about the user's age to an
RD who may or may not be trustworthy (cause... remember... we're
talking about the tourist model here.)

i think what i'm getting at here is that carlo's example is
interesting, but it does yield to analysis. i think it also exposes
the difference between linden's vision of their service and what
morgaine (and presumably others) want people to build. but we can get
one protocol that works for both models, we just have to be careful,
and the end result will likely be more complicated than we would
prefer. but. welcome to the world of standards.

-cheers
-meadhbh