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
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Kari Lippert
- [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Charles Krinke
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] Fwd: VWRAP Draft Charter - 2009 09 01 Meadhbh Siobhan
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Charles Krinke
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Charles Krinke
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 David W Levine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 David W Levine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Charles Krinke
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Joshua Bell
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Dickson, Mike (ISS Software)
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Dickson, Mike (ISS Software)
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 SM
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Dickson, Mike (ISS Software)
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Dickson, Mike (ISS Software)
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Vaughn Deluca
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- [ogpx] Policy between services David W Levine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 SM
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Infinity Linden
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Morgaine
- Re: [ogpx] VWRAP Draft Charter - 2009 09 01 Carlo Wood