[ogpx] +1 on the charter (was: RE: An example to show the problems with defining an OGPX/VWRAP virtual world)

["Hurliman, John" <[e-mail]>]

You have to start somewhere. It seems like the core contributors to VWRAP are primarily interested in the use case of explicit trust domains, so they will be in a good position to carefully think through this use case and create a strong spec for it. Asking someone to spend any significant amount of effort on a use case that they have no demonstrated need for will get you a poorly though through spec at best. The explicit trust domain work that VWRAP is focusing on also does not preclude other groups from focusing more closely on the nil trust domain use case. That's the domain that my work (Intel's Cable Beach) is primarily interested in, and so far I feel that Intel's work and VWRAP's plans have nicely paralleled each other. With some effort, hopefully they will be able to merge in the future.

This is why I don't have any strong feelings on the specific wording of the charter. The primary contributors to VWRAP know what they are working on, and the capabilities (no pun intended) of the final product will speak louder than the original charter. Although there is always room for more closely defining your goals and requirements, I'm in favor of a +1 on the current charter and moving on to the next step. I can't personally commit any development effort to VWRAP work at this time, but I will continue to periodically sync Intel's Cable Beach work with the VWRAP work and aim for a merging of features in the future.

John

From: [e-mail] [mailto:[e-mail]] On Behalf Of Morgaine
Sent: Wednesday, September 02, 2009 7:27 AM
To: [e-mail]
Subject: Re: [ogpx] An example to show the problems with defining an OGPX/VWRAP virtual world

Magnus' interesting analysis effectively reaches the same conclusion that various people reached in MMOX.  I wrote a short summary of it back then -- http://www.ietf.org/mail-archive/web/mmox/current/msg01307.html .  Trust agreements will not build the metaverse, but only balkanize it.

In the end, the only trust domain likely to bloom explosively in the way that the Internet and the web did is the nil trust domain, so all this emphasis on trust agreements is largely immaterial to the worldwide spread of virtual worlds.  Trust agreements on a global scale become completely meaningless, as no trust is actually carried.  Schneier's point about "security theater" applies here completely.

Fortunately, as David Levine has said a few times, trust agreement technology does not preclude nil trust, so we can work with this.  However, it will be extremely important to ensure that the nil trust mechanism is actually catered for in practice in VWRAP, rather than just in theory.


Morgaine.






===============================
On Tue, Sep 1, 2009 at 11:06 AM, Magnus Zeisig <[e-mail]<mailto:[e-mail]>> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Sorry to crash in and sorry if my below rambling is useless, a misinterpretation, or, even worse, only mess up things even further. But I believe an example might clarify things a bit to at least some readers. If my below example is wrong, perhaps someone with a better understanding than me could correct it or provide another example.

I think one of the problems with the definitions of "virtual world" and related terminology on the list is that it's easy to lock it to the existing models, like Second Life or OpenSimulator, and not realizing that future models might be quite different. If I understand the intents and early definitions on this list right, a very small but still rather complex OGPX/VWRAP model might look like this:

Protocols

* Five geographically adjacent simulators/regions in a rectangular grid: "R11" (top left), "R12" (top right), "R21" (middle left), "R22" (middle right) and "R3" (bottom left and right, since no requirement for equal-sized or -shaped regions exists).
* Four avatars: "A1", "A2", "A3" and "A4".
* Three simulator/region owners/managers: "M1" handling "R11" and "R22", "M2" handling "R12" and "R3", and "M3" handling "R21".
* Three asset/inventory service providers: "S1" catering to "A2", "A3", "R11", "R22" and "R3", "S2" catering to "R12" and "R21", and "S3" catering to "A1" and "A4" (one region owner may employ more than one asset service, like "M2" does with "S1" for "R3" and "S2" for "R12").
* Two authentication service providers: "L1" catering to "A1", "A2" and "A4", and "L2" catering to "A3".

Note that some of the above entities may be the same company or site providing different services, e.g. "Virtual World Services, Ltd." managing both "M1", "S1" and "L1".

Policies

All simulator/region owner/managers, asset/inventory service providers and authentication service providers share a common domain of trust, with the following exceptions:
* "M2" doesn't trust "S1" (e.g. owing to previous experiences of malicious content).
* "S1" doesn't trust "M3" (e.g. owing to "M3"s refusal to sign an IP agreement).
* "M1" doesn't trust "L2" (e.g. owing to a too loose control when accepting new users).

Results

Seen from the avatars' points of view, this means:
* "A1" can move freely with all attachments and inventory through all the regions.
* "A2"  can move freely through all the regions but can't bring attachments and inventory to "R12" and "R3" owing to "M2"s distrust for "S1", and "R21" owing to "S1"s distrust for "M3".
* "A3" can only move to regions "R12", "R21" and "R3" owing to "M1"s distrust for "L2", and can't bring attachments and inventory to "R12" and "R3" owing to "M2"s distrust for "S1", and "R21" owing to "S1"s distrust for "M3", i.e. is not fully operational in any region. Also, the world is geographically split since "R12" and "R21" is only connected through a corner where it can't cross but require teleportation.
* "A4" can move freely with all attachments and inventory through all the regions.

So, to "A1" and "A4" this is a great virtual world with five fully functional regions, to "A2" it's a hobbled world where it's ruthed (forced to some generic appearence) in three out of five regions, and to "A3" it's a lousy, splitted world with only three regions in which it's all ruthed. But what really constitutes the geographic "virtual world" in this example? The five regions "R11", "R12", "R21", "R22", "R3", the three regions "R12", "R21", "R3" where all avatars can go, or no region since there is no region that is fully functional to all avatars?

I guess this is part of the reason why the exact definition of e.g. "virtual world" and "interop" is not made, because the aim of the working group is to provide the technical specs necessary to enable, but not force, the communication between such entities as mentioned in the example above, while policies might make up a totally different infrastructure and impression of what the "virtual world" or "virtual worlds" and "interop" are, or at least appear to be to the end-users (avatar owners).

Best regards,
Magnus

-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSpzyJ+5MlU9XyaiSAQgTyQf+MjeSs8iKdSWHKKPASzwa9KjmYtj8ojUg
+nqiaGtaB7lWC/Lq1PUGxMXdJvUd4AhCL96wvawWQzxAQmYYk7n0hjvs6RKub2cm
bhuvhHbEtn/9uD1tdBJvm0x+Q1ZFr6nqE2XV9cXEwlGx32/wl9aP0/wejAouqCZM
a9YQv5ceE5B3zJn54TdbFPXX8V6OZ7jtiUplP2erhUg0hkzOjVYkwt1f5G9NJhW8
p2YcTYibC0mnnu/ATzVojMhxMiQpwxRH7695TobDUdBCz48+ix1tZvkLdk9o2t2u
JodGIkTtd+mFdYOtUNbaScrTs02exahKfqD81gaEYCcLfO+J14XkkQ==
=FsIQ
-----END PGP SIGNATURE-----

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