Re: [ogpx] Protocol for permitting policy decisions

Meadhbh Hamrick <meadhbh.siobhan@gmail.com> Thu, 08 October 2009 05:35 UTC

Return-Path: <meadhbh.siobhan@gmail.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 26E8628C1F3 for <ogpx@core3.amsl.com>; Wed, 7 Oct 2009 22:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level:
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599]
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 0QYFqjMMRXTN for <ogpx@core3.amsl.com>; Wed, 7 Oct 2009 22:35:08 -0700 (PDT)
Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.216.176]) by core3.amsl.com (Postfix) with ESMTP id 41F9128C1F1 for <ogpx@ietf.org>; Wed, 7 Oct 2009 22:35:08 -0700 (PDT)
Received: by pxi6 with SMTP id 6so6417247pxi.32 for <ogpx@ietf.org>; Wed, 07 Oct 2009 22:36:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pY8+xhUiM/0iM+GAXt3BALVA1R30iSLYicMx67F3a54=; b=L9SpY5CB8ysU2kBBzcJOV5i3BJR3FoG7qfJJymKgrraB3jPQscYKT9t39sd7VaHOnY gHvLY0j+H/OGGzCUVVJocn3eCJQ/4hgvIyJfUYLfW10HSdZsR8fv34avNw67E9K4cKBu IhFC7ZholLOzhiEMivslpvabtTgxK0Ow+BSR4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LKtNma46IOeEXVyNrffy8vfV0cj4fTX+X2bU8Dia1P/GQFWEudO/foEjrDRVVLA58L CtX9PBuq7Yr9QeBKtzVmZXFjd4UuBs0ctK7RHGbRszESmJ+kfCO8Zh7c9CWrrL0l4o0G fgQ4Kxr6pIxi0HJTu+0YsB1gJ+3myfKV2lMxg=
MIME-Version: 1.0
Received: by 10.114.44.14 with SMTP id r14mr1504940war.196.1254980206863; Wed, 07 Oct 2009 22:36:46 -0700 (PDT)
In-Reply-To: <4646639E08F58B42836FAC24C94624DD771A1BA1FA@GVW0433EXB.americas.hpqcorp.net>
References: <983F17705339E24699AA251B458249B50CC48CAEBF@EXCHANGE2K7.office.nic.se> <3a880e2c0910051239t3dcae895x4f6d5f4bf5d64cd@mail.gmail.com> <20091007203535.GA13882@alinoe.com> <b8ef0a220910071358x17b14245k671d5d41ebdf9ac7@mail.gmail.com> <4646639E08F58B42836FAC24C94624DD771A1BA1FA@GVW0433EXB.americas.hpqcorp.net>
Date: Wed, 7 Oct 2009 22:36:46 -0700
Message-ID: <b8ef0a220910072236l6924aa2fqac83f38c3541a4ae@mail.gmail.com>
From: Meadhbh Hamrick <meadhbh.siobhan@gmail.com>
To: "Dickson, Mike (ISS Software)" <mike.dickson@hp.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: Infinity Linden <infinity@lindenlab.com>, "ogpx@ietf.org" <ogpx@ietf.org>, Magnus Zeisig <magnus.zeisig@iis.se>
Subject: Re: [ogpx] Protocol for permitting policy decisions
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: Thu, 08 Oct 2009 05:35:09 -0000

the way that my employer plans to deploy AD's and RD's is that the AD
will be the entity that has a relationship with the user. _it_ is
responsible for ensuring that the little ones don't run afoul of the
local obscenity regulations, because _it_ is the one that provides
access to the regions.

we _could_ say that it's the region's responsibility to know the agent
domain's policy, and that the region needs to block access to the user
when the agent domain tells it that the user in question is underage,
but that's the scenario we were trying to avoid: leaking information
about the user to the region domain. also, i think under current US
law, this might change the relationship between the RD and the AD with
respect to the nature of agency between the two. but, IANAL, so i'm
not an expert on that topic.

but at the end of the day, if i'm an agent domain, and i have a user
whom i know is 15 and a US resident, i would really like to make the
decision myself about whether i even want to start rezzing the user's
avatar in a region. and to make that decision, i will want to know
what the region's maturity level is set to.

-cheers
-meadhbh / infinity

On Wed, Oct 7, 2009 at 6:17 PM, Dickson, Mike (ISS Software)
<mike.dickson@hp.com> wrote:
> Meadbah wrote:
>
>
>
> i still like this scheme because a) it's really similar to the way
>
> seed caps work, b) it adds flexibility to our system(s), and c) it
>
> does what i was hoping... gives the AD the ability to make policy
>
> decisions (like am i going to let this 15 year old user access
>
> material that may land me in hot water with the local authorities.)
>
>
>
> I may be mis-understanding all this since I’m still trying to come up to
> speed but isn’t it the region that’s making the policy decision here to
> allow/disallow a connect given what AD is representing about the user?  And
> yes, I agree that for this to work there must be trust established between
> the services involved.  I’m just confused by the above statement since it
> implies the AD is making a policy decision while it’s really the RD that has
> the content (and hence the possible issue).  And the RD and AD may be run by
> two different entities….
>
>
>
> Mike
>
>