Subject: [mmox] Another proposal for LLSD draft

From: Catherine Pfeffer <[email-masked]>
Date: Wed, 11 Feb 2009 11:50:44 +0100

Hi all,

The current xxSD draft is in no way related to virtual worlds and massively
multiparty environments. That's rather strange for something coming out from
a (future) working group named "MMOX".

As it is currently expressed, xxSD is very general and addresses the same
problems of marshalling and demarshalling structured data like CORBA, COM+,
UNO, D-Bus, Sun RPC, Web services, ... do. Even the examples in the draft
are very generic and do not show a connotation to virtual worlds.

xxSD does the job of marshalling and demarshalling structured data in a way
that is much simpler, more flexible and more adapted to virtual worlds than
these other protocols, but this might not be obvious to an external person
reading the draft. I am fearing a "why are you reinventing the wheel?"
concern.

I propose to tighten the link to virtual words by specifying how typical
virtual worlds data fit in the general principles expressed in the draft.

We could add a section saying that :
 - a 3D vector is to be represented by an array of three reals, in the x, y,
z order
 - a 2D vector is to be represented by an array of three reals, in the x, y
order (for hypothetical 2D virtual worlds, why not)
 - a rotation is expressed by a quaternion in the order X, Y, Z, S (or S, X,
Y, Z if we want to be maths-compatible and not linden labs-compatible)
 - say if this quaternion needs being normalized (X² + Y² + Z² + S² = 1) or
not.
 - etc...

This would also spare another document/draft that would need to express
these constraints ;-).

My two cents.

-- 
Catherine Pfeffer

---

From: Mark Lentczner <[email-masked]>
Date: Wed, 11 Feb 2009 09:01:36 -0800

Catherine raised many good points about this that I'm sure we'll see  
again and again, so I hope we'll form consensus about this soon.

On the one hand, it is indeed correct, LLSD and LLIDL, as they sit are  
not particularly virtual world specific. They could be used in many  
other contexts.  Along with the upcoming OGP Base draft (I'm workin'  
on it...), it defines a general system for loosely coupled systems to  
interact over the Internet.

On the other hand, LLSD (and the upcoming OGP Base) were motivated by  
the particular problem that Virtual World interoperability presented:  
Such a system requires specification of a large number of messages  
with rich semantics (it takes a large feature set to make a virtual  
world work), while at the same time requiring heavy resilience in the  
face of version compatibility.

We reviewed the host of available options as a substrate for OGP, and  
found them lacking for the needs of virtual worlds: Those that  
supported large, rich APIs generally were very rigid about versioning  
or expected tightly coupled systems. Those that were designed for  
loosely coupled systems generally could only support very simple or  
generic semantics.

This led us to create LLSD and LLIDL, which are admittedly more  
generic than virtual worlds, because other systems didn't fit the  
requirements well. That all said, we found numerous examples of APIs  
springing up on the web that could use this level of formalism for  
both data transport and specification. Most have home-spun data  
systems and use English and web pages for humans as the only  
specification language. Examples are Flickr API and Amazon's S3 and  
EC2. I wonder if we've hit something more broadly useful.

I do think that we should, somewhere, define a larger set of composite  
data structures that will be used time and again in the context of  
virtual worlds.  The examples you gave are dead on: 3D and 2D vectors  
and quaternions. There are also things like defining units for common  
scalars such as length, mass, acceleration, etc. I don't know if these  
belong in the LLSD draft or in another.

	- Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

---

From: Jon Watte <[email-masked]>
Date: Wed, 11 Feb 2009 10:40:42 -0800

Catherine Pfeffer wrote:
> I propose to tighten the link to virtual words by specifying how 
> typical virtual worlds data fit in the general principles expressed in 
> the draft.

What kinds of virtual world data do you imagine running through this system?
Service requests?
Service request responses?
Mesh data?
Animation data?
Terrain data?
Entity behavior?
Multimedia streams?
Real-time interactions?
User input/control data?
Network packet structure?
Entity interactions?
Database records?
On-disk files?

