Re: [ogpx] Tourist use case

Vaughn Deluca <vaughn.deluca@gmail.com> Fri, 16 October 2009 10:16 UTC

Return-Path: <vaughn.deluca@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 363723A6859 for <ogpx@core3.amsl.com>; Fri, 16 Oct 2009 03:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, 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 CboMuSK460zh for <ogpx@core3.amsl.com>; Fri, 16 Oct 2009 03:16:51 -0700 (PDT)
Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 2DF693A69CC for <ogpx@ietf.org>; Fri, 16 Oct 2009 03:16:51 -0700 (PDT)
Received: by fxm18 with SMTP id 18so2209902fxm.37 for <ogpx@ietf.org>; Fri, 16 Oct 2009 03:16:51 -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; bh=9629xpNAoM52XRITkcHZ0ZrRTpcDsPcNWJ6J5J+/IxM=; b=LnJ8CX/JkY6T+W1ln1JNghnJ0GJf24Q5hSR0VSYhh4gTaMJSEUdGCmBTAyd7JcUUOp frmMkPuQpuToVwdXsnx6dQFOBOvGoxh52UZ04mjmeyHcjbvWj9rqqVgzQTjf/xejH27h CR6aeqcopMiZm44SL3uqTXezSlgbxGSofeu/w=
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; b=B67YD5E2htLQSvMVBBAt92bNRhWlUiJg2NysCwXpLXAiR28+2hc6+dFVBvRdRb6NWh IHW7yhidzFpXx8vsM9CsDoZo0F7klDl5ZOHOudL/RAyYZWQ75K577MEW/opE3tuTmcql zGCygEyCeQGU4WwwXEW5AgQoPmnYRSqXjc0wQ=
MIME-Version: 1.0
Received: by 10.204.155.79 with SMTP id r15mr1115652bkw.142.1255688211645; Fri, 16 Oct 2009 03:16:51 -0700 (PDT)
In-Reply-To: <3a880e2c0910160116g2f4f394ag763822dbd35c80e1@mail.gmail.com>
References: <9b8a8de40910160034j11dcb94fm401f29814aed60a8@mail.gmail.com> <3a880e2c0910160116g2f4f394ag763822dbd35c80e1@mail.gmail.com>
Date: Fri, 16 Oct 2009 12:16:51 +0200
Message-ID: <9b8a8de40910160316w364a2695t8e8dd8992e0b524f@mail.gmail.com>
From: Vaughn Deluca <vaughn.deluca@gmail.com>
To: "Infinity Linden (Meadhbh Hamrick)" <infinity@lindenlab.com>
Content-Type: multipart/alternative; boundary=0015175d07d2cdc62404760ab1e7
Cc: ogpx@ietf.org
Subject: Re: [ogpx] Tourist use case
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, 16 Oct 2009 10:16:53 -0000

On Fri, Oct 16, 2009 at 10:16 AM, Infinity Linden (Meadhbh Hamrick) <
infinity@lindenlab.com> wrote:

> i had assumed that the "tourist model" also implied that the client
> assumes no transitive trust on behalf of the agent domain, or includes
> the agent domain as part of a client implementation.
>

Not in the most basic case, Morgaine indeed defined it that way, but i feel
that that is a more complicated use case, and we would benefit from treating
 it separately from the more basic case.


> also. we should tighten up the language. i would argue that from the
> client's perspective, teleporting between Sim 1 and Sim 2 requires no
> prior arrangement (for the client.) it does, however, require the
> agent domain to trust both sims.
>

Yes, but note that the asset service will have its own policy in this model,
so the needed reasons to distrust the destination region are limited. One
obvious reason would be that promises were made to the user to protect the
avatar from exposure to adult material.
But if the user indicates is has no problem, i would think in the majority
of cases the Agent service can trust the region. In the worst case the
avatar would have to be ruthed because the avatar shape can not be exported.


> maybe we could define the various models in terms of who trusts whom
> and how service endpoint addresses are resolved?
>

Yes, i like that suggestion.


> so the "second life" model [1] would essentially be that the client
> and the agent domain trust each other, and the agent domain and all of
> the region domains trust each other. service endpoints for agent
> services are given to the client by the agent domain, while region
> service are given to the client by the agent domain or the region
> domain.
>

Yes, although you specify a bit more trust that is needed in my view because
you do not    allow assets services there own policy, distinct from the
agent service policy, but if you want to make a blanket statement this is
correct.

>
> in the "tourist model" you would have no trust, and the client is
> responsible for resolving the address of all services.


No, you loose me here. The client *does*  trust the agent service, there is
no difference here with the SL case. The client logs in to an AD, and by
definition trusts that service.
that AD has its own asset service,  just like in the SL case, and the user
can use those assets (as far as the Asset service allows the assets to go
out to other domains).
In addition to using its own asset services the Agent service can use other
Asset services.


> in the "cable beach" model, you have the same trust as the "second
> life" model, but you bring the asset service into it's own domain
> which is explicitly trusted by the agent domain, the region domains
> and the client. asset service endpoints are resolved by the client.
>

I did not yet look in detail at cable beach, but I clearly  should, since
this sounds a lot like what i was thinking of.  However,  I do not think its
needed to put the asset service in its own domain, because by definition a
domain is under a different administration, and in many cases the asset
service will be in some domain. So the critical point is that the asset
service in some domain exposes an interface to the world so its assets *can*
be used, if by anybody if policy allows it.

-Vaughn


> -cheers
> -meadhbh
>
> --
>   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
>         http://wiki.secondlife.com/wiki/User:Infinity_Linden
>
>
>
> On Fri, Oct 16, 2009 at 00:34, Vaughn Deluca <vaughn.deluca@gmail.com>
> wrote:
> > The "tourist use case" has been brought up several times, but the concept
> is
> > not always used in the same way, and needs to be more precisely defined.
> > Morgaines original definition of the "Free Worlds Tourist use case" in
> > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html
> > mentions two characteristics:
> > 1. Travel requires no prior arrangement.
> > 2. Your avatar is defined by you, not by the target worlds, and it
> appears
> > in those worlds with no prior arrangement.
> > Point 1 is only dependent the policies of the users AD as well as that of
> > the destination region. It is not dependent on the protocol, so in
> principle
> > solved.
> > The second point is actually extending the SL use case beyond what is in
> my
> > view needed for a basic tourist model (and that is why the post was in
> the
> > mmox list).  In my view  a basic tourist use case has two main
> > characteristics:
> > 1.  Travel requires no prior arrangement.
> >         2.  Agent domains can use external asset services
> > Point 2 requires that assets services expose an interface (in the current
> > ogp description of the AD that is not the case).
> > Note that this models does *not* assumes that all assets in a services
> > should be useable by the agent in all domains, but only that an interface
> is
> > available so an asset service in one domain can be contacted by another
> AD.
> > I think exposing the asset service interface directly is essential for
> > meaningful interop.  I think it would benefit the discussion if some
> > diagrams were added to http://wiki.secondlife.com/wiki/Structural_Design
> > and/or to the VWRAP wiki to document this possibility.
> > -Vaughn
> > _______________________________________________
> > ogpx mailing list
> > ogpx@ietf.org
> > https://www.ietf.org/mailman/listinfo/ogpx
> >
> >
>