Re: [ogpx] Cable Beach + VWRAP update

[Morgaine <[e-mail]>]

David, your very interesting reply highlights very well why discussions
behind closed doors are not a good idea in VWRAP.  You now know things that
the rest of us had to guess at, as is evident here:


On Mon, Jan 18, 2010 at 6:13 PM, David W Levine <[e-mail]> wrote:

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


If inventory is just a list of references in VWRAP, in other words the
inventory itself is free of content-based semantics (a bit like symbolic
links in a Unix filestore), then you are absolutely right, the inventory
will not be a Policy Enforcement Point (*PEP*), to a first degree anyway.
That would remove almost entirely the biggest problem that stems from
allowing only a single inventory, since the entries could point to anything
and cannot be blocked by the AD based on type or origin.

However, as we have discussed on various occasions, inventory in SL in badly
entangled with type semantics, so the above is not the conclusion that comes
naturally when one hears that VWRAP using a Cable Beach mechanism would have
only a single inventory which lives in the AD.  It looked to me very much
like a content type or origin control point --- very bad news indeed for
VWRAP.

Not surprisingly, I am much heartened by what you have written!

(Also, John has now clarified on his article that the inventory service
could run anywhere and in more than one place  --- the diagram showing a
single inventory in the AD was just an example.  This of course means that
more than one inventory deployment pattern is possible, which is much more
flexible than it appeared at first glance.  I'm sure that open discussions
would have prevented my misunderstanding this point, but I'm very glad to
see the clarification now.  If VWRAP takes on the CB inventory mechanism
then we will need to ensure that these various deployment pattern options
are provided.)


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 ... and the Asset
server holding the asset.


Excellent!  With that clarified, the Agent Domain will indeed not be
controlling region policies such as access to region assets.  That
separation is what we need for genuine tourism to happen, where the places
visited determine what an agent can do in them (the good ol' DDP
principle).  The AD can at most only disallow the travel, and it's up to
asset services and the region to determine what happens to assets.


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.


That fits in perfectly with the direction of VWRAP discussions at the tail
end of last year, so I'm glad to hear it. :-)

I'll point out now why I said "to a first degree" in answer to your point
about PEPs.  An inventory service could be semantic-free on asset type and
origin, yet still place unwanted constraints on inventory size, shape, or
which operations allowed on inventory items.  It could also be running on
poorly resourced or unreliable hardware or provide poor uptime.  In all
these cases, inability to use a different inventory service when
authenticated with a given Agent Domain would have bad ramifications, and
could exert a sort of second-order policy control, especially in the context
of sizes.  This may be seen as less important than the usual context for
discussion about PEPs, but nevertheless it's still a good reason for
allowing non-AD inventories in the protocol.

Thanks for these clarifications, David.  I think I'm reassured that we're
still on course for a protocol with sufficient flexibility.  :-)


Morgaine.






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

On Mon, Jan 18, 2010 at 6:13 PM, David W Levine <[e-mail]> wrote:

>
> 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<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]*<[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/*<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]* <[e-mail]>*
> **https://www.ietf.org/mailman/listinfo/ogpx*<https://www.ietf.org/mailman/listinfo/ogpx>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
>