Each of these usage scenarios have different requirements. For example, 
as proposed, LLSD might be fine for service requests, but would probably 
fall short for something like terrain data (which requires indexing and 
random access).

Sincerely,

jw

---

From: Morgaine Dinova <[email-masked]>
Date: Thu, 12 Feb 2009 04:23:19 +0000

Jon makes an important point through his question I think.

Unless the MMOX protocols are intended to carry EVERYTHING related to VWs
(and they well might, though I doubt it), we really need to partition the
universe of discourse into those things that we intend to cover and those
things that we don't.  A list of inclusions and exclusions (if any) would be
very useful to direct the discussion ahead.

As OGP is currently the only specific proposal on the table (we're waiting
for John to deliver his counter-proposal), I think it would be appropriate
and helpful if OGP designers could give us a tentative list here to outline
their thinking.

Morgaine.

On Wed, Feb 11, 2009 at 6:40 PM, Jon Watte <[email-masked]> wrote:

> Each of these usage scenarios have different requirements. For example, as
> proposed, LLSD might be fine for service requests, but would probably fall
> short for something like terrain data (which requires indexing and random
> access).
>
> Sincerely,
>
> jw
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

---

From: Jon Watte <[email-masked]>
Date: Thu, 12 Feb 2009 11:39:15 -0800

Morgaine Dinova wrote:
> Unless the MMOX protocols are intended to carry EVERYTHING related to 
> VWs (and they well might, though I doubt it), we really need to 
> partition the universe of discourse into those things that we intend 
> to cover and those things that we don't.  A list of inclusions and 
> exclusions (if any) would be very useful to direct the discussion ahead.

I don't even yet understand what mode of interoperability you're 
tackling here. For example, there's the "universal client" ghost, which 
doesn't actually solve any real business problems. Then there's the 
"porting content" area, where we're seeing a lot of demand from 
customers. There's also "tieing servers together" which actually enables 
new and interesting, never-before-seen applications.

For an argument for why a "universal client" is a non-solution, see 
http://www.interopworld.com/node/31
For a description of what "tieing server together" might enable, see 
http://www.interopworld.com/node/22

So, before we start talking too much about specific details of 
serializing data, I think it would be great if we first figured out what 
kinds of new applications we're trying to enable through interoperability.

Sincerely,

jw

---

From: Lawson English <[email-masked]>
Date: Thu, 12 Feb 2009 15:09:19 -0700

A fully universal client would be, as you put it, impossible, if for no 
other reason than proprietary innnovation would preclude an open source 
version, but that doesn't mean we can't work on a reasonably robust 
lowest common denominator of some kind that will handle most cases. Look 
at what the people from realXtend have managed to do with the GPL Second 
Life client, even given its legacy [non] design.

L

Jon Watte wrote:
> tackling here. For example, there's the "universal client" ghost, 
> which doesn't actually solve any real business problems. Then there's 
> the "porting content" area, where we're seeing a lot of demand from 
> customers. There's also "tieing servers together" which actually 
> enables new and interesting, never-before-seen applications.
>
> serializing data, I think it would be great if we first figured out 
> what kinds of new applications we're trying to enable through 
> interoperability.
>
> Sincerely,
>
> jw
>

---

From: Jon Watte <[email-masked]>
Date: Thu, 12 Feb 2009 15:22:24 -0800

Lawson English wrote:
> A fully universal client would be, as you put it, impossible, if for 
> no other reason than proprietary innnovation would preclude an open 
> source version, but that doesn't mean we can't work on a reasonably 
> robust lowest common denominator of some kind that will handle most 
> cases. Look at what the people from realXtend have managed to do with 
> the GPL Second Life client, even given its legacy [non] design.

I believe that argument misses the point: A universal client is almost 
value-less to a typical user. The only problem a universal client woudl 
solve is having to install two separate binaries on the hard disk. If 
you play both WoW and Counterstrike, how much would it be worth to you 
to be able to keep one binary on the hard disk instead of two? (Note 
that the assets, which are the majority of the size, still need to be 
separate) My estimation is "not more than a few cents," and certainly 
not worth spending any actual time on anytime soon.

