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

Carlo Wood <carlo@alinoe.com> Sat, 03 October 2009 19:19 UTC

Return-Path: <carlo@alinoe.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 D84223A67A8 for <ogpx@core3.amsl.com>; Sat, 3 Oct 2009 12:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.19
X-Spam-Level:
X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
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 nZGtnenp+LiV for <ogpx@core3.amsl.com>; Sat, 3 Oct 2009 12:19:26 -0700 (PDT)
Received: from viefep16-int.chello.at (viefep16-int.chello.at [62.179.121.36]) by core3.amsl.com (Postfix) with ESMTP id 423B73A67E4 for <ogpx@ietf.org>; Sat, 3 Oct 2009 12:19:25 -0700 (PDT)
Received: from edge04.upc.biz ([192.168.13.239]) by viefep16-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091003192053.NVJF422.viefep16-int.chello.at@edge04.upc.biz>; Sat, 3 Oct 2009 21:20:53 +0200
Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id oKLr1c02L0FlQed04KLsmz; Sat, 03 Oct 2009 21:20:53 +0200
X-SourceIP: 77.250.43.12
Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from <carlo@alinoe.com>) id 1MuAB5-0002HT-G7; Sat, 03 Oct 2009 21:21:59 +0200
Date: Sat, 03 Oct 2009 21:21:59 +0200
From: Carlo Wood <carlo@alinoe.com>
To: Infinity Linden <infinity@lindenlab.com>
Message-ID: <20091003192159.GA7474@alinoe.com>
References: <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> <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
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: Sat, 03 Oct 2009 19:19:28 -0000

Can't type much with my RSI, but I'd like to add that instead
I'd prefer this for D, (not G):

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 won't get me in trouble
with the state if you let 19 year olds into my adults only sim, PLEASE
DON'T block them from entering sims i mark as adult." this effectively turns
scenario D into scenario B for the AD2 / RD1 pairing.

Reason, it's the region (destination) that really determines the law.
And as extension to this, it should be the region that determines all
rules that a visiting user must follow (independent of AD they use).

On Fri, Oct 02, 2009 at 09:32:22AM -0700, Infinity Linden wrote:
> 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
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx

-- 
Carlo Wood <carlo@alinoe.com>