Subject: [ogpx] An example to show the problems with defining an OGPX/VWRAP virtual world

From: "Magnus Zeisig" <[email-masked]>
Date: Tue, 1 Sep 2009 12:06:31 +0200

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

---

From: Morgaine <[email-masked]>
Date: Wed, 2 Sep 2009 15:26:58 +0100

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 <[email-masked]> 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).
> * 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").
> 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:
> * "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.
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>

---

From: "Hurliman, John" <[email-masked]>
Date: Wed, 2 Sep 2009 14:40:44 -0600

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: [email-masked] [mailto:[email-masked]] On Behalf Of Morgaine
Sent: Wednesday, September 02, 2009 7:27 AM
To: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:

Protocols

Policies

Results

Best regards,
Magnus

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

---

From: Morgaine <[email-masked]>
Date: Wed, 2 Sep 2009 22:07:47 +0100

+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 <[email-masked]>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:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Morgaine
> *Sent:* Wednesday, September 02, 2009 7:27 AM
> *To:* [email-masked]
> *Subject:* Re: [ogpx] An example to show the problems with defining an
> OGPX/VWRAP virtual world
>
>
>

---

From: Dan Olivares <[email-masked]>
Date: Wed, 2 Sep 2009 18:25:06 -0400

+ 1 on the charter also

Regards

Dan

On Wed, Sep 2, 2009 at 5:07 PM, Morgaine<[email-masked]> wrote:
> +1 John.
>
> I'll try to keep the nil trust domain use case in focus before us as the
>> 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
>> that the Internet and the web did is the nil trust domain, so all this
>> * "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".

---

From: Carlo Wood <[email-masked]>
Date: Thu, 3 Sep 2009 00:25:44 +0200

On Wed, Sep 02, 2009 at 03:26:58PM +0100, Morgaine wrote:
> 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.

+1

-- 
Carlo Wood <[email-masked]>

---

From: Infinity Linden <[email-masked]>
Date: Wed, 2 Sep 2009 16:11:23 -0700

it should probably go without saying that i +1 the charter, but for
completeness sake, let me just say...

+1 on the charter

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 02 Sep 2009 16:24:09 -0700

+1

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Suzy Deffeyes <[email-masked]>
Date: Wed, 2 Sep 2009 20:18:34 -0400

+1 as well. Muchos thanks to all who commented and provided input to the draft.

Suzy Deffeyes
IBM

On Wednesday, September 2, 2009, Infinity Linden <[email-masked]> wrote:
>>>> it wil

---

From: Joshua Bell <[email-masked]>
Date: Wed, 2 Sep 2009 16:52:46 -0700

On Wed, Sep 2, 2009 at 3:25 PM, Carlo Wood <[email-masked]> wrote:

> technology
+1 as well. As Morgaine pointed out, this little thing called "the Web"
seems to have caught on due to this stance. :)

I would caution that Virtual Worlds with portable, persistent identity don't
have it quite so easy as the Web since the user is an active participant
from the get-go (your avatar's identity gets sent to places you visit)
rather than a passive consumer of data. The Web is late to the game in
tackling that with efforts such as OpenID and OAuth, and even venerable
e-mail strains under not having a well established concept of trust (the
gaping void between easy/spam and onerous/PKI, sprinkled with efforts like
SPF). We must tackle this from the start.

But again, +1.