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

Morgaine <morgaine.dinova@googlemail.com> Sat, 03 October 2009 21:50 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 379A93A63EB for <ogpx@core3.amsl.com>; Sat, 3 Oct 2009 14:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.802
X-Spam-Level:
X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_05=-1.11, 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 n1DtaSlL0pzH for <ogpx@core3.amsl.com>; Sat, 3 Oct 2009 14:50:52 -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 6B1AC3A6359 for <ogpx@ietf.org>; Sat, 3 Oct 2009 14:50:51 -0700 (PDT)
Received: by ewy28 with SMTP id 28so2783501ewy.42 for <ogpx@ietf.org>; Sat, 03 Oct 2009 14:52:19 -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=IUHS5wXfpHl5DI/pjR1O5saMKryY1qGhA8FlV/6glbQ=; b=fTE/Ubrk1MUWwr0BFj0Aa9CPcuOfZSOcveQPcZ/cWXeSq7KgoZ/bLaopr7JHl2UO4h qb1CdEAdtXMXmoSIRQ6moiiU9sJCVg7UBvgOXdj5QQFx5prpPuWzcSIqwq3YnNmAWE5X 8xTY5coYErhD89P+2OQNBAQ4KNpvCeIkv54T0=
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=PSisLnBZUum7aTCPYXmg3sdsc+R4GTjofLeg0PGO8x1K9iugni/qdZ05N+0rflS0YG 5flS+mU5+xL2IlDRr4M9ETLi5xGnmPOIbplnCEqY70POkI+vg3UO4yEs9TqHgrK3QrwZ TdaJ8C+NcgRS0GqZi4FB9qktF4j8rvNBTnBUM=
MIME-Version: 1.0
Received: by 10.210.7.17 with SMTP id 17mr1423112ebg.17.1254606738926; Sat, 03 Oct 2009 14:52:18 -0700 (PDT)
In-Reply-To: <20091003192159.GA7474@alinoe.com>
References: <20090914084420.GA25580@alinoe.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> <20091003192159.GA7474@alinoe.com>
Date: Sat, 03 Oct 2009 22:52:18 +0100
Message-ID: <e0b04bba0910031452o2a497effi57c4e92f8902b5df@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: Carlo Wood <carlo@alinoe.com>
Content-Type: multipart/alternative; boundary="000e0ce0450a01aeb404750ee555"
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 21:50:54 -0000

On Sat, Oct 3, 2009 at 8:21 PM, Carlo Wood <carlo@alinoe.com> wrote:

>
> 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).
>
>
Yes indeed.  And that's pure *DDP*.  W2's regions or RDs may be run by a
provider located in a different country to W1's regions, so no way can W1
determine policy in RD2.

W1's policies can at most dictate whether A1 is allowed to TP to a W2 region
or RD, and which items can be brought back to W1.  That's all.

It's important to highlight (as you did) that issues such as age
verification have no place in a worldwide IETF protocol standard, so while
you provide a good example of policy variations among worlds, any such
agreements are outside of the context of our protocol.


Morgaine.






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

On Sat, Oct 3, 2009 at 8:21 PM, Carlo Wood <carlo@alinoe.com> wrote:

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