Re: [ogpx] Tourist use case

["Infinity Linden (Meadhbh Hamrick)" <[e-mail]>]

okay. i think we're heading towards nomenclature communication fail.
what you describe below is part of what i call the "Second Life"
deployment pattern. what i'm calling the tourist pattern is that
"trust is managed by the client; services may be deployed in different
domains or all in the same domain; the client decides which URLs to
use for each service it wants to use for service establishment."

maybe we should be asking, what is the aspect of the tourist model
that differentiates it from the others. based on what i _think_ i hear
people saying (david's deployment and layering doc aside,) it sounds
to me that the fundamental aspect of the tourist model is the ability
for the client application to tell the agent domain to rez in a region
at an arbitrary URI and to use credentials given to it by the client
at the time the user requests placement in a region.

this is contrasted to what i'm calling the "second life model" where
the user establishes a credential for use exclusively between the
client and the agent domain. and the agent domain and different region
domains establish some authentication or authorization regime between
themselves that is distinct from the client <-> agent domain
authenticator. when the user wants their avatar moved into a
particular region, the client provides the URI or an arbitrary map
reference to the agent domain. the agent domain then resolves the map
reference to a service URI if one wasn't provided by the client.
assuming that the destination URI resolves to a host inside a region
domain with whom the agent domain has a trust relationship, it begins
the protocol to place the user's avatar in that region. the
destination region authenticates the agent domain and not the user's
avatar before placing it in the region.

what i'm calling the "cable beach model" is that the client tells the
agent domain where it will find it's preferred asset server. this is
different from the "second life model" where the agent domain provides
caps for inventory access after the client has authenticated itself. i
chatted with jhurliman about this, and he seems big on OAuth to be the
carrier of authorization information. the essential difference here is
that an independent authentication to the asset service is required,
but once that's done, you can use OAuth to give asset access to the
AD, the RD or the client. in fact, you could probably just have the
agent domain authenticate OAuth tokens from the domain containing the
asset service. but the essential notion here is that multiple region
domains and multiple agent domains could use the services of the same
external asset service.

and the standalone mode is basically everything is on one box.

discussion?

-cheers
-meadhbh/infinity



--
   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
         http://wiki.secondlife.com/wiki/User:Infinity_Linden



On Fri, Oct 16, 2009 at 07:29, Vaughn Deluca <[e-mail]> wrote:
>
>
> On Fri, Oct 16, 2009 at 3:44 PM, Meadhbh Hamrick <[e-mail]>
> wrote:
>>
>> but didn't we say that we were going to focus on "second life-like"
>> worlds in this WG?
>
> I strongly believe the basic  mode *is* "second life like", even much more
> so than some of the other use cases considered in Davids layering draft.
> Also i do not think this needs to delay us much *at all*, since the basics
> idea has  always been part of the deployment pattern considered. Look at the
> description of "adding a Organization domain" on the wiki:
> http://wiki.secondlife.com/wiki/Multiple_Domains#Adding_a_Organization_Domain.
> The figure legend states:
>> [...] The blue dotted line means that an agent can be linked
>> to another agent (e.g. the more public agent from the SL Agent domain
>> (== Linden Lab's grid)). This can mean the following:
>>
>> The company agent can access the inventory from the
>> company agent domain and from the SL Agent Domain
> This is in principle the tourist use case i have been describing!
> However, the wiki is not clear about the way to actually implement the
> restrictions:
>>So what we need here is a list of what should be restrictable
>>and a means of how to define it.
> My suggestion is to define the restrictions at the level of the services,
> completely analogous to the discussion we had about the Region Domain i.e.
> All policy is local -but the regions can use a global policy derived from
> the domain if they wish to do so).
> I therefore argue strongly for a design were Agent service and Asset service
> are both expressing policy, and both exposing an interface to the world.
> In this way it becomes fairly easy to configure any type of domain
> behaviour.
> I really see very few problems here, but maybe i am naive  :)
> -Vaughn
>
>
>>
>> isn't that why it was formed? shouldn't the tourist
>> model be an effort of the MMOX group? i thought that was the reason we
>> kept the MMOX mailing list up, so work could continue on that type of
>> virtual world.
>>
>> -meadhbh/infinity
>>
>>
>> On Fri, Oct 16, 2009 at 5:00 AM, Morgaine
>> <[e-mail]> wrote:
>> > Vaughn,
>> >
>> > You've correctly represented my MMOX post, thanks!  (
>> > http://www.ietf.org/mail-archive/web/mmox/current/msg01392.html )
>> >
>> > I must stress, as you did yourself, that the "Free Worlds Tourist" use
>> > case
>> > which I described there in MMOX is different  to the simpler "tourist
>> > use
>> > case" which we have been discussing here.  It's great that you're
>> > shining
>> > some light into this corner.  Hopefully this will allow us to affix
>> > labels
>> > to the various cases to keep our discussions simple yet clear.
>> >
>> > Before addressing your actual point, I should first state that I
>> > consider it
>> > unfortunate that the "Free Worlds Tourist" use case is not considered an
>> > integral part of VWRAP requirements --- this is a practical conclusion
>> > on my
>> > part.  On the basis of our discussions so far, I think it would be too
>> > much
>> > to expect that a mode of operation offering such a high degree of
>> > freedom of
>> > travel and of avatar appearance would achieve rough consensus in the
>> > group,
>> > given that its considerable distance from Second Life policies would
>> > almost
>> > certainly lead to intense opposition.  This is not a battle I wish to
>> > fight.
>> >
>> > As a practical matter then, "Free Worlds Tourist" as defined above is
>> > not a
>> > use case that I am pushing in VWRAP at this time, despite it being
>> > entirely
>> > compatible with the SL/Opensim model and hence deserving inclusion.  I'm
>> > simply going to express regret that it is likely to be a bridge too far
>> > on
>> > political grounds and leave it at that.  I would wish it were otherwise.
>> >
>> > With that disclaimer, I'll answer your point about our more constrained
>> > "tourist use case" (which perhaps needs a better name), this being a
>> > much
>> > easier target but still a very useful one.  I will however answer it in
>> > the
>> > immediately following post, because I don't want to get this confused
>> > with
>> > the "Free Worlds Tourist" case that I described in MMOX.
>> >
>> >
>> > Morgaine.
>> >
>> >
>> >
>> >
>> >
>> > =====================================
>> >
>> > On Fri, Oct 16, 2009 at 8:34 AM, Vaughn Deluca <[e-mail]>
>> > 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
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ogpx
>> >>
>> >
>> >
>> > _______________________________________________
>> > ogpx mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ogpx
>> >
>> >
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>