A universal client doesn't actually enable any new applications.

A new application is to have virtual world A and virtual world B 
collaborate, so that users in one see users/objects/interactions in the 
other, and vice versa. A universal client doesn't do that at all, 
because it would have to treat two different virtual worlds as separate 
walled gardens. The whole point of interoperability, to me, is to tear 
down those walls. It shouldn't matter if you, personally, use Qwaq Web 
Forums, Active Worlds, OLIVE, Second Life, Open Sim, Proton Media, Blue 
Mars, Kaneva, Multiverse, Areae or one of the many other virtual worlds 
on the market that solve different problems. You should still be able to 
"go visit" with some of your friends in some shared space, with friends 
who use some other platform. Once you apply that concept to real 
activities (city planning, emergency management, corporate meetings, 
etc) you have something truly powerful and worthwhile -- similar to long 
distance telephones being able to call between different phone company 
customers, using switching equipment purchased from different vendors.

Note that, once you have that working, you don't even need a universal 
client, because you can go visit any world through the system you're 
using (you're most comfortable with, or your enterprise has standardized 
on, or whatever). Compare with Lotus Notes, Microsoft Exchange, Sendmail 
and other mail solutions. They don't use the same client/server protocol 
for the clients, but they interoperate just fine!

So, again, let's back up to a higher level:
/Is the goal to make sure that different virtual worlds, from different 
vendors, can meaningfully interoperate?/
If so, the particular data marshaling solution chosen for the lowest 
level of some of the protocols involved is a fairly insignificant part 
compared to the whole scope of what needs to be done.

For example, I would assume that geometry and animation interop happens 
through some already existing, well-defined open standard, such as 
COLLADA or X3D, rather than some arbitrary binary format, either new or 
vendor-specific. Those open formats aren't tied to LLSD (or any other 
serialization library) at all, and probably represent the largest amount 
of data that needs to be exchanged, except for terrain.

Sincerely,

jw

---

From: Dahlia Trimble <[email-masked]>
Date: Thu, 12 Feb 2009 16:27:58 -0800

I think Collada is intended as a way to connect design tools together in a
content creation workflow and is not really meant to be a wire protocol for
end-user mass distribution of content, such as may occur between a virtual
reality simulation between servers and clients. Collada is not designed for
efficiency of asset size.

On Thu, Feb 12, 2009 at 3:22 PM, Jon Watte <[email-masked]> wrote:

>> version, but that doesn't mean we can't work on a reasonably robust lowest
>> common denominator of some kind that will handle most cases. Look at what
>> the people from realXtend have managed to do with the GPL Second Life
>> client, even given its legacy [non] design.
>>
>
> solve is having to install two separate binaries on the hard disk. If you
> play both WoW and Counterstrike, how much would it be worth to you to be
> able to keep one binary on the hard disk instead of two? (Note that the
> assets, which are the majority of the size, still need to be separate) My
> estimation is "not more than a few cents," and certainly not worth spending
> any actual time on anytime soon.
>
> other, and vice versa. A universal client doesn't do that at all, because it
> would have to treat two different virtual worlds as separate walled gardens.
> The whole point of interoperability, to me, is to tear down those walls. It
> shouldn't matter if you, personally, use Qwaq Web Forums, Active Worlds,
> OLIVE, Second Life, Open Sim, Proton Media, Blue Mars, Kaneva, Multiverse,
> Areae or one of the many other virtual worlds on the market that solve
> different problems. You should still be able to "go visit" with some of your
> friends in some shared space, with friends who use some other platform. Once
> you apply that concept to real activities (city planning, emergency
> management, corporate meetings, etc) you have something truly powerful and
> worthwhile -- similar to long distance telephones being able to call between
> different phone company customers, using switching equipment purchased from
> different vendors.
>
> client, because you can go visit any world through the system you're using
> (you're most comfortable with, or your enterprise has standardized on, or
> whatever). Compare with Lotus Notes, Microsoft Exchange, Sendmail and other
> mail solutions. They don't use the same client/server protocol for the
> clients, but they interoperate just fine!
>
> If so, the particular data marshaling solution chosen for the lowest level
> of some of the protocols involved is a fairly insignificant part compared to
> the whole scope of what needs to be done.
>
> through some already existing, well-defined open standard, such as COLLADA
> or X3D, rather than some arbitrary binary format, either new or
> serialization library) at all, and probably represent the largest amount of
> data that needs to be exchanged, except for terrain.
>
>
> Sincerely,
>
> jw
>

