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

Morgaine <morgaine.dinova@googlemail.com> Sat, 03 October 2009 08:54 UTC

Return-Path: <morgaine.dinova@googlemail.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 DEC0F3A685B for <ogpx@core3.amsl.com>; Sat, 3 Oct 2009 01:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.619
X-Spam-Level:
X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[AWL=-0.502, 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 8GzwAQYUXOTN for <ogpx@core3.amsl.com>; Sat, 3 Oct 2009 01:54:50 -0700 (PDT)
Received: from mail-ew0-f228.google.com (mail-ew0-f228.google.com [209.85.219.228]) by core3.amsl.com (Postfix) with ESMTP id 584063A67F2 for <ogpx@ietf.org>; Sat, 3 Oct 2009 01:54:48 -0700 (PDT)
Received: by ewy28 with SMTP id 28so2238822ewy.42 for <ogpx@ietf.org>; Sat, 03 Oct 2009 01:56:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jkHoMWwLr48u/j8ok7hVbMkWdvd/1yWx+mhMjMbb2Ik=; b=ioTYiEfF7PDNG5HAzXfQipQRYPkdZf9kaGuw54X44sp//F+IyslP+KgmSojLD0R91B nuG9PUtRnnO/ITpvwXNziZKky7YBAqpChjCjs8j+m2S73CdB0V4wuChatujZhE1OShsx i7Va95zJGeuguqIJV1oMXBdyiTwBB7AoCM0Ds=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rJkAdyxydNL3NLRr7BOSNxcP4DFaVlCKrsfvXlGp0sfw8vdgNoex1Kiix1ncZ53zU8 ocQaEs2H8eWe7O5oeThRYMmqulwP1TExFotKYDk7ZQznRqhDsBwAEuPMIcDDCxdIiHKX A4/sfhtvKvR2Mn1ylJuhFlPVXPTRMKv6Y6v+Q=
MIME-Version: 1.0
Received: by 10.211.146.2 with SMTP id y2mr749377ebn.21.1254560174511; Sat, 03 Oct 2009 01:56:14 -0700 (PDT)
In-Reply-To: <3a880e2c0910020932t5995c477qb0d798de1c2653f6@mail.gmail.com>
References: <3a880e2c0909011549n504111ebi2729273631cdee74@mail.gmail.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>
Date: Sat, 03 Oct 2009 09:56:14 +0100
Message-ID: <e0b04bba0910030156p5154fa67sca11427be21e54ff@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: Infinity Linden <infinity@lindenlab.com>
Content-Type: multipart/alternative; boundary="001636c5a2828d16ea0475040d84"
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 08:54:52 -0000

On Fri, Oct 2, 2009 at 5:32 PM, Infinity Linden <infinity@lindenlab.com>wrote:

>
> 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.
>


Of course they must have that opportunity, and nobody said they mustn't.
:-)  You may have misinterpreted the scope of the DDP principle slightly,
that's all.  I explained its narrow scope at the end of this response to
Joshua -- http://www.ietf.org/mail-archive/web/ogpx/current/msg00445.html .
It applies only at the destination, so perhaps we should give it yet another
'D' and turn it into *Destination Determines Destination Policy*, although
really it's implicit that it only applies in the destination region.

Think of it just like in the physical world.  If "When in Rome, do as the
Romans do" isn't sufficient, then consider what happens when you travel from
USA to France.  When in France, French laws apply --- no US law has
jurisdiction in France.

Yet, despite French law being the only valid one during your stay, this
doesn't mean that the US had no say in your exit from the US and your
boarding of a plane.  Nor does it mean that France has the power to override
US laws while you are inside her borders, not does it mean that something
you buy legally in France can necessarily be admitted into the US when you
return.  Despite DDP (or DDDP) in France, US law most certainly continues to
apply in its own jurisdiction.  However, US law does not apply on French
soil when you travel there.

Hopefully this squashes the worry that DDP means that AD1's agent-related
policies have no opportunity to be expressed --- they can be expressed
wherever agent-related policies are relevant to its agent A1.  It is only
the *region-related* policies of W2 that are determined by RD2 when A1 is in
RD2.  RD2 has no power beyond that.


Morgaine.







===================================

On Fri, Oct 2, 2009 at 5:32 PM, Infinity Linden <infinity@lindenlab.com>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
>