(Dropping opensim-dev from the distribution list - cross-posting between
moderated lists is not ideal, and the conversation tends to be quite hard to
follow. My apologies if this makes it worse.)

Thanks for dropping in, Diva!

This discussion is completely within the bounds of the VWRAP charter, so
it's perfectly welcome on the vwrap@ietf.org list, if it's being done with
an eye towards encouraging independent implementations. Don't feel that
you're intruding at all - quite the opposite!

This would be a great place to hash out details of security/trust models and
protocols for data transport between virtual world instances, with the
benefit of input from other list contributors who have experience in related
areas. That's what this working group is chartered with, after all.

As an example, over on the opensim-dev list branch of this thread, I noticed
some conversation about the global identifiers that implied parsing URLs to
extract data, rather than treating them as opaque references to resources.
That's generally considered a big "no-no" and runs contrary to the collected
wisdom of the IETF for several reasons (that I'm sure folks will be glad to
enumerate), and there are alternate patterns that should be followed.
Hopefully, input on that level would be appreciated - if so, please do take
advantage of this forum.

On Tue, Aug 31, 2010 at 10:56 AM, <diva@metaverseink.com> wrote:

> One last thing, possibly of interest to the folks in VWRAP:
>
> Another thing that happened to OpenSim as it reached 0.7 was the
> reconceptualization of the software itself. As a consequence of this
> reconceptualization, interoperability architectures such as the Hypergrid
> are built as optional components that don't affect the core of the
> walled-garden code.
>
> As such, for those who don't like the Hypergrid for whatever reason, you
> can experiment with your own ideas of interoperability without having to tip
> toe around it. I suggest you understand HG1.5 first, as not to reimplement
> it again. Then, if what you want to do is really different, and not just a
> layer of *policy* above HG1.5 (policy specifications will be supported
> soon), follow the same philosophy of modularizing things properly, as that
> will give your architecture a chance for people to use as plugin. If you run
> into a missing hook, just let me know.
>
> Bottom line wrt interop, two major things happened: 1) the hypergrid 1.5, a
> system-to-system (S2S) architecture with the trust/security model explained
> below; and 2) the clean up of the framework, allowing anyone to experiment
> with interop.
>
> diva@metaverseink.com wrote:
>
>> One more thing, a bit less important than the others, as the others
>> pertain to grid-level content, and this one pertains to user-level content:
>>
>> - WRT to the user agent itself (i.e. name, appearance, etc.), the user's
>> user agent service (a grid-level service) is the party responsible for
>> creating user agents that are launched at foreign grids. As such, that
>> component is the authority that defines what agent data to send. If the user
>> agent service of one grid so wishes, all of its users' agents can be
>> anonymized and stripped off their clothes before going out.
>>
>> - HG 1.5 has another, symmetric, grid-level component called the
>> Gatekeeper which has the role of deciding what comes in to its grid. So if
>> the Gatekeeper so wishes, it can anonymize all foreign user agents and strip
>> them off their clothes before allowing them in.
>>
>> In other words, the user agent service and the gatekeeper service are the
>> yin and yang of the Hypergrid.
>>
>> diva@metaverseink.com wrote:
>>
>>> [unrelated to the narrow issue at hand, but since people want to know,
>>> here goes]
>>>
>>> HG 1.5 has a trust/security model. The base case is one where grids are
>>> peers, and the traveling of one user agent from his home grid to another
>>> establishes the *base trust* in the following manner:
>>>
>>> - Everything that the agent references from his home grid is made
>>> available to the foreign grid where the user is. In other words, the user is
>>> the driver of trust.
>>>
>>> - Everything else that is not referenced by the visiting agent is out of
>>> reach. "Out of reach" is a soft security model, i.e. the resources are
>>> available on the internet, but you need to know their identifiers in order
>>> to get them. Their identifiers behave as capabilities. This is the part that
>>> still needs work, as Melanie thinks 'soft' is not enough.
>>>
>>> This trust model is the base upon which trust policies can be defined. In
>>> other words, we now have the basis to add additional grid-level
>>> specifications that overwrite the user's actions.
>>>
>>> Melanie wrote:
>>>
>>>> Hi,
>>>>
>>>> HG 1.5 doesn't address these concerns. Also, please remember that
>>>> assets need to be freely available to all, else they can't be
>>>> displayed. The observer gets a copy, too.
>>>>
>>>> Animations, textures, sounds, etc. need to be given to all observers.
>>>>
>>>> Melanie
>>>>
>>>> Mike Dickson wrote:
>>>>
>>>>> Right. I think some of the use cases related to how content is shared
>>>>> have been glossed over. In a completely open model which is what has
>>>>> been discussed this is all pretty straightforward.  But if I'm running
>>>>> an asset service (as part of a grid or separately) I might want to
>>>>> provide access controls as part of that service. The same with user
>>>>> services.  I may have a trust relationship with one agent service and
>>>>> allow content to be transferred to agents that service represents. But
>>>>> for another agent service for which no such relationship exists I'd
>>>>> like
>>>>> to deny access to content. And even in the transfer case does the new
>>>>> user get a new copy or a reference. That concept isn't supported now
>>>>> but
>>>>> in a distributed grid its an important distinction. I might wish to
>>>>> know
>>>>> that copies of objects rezzed in a simulator always come from a
>>>>> specific
>>>>> asset service.
>>>>>
>>>>> In short I think how the security model works is way more important
>>>>> than
>>>>> a caching optimization being applied to a URI/URL.  Its important to
>>>>> understand what levels of trust between services are supported and
>>>>> under
>>>>> what conditions an access is supported.  As an Agent Service I may
>>>>> consider even the "Names" of my users to be confidential and only to be
>>>>> revealed to services for which a trust relationship exists.
>>>>>
>>>>> Mike
>>>>>
>>>>> On Tue, 2010-08-31 at 13:23 +0000, mysticaldemina@xrgrid.com wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> As a content creator this concerns me.  I believe if I license my
>>>>>> content to
>>>>>> an avatar, and then they go to another grid that any content pulled
>>>>>> should
>>>>>> be from the grid that I have the content loaded into.  I think I
>>>>>> should be
>>>>>> in control of my content.  I also think I should be able to block
>>>>>> grids that
>>>>>> my content is being accessed from.  If you don't always maintain the
>>>>>> original content location there will be no control.  If I give someone
>>>>>> a
>>>>>> copy of my content, then that is something else, they are now the
>>>>>> owner of
>>>>>> it and are free to do as they please with it, at least within any
>>>>>> license I
>>>>>> give them.  But that is a legal stuff not a technically programmed
>>>>>> one.  At
>>>>>> least I don't expect all situations to be programmed.
>>>>>>
>>>>>> Also when asset services start happening this will become more of an
>>>>>> issue.
>>>>>> I will have XRMarketplace.com live soon and plan to start selling
>>>>>> content
>>>>>> and provide that content as an asset server.  How will I maintain any
>>>>>> kind
>>>>>> of control over the use of my content if people don't have to pull
>>>>>> copies
>>>>>> from me?
>>>>>>
>>>>>> I also think, and haven't seen in the new hypergrid, if someone goes
>>>>>> to a
>>>>>> new grid I may not allow any of my content to go there unless that
>>>>>> avatars
>>>>>> gets an authorization from me which should be attached to his proxy
>>>>>> profile
>>>>>> for access into my grid/asset server.
>>>>>>
>>>>>> The other thing to think about is how updates or corrections are
>>>>>> propagated.
>>>>>> SL has a terrible system of only supporting copies so any updates or
>>>>>> copies
>>>>>> have to be sent to everyone.  Seems content replacement needs to be
>>>>>> supported and if content is all over the place this will get even
>>>>>> crazier.
>>>>>> Also to support dynamic content there needs to be a ways to refresh or
>>>>>> update content.  I suggest there needs to be an expiration date on the
>>>>>> content just like how images and HTML pages on the web work so that
>>>>>> cached
>>>>>> content will know to pull a new copy.  And if the expiration date is
>>>>>> 0, at
>>>>>> the time it was pulled, it will always get refreshed.
>>>>>>
>>>>>> This is maybe should have its own discussion thread but seems to be
>>>>>> part of
>>>>>> how this is all going to work.
>>>>>>
>>>>>>
>>>>>> M.
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: opensim-dev-bounces@lists.berlios.de
>>>>>> [mailto:opensim-dev-bounces@lists.berlios.de] On Behalf Of Ai Austin
>>>>>> Sent: Tuesday, August 31, 2010 4:17 AM
>>>>>> To: opensim-dev@lists.berlios.de
>>>>>> Subject: Re: [Opensim-dev] Global identifiers
>>>>>>
>>>>>> myticaldemina makes a lot of good points... one thing that could be
>>>>>> problematic though relates to this comment...
>>>>>>
>>>>>>  From: <mysticaldemina@xrgrid.com>
>>>>>>> ...I would suggest any
>>>>>>>
>>>>>>> proxies would give the external system and identifier and not chain
>>>>>>> proxy
>>>>>>>
>>>>>> to
>>>>>>
>>>>>>> proxy unless there is a reason to do it, and the assets should be
>>>>>>> copied
>>>>>>>
>>>>>> >from the original source.
>>>>>>
>>>>>>
>>>>>> I agree with the first half... no chains, just hand over the external
>>>>>> system "authority" and its given identifier pair for the identity involved.
>>>>>>
>>>>>> But I don't agree at all with the idea that you then have to get the
>>>>>> asset from that original authority.  The permissions could have changed,
>>>>>> corruptions could have occurred or much more likely the authority simply
>>>>>> will no longer be there.  The asset "as is" (with its textures, scripted
>>>>>> content and what not) should be provided to the destination location/grid if
>>>>>> the object permissions allow it, with proper transfer of the permissions to
>>>>>> next owner exactly as if an avatar to avatar transfer or rez in world took
>>>>>> place on the local grid, without trying to reload the asset from an original
>>>>>> source.
>>>>>>
>>>>>> .
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Opensim-dev mailing list
>>>>>> Opensim-dev@lists.berlios.de
>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> Opensim-dev mailing list
>>>>>> Opensim-dev@lists.berlios.de
>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev@lists.berlios.de
>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>
>>>>>
>>>>>  _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev@lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>>>  _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>  _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>  _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>