---

From: Jon Watte <[email-masked]>
Date: Thu, 12 Feb 2009 20:35:15 -0800

Dahlia Trimble wrote:
> I think Collada is intended as a way to connect design tools together 
> in a content creation workflow and is not really meant to be a wire 
> protocol for end-user mass distribution of content, such as may occur 
> between a virtual reality simulation between servers and clients. 
> Collada is not designed for efficiency of asset size. 

Are you saying that using an established public standard is not 
desirable, or do you have a specific problem with COLLADA? Compare to 
X3D or MPEG-4 meshes, say? (which have a binary representation, and are 
designed explicitly for virtual worlds)

I think COLLADA may actually win out for pragmatic reasons, though. It 
has excellent tools support compared to most other formats, and a number 
of large content repositories (including the Google Warehouse) are 
available in COLLADA (that's what's on the inside of the kmz files). 
Given that the kmz files are compressed, the size is not orders of 
magnitude bigger than what you would see with a custom format anyway.

If you want a really compressed, custom, binary format, that is still a 
well-defined standard, then take a look at the MPEG-4 mesh and avatar 
standards. They are also well defined standards, since many years back, 
and there exist people who implement it, but personally I think it's the 
least well supported of the three open standards (COLLADA being tops, 
followed by X3D, followed by MPEG-4).

Sincerely,

jw

---

From: Morgaine Dinova <[email-masked]>
Date: Fri, 13 Feb 2009 06:45:55 +0000

On Thu, Feb 12, 2009 at 7:39 PM, Jon Watte <[email-masked]> wrote:

> I don't even yet understand what mode of interoperability you're tackling
> here. For example, there's the "universal client" ghost, which doesn't
> actually solve any real business problems. Then there's the "porting
> content" area, where we're seeing a lot of demand from customers. There's
> also "tieing servers together" which actually enables new and interesting,
> never-before-seen applications.
>

Jon, we've been discussing interoperability goals and designs in the
Architecture Working Group (AWG), a technical group hosted within the Second
Life world, for 16 months now, and many of us a lot longer.  The AWG was
founded with the dual goals of addressing broad interoperability and also
the high scalability needs that come naturally with interoperating worlds.
If you had been part of that process, the premise and goals would hopefully
be clear.

This of course can be remedied.  One of our tasks in MMOX should probably be
to make readily available adequate background information to help answer
such questions, since they will be asked frequently.  This information forms
the premise for our work, and therefore we have to describe it effectively.

In a nutshell though, our interoperability goals are as minimally
prescriptive as possible, because different worlds will differ markedly in
both philosophy and implementation, and therefore it is simply not possible
to impose anything amounting to a straightjacket.  It would not be accepted,
and quite possibly it would not be viable to implement either.  Therefore
our overall goal is a lightweight one that can embrace diversity.

In my own words and very much off the cuff, we are defining a protocol that
allows entirely different virtual worlds to access and exchange data objects
that are meaningful across a large spectrum of world types.  This is
achieved by limiting the protocol to common concepts such as login (for
identity), location, teleport, travel, avatars, and messaging, as well as
offering an extensible set of common 3D objects as building blocks that can
be exchanged.  It is a strongly abstracted approach, as independent of
actual implementation details as we can make it, because there is no other
way to embrace the current diversity of worlds let alone the future one.

