[ogpx] Tourist use case

[Vaughn Deluca <[e-mail]>]

On Sat, Oct 17, 2009 at 12:47 AM, Infinity Linden (Meadhbh Hamrick) <
[e-mail]> wrote:

> okay. i think we're heading towards nomenclature communication fail.
>

Wrong, we were right in the middle of it!


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

In what I called the tourist pattern trust is managed by the services in the
agent domain (or maybe OAuth); services may be deployed in different domains
or all in the same domain; The agent service keeps track of all asset
servers the agent uses; The agent service policy  determines which URLs can
actually be used for TP, Asset servers policies determines what assets can
actually be rezzed in a particular destination region. Agent domain is just
as  Region domain an administrative term, and its main purpose is that of a
 policy server for domain wide policy.

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

Hmm, the credentials could be managed by the agent service after login of
the user, but might come from a third party service.
Rezzing assets is possible if the asset server is willing to let go of that
particular asset and sent it to the destination region. The key feature of
this model is the distributed way assets are managed, and the fact that not
the TP is the key event (in most cases there is no reason to prevent a TP of
a ruthed tourist avatar) but the transfer of assets based on asset server
policy (and ultimately on characteristics of the asset, i.e. its license)

I need to think about the actual  control flows, look at cable beach in more
detail and study the available documentation more.  Things turn out to be
more complicated than I envisioned.

-Vaughn

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