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

[Morgaine <[e-mail]>]

+1 John.

I'll try to keep the *nil trust* domain use case in focus before us as the
work proceeds, and hopefully the periodic syncs with Cable Beach features
will merge in fine when you can dedicate time to it.

Thanks for that input. :-)


Morgaine.




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

On Wed, Sep 2, 2009 at 9:40 PM, Hurliman, John <[e-mail]>wrote;wrote:

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