Re: [ogpx] Cable Beach + VWRAP update

[David W Levine <[e-mail]>]

I read John's post as "This is what we have built, how it works, and how 
you can think about it mapping onto the OGPX/VWRAP design. I certainly 
don't read it as "We should all build and deploy this." 

Policy Enforcement Points are where you find them. I actually think that 
having one or many inventory services per avatar is not a control point. 
Inventory is a list of references to virtual goods. The control point is 
not when you you say
"Jacob Smith has Item 7896, which is hosted on the BlueDragonsHosting 
Asset Server, with URI "
https://BlueDragonsHosting.Assets.net/private_scheme_for_reference/asset.foo
" Whether that inventory pointer sits on a local
hard drive, in the only Inventory Service Jacob choses to use, or in a 
list in one of several services matters not at all. What is going to 
matter is what various services do with the URI and credentials Jacob 
presents when he wishes to
use the asset. That decision isn't going to happen in the inventory 
service. It isn't going to happen in the Agent Domain. That decision is 
going be the subject of policies which affect the interaction between the 
services Jacob which to
invoke and the Asset server holding the asset. 

My personal expectation is that we will have many asset servers, and most 
people will have one, or a few inventory services associated with their 
avatar. Since the inventory is nothing more than a list of asset pointers, 
Splitting it across multiple servers feels similar to splitting one's 
bookmark file. One could do it. (And one might well put a backup copy 
someplace) but. the bookmarks file has no  impact on the services I 
invoke. No matter where I get a URL, the server hosting the web page gets 
to determine if
I see it, and if I need to pass it credentials to fetch it. 

I don't see Regions, or Agent Domains as unique gatekeepers to asset 
server seedcaps. I fully expect that virtual world hosters will create 
convenient paths between their regions and any asset services they host. I 
also expect that for assets hosted
outside of their span of trust, seedcaps will be granted by the asset 
host, as it sees fit. The place where all of this plays out is in the 
protocols to permit a user to rez an item from a third party asset server, 
and the policies which influence the
use of those protocols. 

- David
~ Zha






From:
Morgaine <[e-mail]>
To:
"[e-mail]" <[e-mail]>
Date:
01/15/2010 11:09 PM
Subject:
Re: [ogpx] Cable Beach + VWRAP update
Sent by:
[e-mail]



I spoke at length with John about his blog post.

Unfortunately, it seems that his model has some serious restrictions as a 
result of hardwired service coupling, with only a single deployment model 
being allowed.  This is a deployment in which the AD dictates region asset 
policies to RDs or regions through central inventory policy.  This appears 
to be much less flexible than the multiple deployment models that we have 
been discussing here, where we gained much flexibility by using multiple 
asset services and keeping agent and region policies separate.

In addition, the model adds communication between ADs, whereas in our 
VWRAP discussions there was no communication with AD2 when an agent from 
AD1 teleported from RD1 to RD2.  Ie. we needed no prior federation, 
whereas John's model does.  In effect this proposal just extends the world 
controlled by AD1 with additional regions that have no say in local asset 
policy, as in the original OGP.  We've gone beyond that in VWRAP to allow 
for tourism between worlds with different region policies, in which only 
the agent identity and multi-world assets are common.

Also, in John's model there are no independent asset services, instead you 
can use only a single inventory service which is tightly coupled to the 
Agent Domain with which you have authenticated.  All your assets are 
accessed through this centralized inventory service, which means that your 
AD controls the region asset policy of the regions you visit, since 
whether you are allowed to acquire objects from the foreign RD2 is 
dictated by AD1 instead of by RD2.  In other words, there can be no useful 
cross-world tourism for your agent except with worlds that have assets 
allowed by your AD.

To a first degree then (and bearing in mind that I've already discussed 
this extensively  with John so this understanding is at least partially 
correct), this appears to be just the original "let's grow SL" OGP 
protocol but with OpenID added.  It doesn't appear to offer the 
cross-world interop that we've been working towards in VWRAP, since that 
requires Destination Determines (Local) Policy, just like in the real 
world.

I'll have to see the model in action to understand it fully, but at first 
glance this is a recipe for creating walled gardens with no interop at all 
except to federated worlds.  There is no deployment option in it to do any 
more, whereas we've been talking about many more deployment options 
because of the independence of VWRAP services.

As a footnote, this really highlights why such things should be discussed 
here on this list first before being added to a draft spec --- I'm very 
glad to see John doing that here and giving us the opportunity for 
comments prior to spec time.

PS. The above problems are "fixable" (but awkwardly) by making John's 
hardwired AD inventory extensible on the client.  Whenever a dictatorial 
AD disallows placing a foreign region's assets in its restricted inventory 
service, the client could automatically use a more flexible inventory 
service instead, extending symmetrically the user's perception of 
inventory contents beyond that of the AD.  I don't advocate this approach 
though, as it's a fix to a problem that shouldn't be there.  We should 
begin with a clean model from the start by keeping services decoupled so 
that a user controls which assets she references in inventory, and not her 
identity provider.


Morgaine.






=================================

On Sat, Jan 16, 2010 at 1:13 AM, Hurliman, John <[e-mail]> 
wrote:
My post got a bit long and includes some pictures, so I put the Cable 
Beach + VWRAP update in a blog post at 
http://www.jhurliman.org/2010/01/merging-vwrap-and-cable-beach/
 
The comments on that post are closed to encourage discussion to move to 
the appropriate IETF mailing list (OAuth-WG or VWRAP).
 
John

_______________________________________________
ogpx mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ogpx

_______________________________________________
ogpx mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ogpx