This will not have answered your question to any useful extent, but I hope
that you'll see why and where we're going and the fruits of the long process
that has led to MMOX in the week to come.

Meanwhile, it would indeed help if the primary OGP designers were to
enumerate what is included and what is excluded from the design proposal
that will be presented as one possible starting point for MMOX
consideration.  (OGP is the interop protocol and project started by LL+AWG
several months ago, of which a very small part is already implemented in
Second Life.)

Morgaine.

---

From: Dahlia Trimble <[email-masked]>
Date: Fri, 13 Feb 2009 00:36:38 -0800

I have nothing against Collada. Here is a quote from
http://www.khronos.org/collada/

"*COLLADA is a XML database schema for 3D assets*
COLLADA is an intermediate language - not a delivery format and not a scene
graph"

On Thu, Feb 12, 2009 at 8:35 PM, Jon Watte <[email-masked]> wrote:

> Are you saying that using an established public standard is not desirable,
> or do you have a specific problem with COLLADA? Compare to X3D or MPEG-4
> meshes, say? (which have a binary representation, and are designed
> explicitly for virtual worlds)
>
> I think COLLADA may actually win out for pragmatic reasons, though. It has
> excellent tools support compared to most other formats, and a number of
> large content repositories (including the Google Warehouse) are available in
> COLLADA (that's what's on the inside of the kmz files). Given that the kmz
> files are compressed, the size is not orders of magnitude bigger than what
> you would see with a custom format anyway.
>
> standards. They are also well defined standards, since many years back, and
> there exist people who implement it, but personally I think it's the least
> well supported of the three open standards (COLLADA being tops, followed by
> X3D, followed by MPEG-4).
>
> Sincerely,
>
> jw
>
>

---

From: thomas kirk <[email-masked]>
Date: Fri, 13 Feb 2009 07:22:16 -0500

the suggestion from Jon Watte to pop up to a higher level of
discussion is a good one -- seems worthwhile to start off with 
some common understanding of what interoperability means.
Long-time AWG members undoubtedly have particular notions of 
interoperability, so that's probably a good starting point, 
but the rest of us are missing that context, and laying out a 
clear high-level roadmap would make the overall objectives 
more accessible to other communities who may wish to be 
involved with this work (or at least be aware of it).

---

From: Suzy Deffeyes <[email-masked]>
Date: Fri, 13 Feb 2009 07:43:58 -0600

On Thu, Feb 12, 2009 at 10:35 PM, Jon Watte <[email-masked]> wrote:
> I think COLLADA may actually win out for pragmatic reasons

I also think COLLADA will be popular in this space for interchange,
For example, it's already extending beyond its original intended use
as a toolchain interchange format for game developers into the CAD
space (COLLADA 1.5 brep spec).

X3D tends to force an event model on your app, and it has had a tough
time overcoming the baggage of being a descendant of VRML. I don't
think we'd be able to build consensus in adopting it in MMOX.

That said, I think the geometry interchange might not be the first
thing the group tackles. (please, as a COLLADA working group member,
I'd love it if you prove me wrong!).

I think we should look for something small that can be sanely
separated and would have a consensus among the wide use cases we want
to support. Am I unrealistic?  What would that small piece be?

Suzy Deffeyes
IBM

---

From: Lawson English <[email-masked]>
Date: Fri, 13 Feb 2009 13:22:14 -0700

> to support. Am I unrealistic?  What would that small piece be?

Even geometry exchange between "SL-compatible" worlds becomes a sticky 
issue. Compare
realXtend avatars with SL avatars for example...

One thing that everyone seems to want in SL is support for generic 
meshes ala .obj files. This is
just the tip of the iceberg for what is needed for interop, of course.

One of the biggest issues for Second Life, which few other virtual 
worlds have to address, is
the economic/social/legal issues for intellectual property. There are 
people who make a real world
living designing avatars and clothing for them in Second LIfe. How does 
one transport such stuff around
in a metaverse? The technical details are nothing compared to the 
social/legal/ethical/etc details
and interop protocols have to allow for THAT also.

L.

---

From: Jon Watte <[email-masked]>
Date: Fri, 13 Feb 2009 13:08:38 -0800

Morgaine Dinova wrote:
> Architecture Working Group (AWG), a technical group hosted within the 
> Second Life world, for 16 months now, and many of us a lot longer.  
> The AWG was founded with the dual goals of addressing broad 
> interoperability and also the high scalability needs that come 
> naturally with interoperating worlds.  If you had been part of that 
> process, the premise and goals would hopefully be clear.
>

 From what I understand, the AWG is Second Life derived technology 
specific, which is of very low interest to my particular market. The 
reason I found this BoF interesting was that it claimed to want to take 
a vendor neutral approach, which I'm all for. (I, too, sit on a code 
base of several million lines of code, with lots of heavily entrenched 
users accumulated over the last 10 years -- I wouldn't expect to 
standardize the internals of that)

> In my own words and very much off the cuff, we are defining a protocol 
> that allows entirely different virtual worlds to access and exchange 
> data objects that are meaningful across a large spectrum of world 
> types.  This is achieved by limiting the protocol to common concepts 
> such as login (for identity), location, teleport, travel, avatars, and 
> messaging, as well as offering an extensible set of common 3D objects 
> as building blocks that can be exchanged.  It is a strongly abstracted 
> approach, as independent of actual implementation details as we can 
> make it, because there is no other way to embrace the current 
> diversity of worlds let alone the future one.

That's fine. I believe that things like "terrain" or "avatar" or 
"interaction" are abstract enough that many different worlds can agree 
on them. In fact, I have been delivering interoperable virtual worlds to 
various organizational customers for the last 5 years or so, and a while 
back I wrote up my experiences from having done that. You probably will 
find some common ground if you read up on that (so I don't have to 
re-post all of it to this list, which would be pretty large and annoying):

Starting with the use case here:
http://www.interopworld.com/members/node/22
I go down one level in what pieces will actually be needed, with 
strawman examples as illustration:
http://www.interopworld.com/vwsis

For reference, the by far most successful virtual world interoperability 
protocol over the last 20 years is DIS (IEEE 1278). Unfortunately, it 
has a number of problems, such as being highly military specific, and 
being way too verbose (as it relies on PDUs and UDP broadcast sharing), 
but I think the success of DIS in bridging very disparate systems into 
functioning, shared worlds should not be under-estimated!

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Fri, 13 Feb 2009 13:16:57 -0800

Lawson English wrote:
> living designing avatars and clothing for them in Second LIfe. How 
> does one transport such stuff around

I think the There.com people has had some of the same problems for the 
last 6 years or so, btw. When I asked them how they solved it, they 
claim to solve it through their content submission screening process, 
which seems labor intensive to me, but does provide some level of value 
to their users and developers.

However, at the extent, any object that you show to a general user is 
"open" to that user; he/she can use an asset ripper at one of many 
levels (including hooking the graphics drivers), so you can't 
technically prevent criminal intent. However, each particular world has 
to make a determination on how "far" their content sublicensing rights 
extend.

For example, if I build a sofa, and sell it to you. Then you host a 
meeting SL where someone from There.com visits, then that sofa needs to 
be shared to the There.com system, and through that system to the 
viewing client.
You have implicitly already given the viewing client the right to view 
the object, though, so it's not unreasonable to believe that any router, 
cache, or other system on the way also has the right to view the object. 
It seems to me that the important parts to make sure are represented are:
1) Make sure that authorship and sharing rights are carried as metadata 
with any object
2) Make sure that the policy for caching in different parts of the 
system take this into account
3) Put requirements that these policies are followed into the standards 
language

After that, there's really nothing that a vendor can do, technically, to 
prevent users who want to break the law.

So, I think it's fine to say that "any interoperability standard must 
address content metadata, including authorship, ownership and sharing 
rights," but I don't think that mandating specific technical solutions 
(like specific DRM solutions) would be fruitful.

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Fri, 13 Feb 2009 14:00:05 -0800

Morgaine Dinova wrote:
> the protocol to common concepts such as login (for identity)

Hmm. I can't think of a good use case where "login" would make sense for 
standardization.

If I'm logged into Blue Mars, and want to collaborate with someone in 
Club Penguin (run with me, here, this is an example :-), then I 
shouldn't have to have an account in Club Penguin to do that. The person 
I collaborate with should similarly not have to have an account with 
Blue Mars to interop.

The concept of "identity" collapses down to "responsible party" I think. 
Thus, the entire "Club Penguin" system could be one "responsible party," 
although sub-identifiers for each user within there would probably be 
desirable. Thus, an authentication token might look something like:

auth-domain : auth-name : expiry-time : auth-cookie  (Kerberos, anyone? :-)

In this case,

"clubpenguin.com" : "My Cool Penguin" : "Tomorrow" : hash(expirytime + 
name + some secret key)

For that, in turn, to make sense, there needs to be a separate back 
channel where the Blue Mars system can contact the club penguin system 
and verify that the credentials are indeed valid, and perhaps negotiate 
information about the credentials (age group for content rating, e-mail 
address for contact, perhaps in the future negotiated microtransactions, 
etc).

I guess I think "identity" or "responsible party" is a better name for 
this concept than "login," because "login" has a number of connotations 
I don't think it shares.

And, yes, in some future, certain providers may deem that other 
providers are un-trust-worthy, and restrict the set of available 
interactions (possibly down to zero) for certain auth domains. I think 
that needs to be a supported scenario.

Sincerely,

jw

---

From: David W Levine <[email-masked]>
Date: Fri, 13 Feb 2009 20:39:42 -0500

I think this is one way  (quite possibly the predominant way) that we will 
handle "cross domain" issues of identity and authentication. I would add 
one non-trivial caveat here. We probably can (and should) design things so 
that decisions such as "I require an explicit login to my local service 
from the end user" are driven by policy, rather than mechanism.  I for one 
don't  care to log in, in various ways, to various systems in order to 
interact with users on them. At the same time, I can see cases where there 
will be deployed portions of a greater grid of immersive virtual spaces 
which do not share mutual trust at the level required to permit a "system 
mediated cross authentication"  Ideally, this can be handled by policy, 
and  people who wish to deploy such systems can share as much or as little 
trust as they care to. The mechanisms don't change, just the policy. 

Having said this, I will freely admit the balancing act here. The more you 
push choices out to policy, the easier it is to create fully compliant 
implementations which interoperate only in the very most theoretical 
sense, and end up having to have profiles, or similar mechanisms so you 
can decide if you can, in fact talk to a compliant services. 

- David W. Levine
~ Zha Ewry (ISL) 

Jon Watte <[email-masked]> 
Sent by: [email-masked]
02/13/2009 05:00 PM

To
Morgaine Dinova <[email-masked]>
cc
[email-masked]
Subject
Re: [mmox] Another proposal for LLSD draft

auth-domain : auth-name : expiry-time : auth-cookie  (Kerberos, anyone? 
:-)

In this case,

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Fri, 13 Feb 2009 20:48:48 -0800

David W Levine wrote:
>
> I think this is one way  (quite possibly the predominant way) that we 
> will handle "cross domain" issues of identity and authentication. I 
> would add one non-trivial caveat here. We probably can (and should) 
> design things so that decisions such as "I require an explicit login 
> to my local service from the end user" are driven by policy, rather 
> than mechanism.  I for one don't  care

Well, what good is interoperability if the user has to create an account 
on each system he wants to interoperate with? That's a bit like having 
to get a Verizon phone plan to be able to call someone who has a Verizon 
cell phone...
Anyway, I agree that more than one identity could be carried, and 
perhaps requested, through the identity channel. You have to be careful 
that the actual identity token is issued to the user, not the the 
intermediary, though, to avoid impersonation attacks.

Sincerely,

jw