Subject: [mmox] OGP scalability concerns

From: "Hurliman, John" <[email-masked]>
Date: Wed, 1 Apr 2009 14:56:41 -0600

A few days ago I posted an e-mail highlighting my concerns with the architecture of OGP. I'm not sure if there was an implicit agreement from the OGP authors or if the e-mail was lost in the flood. I'm reposting in a new thread because I want to make sure I have a proper understanding of the architecture.

>*	Indirectly, it highlights that the Agent Domain model does not
>have a solution to the problem of accessing worlds with which there is 
>no trust agreement.  People will want to enter arbitrary worlds, and 
>therefore that restriction is inadequate.
>*	There will be millions of worlds in an Internet-scale metaverse,
>which makes the concept of interop through trust agreements far too 
>narrow.  Trust loses its meaning entirely when scaled to millions, 
>becoming mere paperwork or "security theater".
 
This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps (whitelists) work great when IBM wants to define policy to connect to the Linden Lab grid, but has no meaning and no hope of scaling when you talk about defining trust for millions of simulation grids and millions (or at least thousands) of identity providers. This is the primary reason that Intel and many members of the OpenSimulator/OpenMetaverse community have not considered OGP as a strong proposal for virtual world interoperability. If this understanding is not accurate, it would be helpful if an OGP author could step in and clear up the confusion.

John

---

From: Morgaine <[email-masked]>
Date: Wed, 1 Apr 2009 23:37:27 +0100

On Wed, Apr 1, 2009 at 9:56 PM, Hurliman, John <[email-masked]>wrote:

A few days ago I posted an e-mail highlighting my concerns with the
> architecture of OGP. I'm not sure if there was an implicit agreement from
> the OGP authors or if the e-mail was lost in the flood. I'm reposting in a
> new thread because I want to make sure I have a proper understanding of the
> architecture.
>
>
John, I don't think that it indicates implicit agreement nor that your post
was lost in the flood.  It's more a reflection of the fact that we've not
had a single comment from OGP designers at all here since the BoF, on
*any*topic. :-)

I'm not sure where they've got to, but they're not engaging in technical
discussions with the list at this time.  You haven't missed any responses,
afaik. ;-)

Morgaine.

On Wed, Apr 1, 2009 at 9:56 PM, Hurliman, John <[email-masked]>wrote:

> A few days ago I posted an e-mail highlighting my concerns with the
> architecture of OGP. I'm not sure if there was an implicit agreement from
> the OGP authors or if the e-mail was lost in the flood. I'm reposting in a
> new thread because I want to make sure I have a proper understanding of the
> architecture.
>
>
> This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps
> (whitelists) work great when IBM wants to define policy to connect to the
> Linden Lab grid, but has no meaning and no hope of scaling when you talk
> about defining trust for millions of simulation grids and millions (or at
> least thousands) of identity providers. This is the primary reason that
> Intel and many members of the OpenSimulator/OpenMetaverse community have not
> considered OGP as a strong proposal for virtual world interoperability. If
> this understanding is not accurate, it would be helpful if an OGP author
> could step in and clear up the confusion.
>
> John
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Wed, 1 Apr 2009 16:53:26 -0700

On Apr 1, 2009, at 1:56 PM, Hurliman, John wrote:

> architecture of OGP. I'm not sure if there was an implicit agreement  
> from the OGP authors or if the e-mail was lost in the flood. I'm  
> reposting in a new thread because I want to make sure I have a  
> proper understanding of the architecture.
>
>

i would guess the solution would be to have a promiscuous agent domain  
that has a "i will trust all worlds" settings. i think this is a  
limitation of the implementation, not the architecture.

>> becoming mere paperwork or "security theater".

+1. what's your suggestion?

>
> This is, in my opinion, the fundamental flaw in OGP. Explicit trust  
> maps (whitelists) work great when IBM wants to define policy to  
> connect to the Linden Lab grid, but has no meaning and no hope of  
> scaling when you talk about defining trust for millions of  
> simulation grids and millions (or at least thousands) of identity  
> providers. This is the primary reason that Intel and many members of  
> the OpenSimulator/OpenMetaverse community have not considered OGP as  
> a strong proposal for virtual world interoperability. If this  
> understanding is not accurate, it would be helpful if an OGP author

---

From: Charles Krinke <[email-masked]>
Date: Wed, 1 Apr 2009 16:01:14 -0800

To me, interop implies a full handoff of an avatar from one virtual world to
another.

I can appreciate OGP offering one half of this in its current form in a
teleport from a SecondLife type grid to an OpenSim type grid. But, we also
need to consider how a citizen of an OpenSim grid can teleport to a
SecondLife grid as well.

In the case of OpenSim grids, we have a UserServer as opposed to an
AgentDomain, but they offer a similar set of services.

So, from the MMOX viewpoint, we could perhaps get there from here if we were
to consider the fact that each side of this teleport needs to be treated in
an equal and sovereign manner.

To me, interop between grids is more of a "border crossing & customs"
paradigm. That is, each grid may have its own border crossing rules for exit
and its own customs rules for entry and each is sovereign in its own right.
That is, there is no overwhelming AgentDomain that controls all teleports
between all grids, but rather an AgentDomain is a paradigm for one
particular grid, or in the SecondLife case, for a few SecondLife grids all
under the control of one corporate personality.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Wed, Apr 1, 2009 at 3:53 PM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

> i would guess the solution would be to have a promiscuous agent domain that
> has a "i will trust all worlds" settings. i think this is a limitation of
> the implementation, not the architecture.
>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Wed, 1 Apr 2009 17:06:55 -0700

sheesh. you miss one awg meeting and you're branded a deserter!

but yes... Robla, Zero and I spent most of our week last week at the  
IETF meeting. fwiw... we had more to chat about there than MMOX, which  
is why we weren't online much in the latter part of the week. And...  
being gone from the office for a week allows a bunch of stuff to pile  
up, which is why i've been very nearly completely unreachable (mea  
culpa.) I suspect the situation is radically similar for Zero.

-cheers
-opt 5

On Apr 1, 2009, at 3:37 PM, Morgaine wrote:

> On Wed, Apr 1, 2009 at 9:56 PM, Hurliman, John <[email-masked] 
> > wrote:
>
> John, I don't think that it indicates implicit agreement nor that  
> your post was lost in the flood.  It's more a reflection of the fact  
> that we've not had a single comment from OGP designers at all here  
> since the BoF, on any topic. :-)
>
> I'm not sure where they've got to, but they're not engaging in  
> technical discussions with the list at this time.  You haven't  
> missed any responses, afaik. ;-)
>
> Morgaine.
>
>
>
>
>
>
>
>
>
> On Wed, Apr 1, 2009 at 9:56 PM, Hurliman, John <[email-masked] 
> > wrote:

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Wed, 1 Apr 2009 17:30:25 -0700

Charles... i _think_ we're in radical agreement. Some might read that  
first sentence as meaning, "you're not fully interoperable unless you  
can teleport from second life to wonderland to world of warcraft to  
every other virtual world in existence." But the second sentence seems  
to imply you're really just talking about "second life-like" systems.  
If you mean the former... ouch... that's going to be difficult (though  
i'm sure JW would disagree.) If the latter, then yes, you're right...  
we're not fully interoperable (in the OGP sense) until you can  
teleport from a linden controlled server to a OSgrid controlled?  
federated? server, and then turn around and go back the other way.

On Apr 1, 2009, at 5:01 PM, Charles Krinke wrote:

> To me, interop implies a full handoff of an avatar from one virtual  
> world to another.
>
> I can appreciate OGP offering one half of this in its current form  
> in a teleport from a SecondLife type grid to an OpenSim type grid.  
> But, we also need to consider how a citizen of an OpenSim grid can  
> teleport to a SecondLife grid as well.
>
> So, from the MMOX viewpoint, we could perhaps get there from here if  
> we were to consider the fact that each side of this teleport needs  
> to be treated in an equal and sovereign manner.
>
> To me, interop between grids is more of a "border crossing &  
> customs" paradigm. That is, each grid may have its own border  
> crossing rules for exit and its own customs rules for entry and each  
> is sovereign in its own right. That is, there is no overwhelming  
> AgentDomain that controls all teleports between all grids, but  
> rather an AgentDomain is a paradigm for one particular grid, or in  
> the SecondLife case, for a few SecondLife grids all under the  
> control of one corporate personality.
>
> Charles Krinke
> OpenSim Core Developer
> OSGrid Director
>
>
>
>
> On Wed, Apr 1, 2009 at 3:53 PM, Meadhbh Hamrick (Infinity) <[email-masked] 
> > wrote:
>
> i would guess the solution would be to have a promiscuous agent  
> domain that has a "i will trust all worlds" settings. i think this  
> is a limitation of the implementation, not the architecture.
>

---

From: Jon Watte <[email-masked]>
Date: Wed, 01 Apr 2009 17:42:46 -0700

> To me, interop implies a full handoff of an avatar from one virtual 

Is it "virtual worlds interop" if there aren't multiple virtual worlds 
interoperating involved on an ongoing basis?
It sounds like you're describing something like "avatar interop," to me.

It may sound pedantic, but I do think it's important to put as 
unambiguous labels on what we discuss as possible, so that we don't end 
up making different assumptions without realizing it, and ending up in 
confusion and discord.

Sincerely,

jw

---

From: Charles Krinke <[email-masked]>
Date: Wed, 1 Apr 2009 16:48:51 -0800

Yes, Infinity, I was merely using that as an example.

I have the greatest of respect for both you and JHurliman and hope that
"whatever" evolves is something both of you can support. I am trying to pick
my words very carefully as I dont want to paint you or JHurliman into any
corner.

But, in any case, as long as interop between virtual worlds is symmetrical,
then I can support the notions are they are evolving. Symmetrical in this
case meaning that there is *not* an overwhelming, global, metaversal server
somewhere that *everyone* needs an account on in order to accomplish
interop.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Wed, Apr 1, 2009 at 4:30 PM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

> Charles... i _think_ we're in radical agreement. Some might read that first
> sentence as meaning, "you're not fully interoperable unless you can teleport
> from second life to wonderland to world of warcraft to every other virtual
> world in existence." But the second sentence seems to imply you're really
> just talking about "second life-like" systems. If you mean the former...
> ouch... that's going to be difficult (though i'm sure JW would disagree.) If
> the latter, then yes, you're right... we're not fully interoperable (in the
> OGP sense) until you can teleport from a linden controlled server to a
> OSgrid controlled? federated? server, and then turn around and go back the
> other way.
>
> To me, interop implies a full handoff of an avatar from one virtual world
> to another.
>
> So, from the MMOX viewpoint, we could perhaps get there from here if we
> were to consider the fact that each side of this teleport needs to be
> treated in an equal and sovereign manner.
>
>> that has a "i will trust all worlds" settings. i think this is a limitation
>> of the implementation, not the architecture.
>>

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Lawson English <[email-masked]>
Date: Wed, 01 Apr 2009 18:03:50 -0700

Charles Krinke wrote:
> I have the greatest of respect for both you and JHurliman and hope 
> that "whatever" evolves is something both of you can support. I am 
> trying to pick my words very carefully as I dont want to paint you or 
> JHurliman into any corner.
>
> But, in any case, as long as interop between virtual worlds is 
> symmetrical, then I can support the notions are they are evolving. 
> Symmetrical in this case meaning that there is *not* an overwhelming, 
> global, metaversal server somewhere that *everyone* needs an account 
> on in order to accomplish interop.
>
> Charles Krinke
> OpenSim Core Developer
> OSGrid Director
>
>
> On Wed, Apr 1, 2009 at 4:30 PM, Meadhbh Hamrick (Infinity) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Charles... i _think_ we're in radical agreement. Some might read
>     that first sentence as meaning, "you're not fully interoperable
>     unless you can teleport from second life to wonderland to world of
>     warcraft to every other virtual world in existence." But the
>     second sentence seems to imply you're really just talking about
>     "second life-like" systems. If you mean the former... ouch...
>     that's going to be difficult (though i'm sure JW would disagree.)
>     If the latter, then yes, you're right... we're not fully
>     interoperable (in the OGP sense) until you can teleport from a
>     linden controlled server to a OSgrid controlled? federated?
>     server, and then turn around and go back the other way.
>
>>     To me, interop implies a full handoff of an avatar from one
>>     virtual world to another.
>>
>>     I can appreciate OGP offering one half of this in its current
>>     form in a teleport from a SecondLife type grid to an OpenSim type
>>     grid. But, we also need to consider how a citizen of an OpenSim
>>     grid can teleport to a SecondLife grid as well.
>>
>>     In the case of OpenSim grids, we have a UserServer as opposed to
>>     an AgentDomain, but they offer a similar set of services.
>>
>>     So, from the MMOX viewpoint, we could perhaps get there from here
>>     if we were to consider the fact that each side of this teleport
>>     needs to be treated in an equal and sovereign manner.
>>
>>     crossing rules for exit and its own customs rules for entry and
>>     each is sovereign in its own right. That is, there is no
>>     overwhelming AgentDomain that controls all teleports between all
>>     grids, but rather an AgentDomain is a paradigm for one particular
>>     grid, or in the SecondLife case, for a few SecondLife grids all

I had always assumed that agent domains were trusted to a certain extent 
by all grids/regions that allow their avies  in but the converse was not 
true.

This would be analogous to the border guard granting a temp/tourist visa 
to the "non-authorized by recognized Agent Domain avies," while 
providing a more formal passport to those that are.

Euro-pass vs work-visa vs passport vs citizenship papers or somesuch.

Lawson

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Wed, 1 Apr 2009 18:50:30 -0700

Okay... if we want to get pedantic, then let's get pedantic.

	* 47 CFR 51.3 defines interoperability as "the ability of two or more  
facilities, or networks, to be connected, to exchange information, and  
to use the information that has been exchanged."

	* 17 USCS § 1201 describes interoperability as "means the ability of  
computer programs to exchange information, and of such programs  
mutually to use the information which has been exchanged."

	* 44 USCS § 3601 describes interoperability as "the ability of  
different operating and software systems, applications, and services  
to communicate and exchange data in an accurate, effective, and  
consistent manner."

	* The IEEE has used "the ability of two or more systems or components  
to exchange information and to use the information that has been  
exchanged." as the definition of the term.

I would suggest that we all might be using the term incorrectly as the  
definitions above imply an exchange of information; that is,  
information flows between two facilities, networks, computer programs,  
operating systems, applications, services, systems or components.

Perhaps it is more appropriate to say:

	* "Second Life (as a service) has demonstrated interoperability with  
an instance of OpenSim using a version of the OGP protocol." or
	* "sim3078.aditi.lindenlab.com has demonstrated interoperability with  
ec2-XXX-XXX-XXX-XXX.compute-1.amazonaws.com using a version of the OGP  
protocol." or
	* "Second Life server version 1.22 (as a software system) has  
demonstrated interoperability with a version of OpenSim."

But I would defend our previous usage of the term to describe OGP as  
an "interoperability protocol" because, in fact, there are software  
systems (Second Life and OpenSim) which use it to exchange information  
which is used by either system.

I believe the term you're looking for, given your usage is  
"universality." And no, OGP does not provide universality. OGP does  
not allow WoW to talk with Star Wars Galaxies or There.Com or a  
Forterra simulation. It also doesn't solve world hunger or global  
warming. But then again, OGP was not intended to provide that kind of  
universality (or to solve world hunger.) And I would suggest that  
neither LESS nor DIS nor HLA were designed for universality either. I  
further believe that universality is not a feature of a protocol, but  
of markets, products and possibly networks.

-cheers
-meadhbh

On Apr 1, 2009, at 5:42 PM, Jon Watte wrote:

> Is it "virtual worlds interop" if there aren't multiple virtual  
> worlds interoperating involved on an ongoing basis?
> unambiguous labels on what we discuss as possible, so that we don't  
> end up making different assumptions without realizing it, and ending  
> up in confusion and discord.
>
> Sincerely,
>
> jw
>

---

From: Jon Watte <[email-masked]>
Date: Wed, 01 Apr 2009 19:56:28 -0700

Meadhbh Hamrick (Infinity) wrote:
> "universality." And no, OGP does not provide universality. OGP 

>> up in confusion and discord.

I'm sorry: I think you misunderstood what I was saying and took it the 
wrong way. The word "interop" is clearly correct, and I am not arguing 
against that. My argument is against labeling anything and everything as 
"virtual world interop." As we've seen, it's a term that is so broad as 
to be almost meaningless. I'm merely arguing for specificity.

The proposal is to be more detailed about what kind of interop we're 
talking about in any particular case. For example, there might be VoIP 
interop, or avatar interop, or authentication interop, or simulation 
interop, or service brokerage interop, or online status interop, or text 
chat interop. Those are all forms of interop necessary to accomplish 
"full virtual world interop." The confusion arises when someone talks 
about "virtual worlds interop" but is actually only discussing one 
piece. In my opinion, it would be more accurate, and help everybody, to 
clearly specify the piece you're talking about.

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Wed, 1 Apr 2009 20:01:11 -0700

so maybe we might say "virtual world avatar interop" or "virtual world  
event stream interop"?

but not say "virtual world interop" 'cause it's too vague?

On Apr 1, 2009, at 7:56 PM, Jon Watte wrote:

>>> unambiguous labels on what we discuss as possible, so that we  
>>> don't end up making different assumptions without realizing it,  
>>> and ending up in confusion and discord.
>
> I'm sorry: I think you misunderstood what I was saying and took it  
> the wrong way. The word "interop" is clearly correct, and I am not  
> arguing against that. My argument is against labeling anything and  
> everything as "virtual world interop." As we've seen, it's a term  
> that is so broad as to be almost meaningless. I'm merely arguing for  
> specificity.
>
> talking about in any particular case. For example, there might be  
> VoIP interop, or avatar interop, or authentication interop, or  
> simulation interop, or service brokerage interop, or online status  
> interop, or text chat interop. Those are all forms of interop  
> necessary to accomplish "full virtual world interop." The confusion  
> arises when someone talks about "virtual worlds interop" but is  
> actually only discussing one piece. In my opinion, it would be more  
> accurate, and help everybody, to clearly specify the piece you're  
> talking about.
>
> Sincerely,
>
> jw
>

---

From: Charles Krinke <[email-masked]>
Date: Thu, 2 Apr 2009 03:28:27 +0000

At this point, I would really be interested in hearing what JHurliman has to
say and suggest. Getting JHurliman to where he feels more comfortable with
the direction of the interop discussion is something important to me and
others.
-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Morgaine <[email-masked]>
Date: Thu, 2 Apr 2009 06:26:36 +0100

As I see it, a good part of the reason for the tangle surrounding the word
"interop" seems to be that people are focusing on the *mechanisms* that they
believe it requires, and these mechanisms are often architecture-dependent
so there isn't much immediate agreement.

In contrast, if we look at *user expectations* then the situation becomes
much simpler and clearer.

Users already know what a single virtual world looks like, and they also
know what it means to move or teleport between different regions of that
single world.  So, when they hear that other worlds are out there and that
we are offering *interop* between old worlds and new, they know exactly what
to expect:  *the same as before, but extended to regions in the new worlds
as well*.

For our purposes in this protocol group, the above user expectation is
actually very easy to turn into a definition that has useful structural
properties, which I've stated before.  Full VW interop is, in essence:

*To create a mashup for the user, in which the user's avatar and objects
from one world are perceived to be in a new world, and are also perceived by
others in that new world.
*

Despite this interop goal being expressed in pure user terms, it's
remarkably structural too:  it tells us immediately that for successful
interop, we need to gather together data from many different sources (either
worlds or services employed by those worlds), otherwise that mashup will not
occur and user expectations will be dashed.

I think it's a good sign that everyone who has commented on this user view
of interop before has agreed with it --- it probably means that we actually
have the same goal in mind, but just seem to be approaching it from
different angles.

Lisa also provided a persona-oriented use
case<http://www.ietf.org/mail-archive/web/mmox/current/msg01275.html>that
underlined the social dimension of interop, and added one important
element to the picture:  *continuity* in social elements, such as names,
friends, places, and easy travel or access, as well as visual (or at least
perceptual) continuity.  The more seamless we can make the user experience
of interop, the higher will be our degree of success.

I think we actually know what *interop* is, from a user perspective.  If we
start from there, it might help us to converge on a common technical view as
well.

Morgaine.

---

From: Jason Giglio <[email-masked]>
Date: Thu, 02 Apr 2009 03:00:27 -0400

> +1. what's your suggestion?

My suggestion is that it's not appropriate to talk about client
identity, trust, or authentication as a service to be provided in a
centralized manner.

The rest of the Internet gets along just fine without it.  Sure I can
get a CA to sign something that says I am who I am, but no one much
cares; the rest of the net has routed around the problem of client
identification. I'm not sure why we would need to tackle something so
fundamentally difficult here, when it's not really necessary.

-Jason

---

From: Rob Lanphier <[email-masked]>
Date: Thu, 02 Apr 2009 00:40:08 -0700

On 04/02/2009 12:00 AM, Jason Giglio wrote
> fundamentally difficult here, when it's not really necessary.

The cost of building an online identity in a virtual world is much
higher than the cost of building an online identity for purposes of most
web applications.

That said, there's no reason to believe that this group can't come up
with modes of operation for OGP such that a web-like identity-free case
is possible.

Rob

---

From: Morgaine <[email-masked]>
Date: Thu, 2 Apr 2009 11:33:03 +0100

On Thu, Apr 2, 2009 at 12:53 AM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

>
> John quoted<http://www.ietf.org/mail-archive/web/mmox/current/msg01211.html>>>> There will be millions of worlds in an Internet-scale metaverse, which
>>> makes the concept of interop through trust agreements far too narrow.  Trust
>>> loses its meaning entirely when scaled to millions, becoming mere paperwork
>>> or "security theater".
>>>
>>
Jason's suggestion<http://www.ietf.org/mail-archive/web/mmox/current/msg01305.html>was
accurate I believe, namely that centralized control of identity, trust
and authentication is neither appropriate nor accepted on an Internet
scale.  To that I'll add another suggestion, based on my experience in the
defense industry.

Trust agreements *between* organizations are only useful in the context of
transactions *at the level of* organizations, but are very inappropriate for
dealing with transactions at other (lower or higher) levels:  a single
credential cannot carry an appropriate semantic for dealing with multiple
levels of trust, secrecy, or security --- that's why single level
credentials are never used in defense organizations.

In our area, VWs perform transactions over a huge range of objects that have
highly diverse sensitivities, ranging from no sensitivity at all up to
(presumably) the highest levels of sensitivity demanded by business, finance
and government.  To try to encapsulate this in a single trust agreement
between interoperating worlds just doesn't make sense.

Different levels of trust actually cost different amounts of money to
implement if they are to be meaningful, so you cannot have a blanket trust
agreement that operates at all sensitivity levels unless you place a
prohibitively high bar on entry.  And if you don't mandate this high bar,
then the whole agreement becomes "best effort only" and so you end up with
the "security theater <http://en.wikipedia.org/wiki/Security_theater>" that
I mentioned in John's quote in the context of Internet-size scaling.

In view of the above two problems with trust agreements and also Jason's
point, I believe that trust agreements don't actually have a useful role to
play in VWs at all.  Instead, I suggest that the machinery that was going to
underpin trust agreements be used only for endpoint identification in the
usual way, with no trust implied.  It then becomes a *local policy
decision*which data to release to the peer, and that policy decision
will need to be
made on the basis of concrete realities rather than based on the wishful
thinking of a trust agreement.  While we are not concerned with local policy
decisions in MMOX, I think it's fair to suggest that most such decisions
should err on the side of caution.

The above picture would not be complete without offering a solution for
those who *do* require sensitive data to be made available to parties in
remote worlds, as will be common in business.  Because trust between worlds
is largely meaningless yet secure object transfer is still needed, I suggest
that one of the many well-designed cryptographic technologies be used to
deliver individually encrypted items to their intended parties directly.
Whether or not a MMOX protocol should assist in the transport of such opaque
items between worlds is an interesting topic for discussion.  This is
probably appropriate material for the same design team that will deal with
VW privacy and end-to-end encrypted communications to consider.

(PS. For the benefit of those who do not work in this area, please note that
what's become known as "DRM" is not correct usage of cryptography and should
not be used where real security is required.)

Morgaine.

---

From: Jon Watte <[email-masked]>
Date: Thu, 02 Apr 2009 09:19:59 -0700

> but not say "virtual world interop" 'cause it's too vague?

That's the gist of what I'm saying!

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Thu, 02 Apr 2009 09:38:16 -0700

> identity, trust, or authentication as a service to be provided in a

Let's look at the text-based, non-interactive web:

OpenID is a service, and it is "centralized" in the sense that an OpenID 
provider is a central service provider.
E-mail is a service, and it is "centralized" in the sense that an e-mail 
address is centralized to that provider.
When I sign up for a web site, typically I enter an e-mail address and a 
password, and I then have to click on a link sent to that e-mail 
address. This verifies that I am at least marginally reachable through 
that e-mail address. This establishes identity, albeit tenuous.
However, if I want to show at amazon.com, I have to provide another 
identity: my credit card number. This is an identity with significantly 
higher bar to accreditation.
Some sites, like those where there is legal ramifications to providing 
service to under-age visitors, actually use the credit card identity 
even for site access, because they have higher requirements on the 
identity they interact with.

What, if anything, in this model do you think would be different for 
virtual worlds, when it is real-time 3D based?

Sincerely,

jw

> ------------------------------------------------------------------------
>

---

From: Christian Scholz <[email-masked]>
Date: Thu, 02 Apr 2009 22:05:17 +0200

>> but not say "virtual world interop" 'cause it's too vague?

I would say that in fact we have quite a few areas where 
interoperability is possible if we start to cut the problem space into 
smaller chunks.

Here are some:

- Identification (who is this agent?)
- Profiles (information about the logged in user)
- friends/contacts (probably most worlds have this)
- group memberships (not every world might have this)
- (instant) messaging
- presence
- Assets such as textures/photos/sounds etc.

Now if you take those than we can discuss what interoperability means 
for each of them. In fact there are many formats/protocols already 
available:

- OpenID, InformationCards etc. for identification
- OpenSocial RESTful API or PortableContacts (the same protocol) for 
profile and contacts (in a limited fashion at least)
- XMPP or IRC (and other proprietary formats) for instant messaging. 
Might also include presence although maybe this needs to be extended.
- SMTP for not so instant messaging

So in fact for some areas interoperability would already be possible. It 
would at least allow a user with an account on service A to login to 
service B and maybe be able to match contacts, chat with people on other 
services and so on.

And basically what is describes then is a simple social network. If you 
add 3D services on top then you have your virtual world and this is 
where it becomes complicated.

If you take the above elements you also have an Agent Domain. So in fact 
it's nothing else than the social networking part where the Region 
domain would be those additional 3D services.

Of course the AD also does a bit more, like trust brokering.

The thing is though: Why group all this together into one big chunk? It 
will be more likely in the future that you will have data stored on 
several services: your profile might be on MySpace (or one of many), you 
  chat via IRC on freenode, you have photos on flickr which you might 
want to use as textures. So IMHO it makes sense to allow this to be 
split up into several services. The only question is how to bind this 
together.

I already mentioned XRDS here once, which is basically a list of type 
URI/service URI pairs. A user could describe via XRDS where profile, 
friends list etc. is stored and the client or the simulator could then 
go and fetch it. No big Agent Domain would be needed and you also could 
support various services where client and simulator could choose those 
they understand.

The only thing of course where it gets tricky is authorization 
brokering. You don't want your data public (at least not all of it). 
OAuth might give you some means of authorizing third parties to give out 
  data on your behalf. But the problem is of course that you'd need to 
authorize each service individually which is not user friendly.

So here is where some thinking is actually needed: How can an 
authorization broker be implemented. I would prefer it be OAuth based 
because libraries and understanding of OAuth is there (and of course 
it's also at the IETF ;-). And maybe we come back here to the original 
scalability problem of the AgentDomain but at least it would be only one 
problem for the AD to solve (although the name might be not correct 
anymore then because all the stuff related to an agent would be spread 
across different services).

As for naming though: it would then be

- profile interop
- contactlist interop
- group interop
- chat interop

etc.

The question to the group would now be: Would it be worthwhile to try to 
use all those existing specifications and just build a way around them 
to bundle those things? IMHO the implementation wouldn't be so hard to 
do. It would be an area though where it's very mixed with where the 
web/social networks are going so it would make sense to do this together 
with web folks.

-- Christian

-- 
COM.lounge GmbH
http://comlounge.net
Hanbrucher Strasse 33, 52064 Aachen
Amtsgericht Aachen HRB 15170
Geschäftsführer: Dr. Ben Scheffler, Christian Scholz

email: [email-masked]
fon: +49-241-4007300
fax: +49-241-97900850

personal email: [email-masked]
personal blog: http://mrtopf.de/blog
personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net

---

From: "Hurliman, John" <[email-masked]>
Date: Thu, 2 Apr 2009 15:02:54 -0600

Thank you Christian, I think this is the right approach. Using partially defined blanket terms such as "Agent Domain" or "Region Domain" conjure up different ideas in everyone's head and also tend to imply an unnecessary aggregation of services. If we can clearly define the actual work items such as identity, authentication, authorization, asset storage, asset representation (content types and metadata), communication and contact lists, etc. we would likely find much more common ground between parties and could start partitioning the work into manageable sized chunks.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Christian Scholz
> Sent: Thursday, April 02, 2009 1:05 PM
> To: Jon Watte
> Cc: [email-masked]
> Subject: Re: [mmox] OGP scalability concerns
> 
> Jon Watte schrieb:
>>> so maybe we might say "virtual world avatar interop" or "virtual
>>> world event stream interop"?
>>> 
> So in fact for some areas interoperability would already be possible.
> It would at least allow a user with an account on service A to login
> to service B and maybe be able to match contacts, chat with people on
> other services and so on.
> 
> And basically what is describes then is a simple social network. If
> you add 3D services on top then you have your virtual world and this
> is where it becomes complicated.
> 
> If you take the above elements you also have an Agent Domain. So in
> fact it's nothing else than the social networking part where the
> Region domain would be those additional 3D services.
> 
> The thing is though: Why group all this together into one big chunk?
> It will be more likely in the future that you will have data stored on
> go and fetch it. No big Agent Domain would be needed and you also
> could support various services where client and simulator could choose
> those they understand.
> 
> scalability problem of the AgentDomain but at least it would be only
> one problem for the AD to solve (although the name might be not
> correct anymore then because all the stuff related to an agent would
> be spread across different services).
> 
> 
> The question to the group would now be: Would it be worthwhile to try
> to use all those existing specifications and just build a way around
> them to bundle those things? IMHO the implementation wouldn't be so
> hard to do. It would be an area though where it's very mixed with
> where the web/social networks are going so it would make sense to do
> this together with web folks.
> 
> 
> 
> 
> 
> -- Christian
> 
> 
> 
> 
> --
> COM.lounge GmbH
> http://comlounge.net
> personal email: [email-masked] personal blog: http://mrtopf.de/blog

---

From: Christian Scholz <[email-masked]>
Date: Thu, 02 Apr 2009 23:27:41 +0200

Hurliman, John schrieb:
> Thank you Christian, I think this is the right approach. Using
> partially defined blanket terms such as "Agent Domain" or "Region
> Domain" conjure up different ideas in everyone's head and also tend
> to imply an unnecessary aggregation of services. If we can clearly
> define the actual work items such as identity, authentication,
> authorization, asset storage, asset representation (content types and
> metadata), communication and contact lists, etc. we would likely find
> much more common ground between parties and could start partitioning
> the work into manageable sized chunks.

Thanks!

In fact we could actually start with thinking about 
identification/authentication right away and maybe taking OpenID and see 
how it might fit in a not web-based environment (read: VW client).

Another option would be to join forces with the OAuth group at IETF and 
check on how we could add identity to OAuth (there is discussion about 
that already). Eventually this might be an easier choice and you could 
do authorization in one step, at least for some centralized services.

We could start by fleshing out some more detailed use cases to see what 
is needed, what can be provided by existing standards and what might be 
missing and needs some inventing.

I am just too tired to start right away ;-)

-- Christian

> 
> John
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Christian Scholz Sent:
>> Thursday, April 02, 2009 1:05 PM To: Jon Watte Cc: [email-masked] 
>>>> so maybe we might say "virtual world avatar interop" or
>>>> "virtual world event stream interop"?
>>>> 
>> interoperability is possible if we start to cut the problem space
>> into smaller chunks.
>> 
>> Here are some:
>> 
>> - Identification (who is this agent?) - Profiles (information about
>> the logged in user) - friends/contacts (probably most worlds have
>> this) - group memberships (not every world might have this) -
>> (instant) messaging - presence - Assets such as
>> textures/photos/sounds etc.
>> 
>> Now if you take those than we can discuss what interoperability
>> means for each of them. In fact there are many formats/protocols
>> already available:
>> 
>> - OpenID, InformationCards etc. for identification - OpenSocial
>> RESTful API or PortableContacts (the same protocol) for profile and
>> contacts (in a limited fashion at least) - XMPP or IRC (and other
>> proprietary formats) for instant messaging. Might also include
>> presence although maybe this needs to be extended. - SMTP for not
>> so instant messaging
>> 
>> So in fact for some areas interoperability would already be
>> possible. It would at least allow a user with an account on service
>> A to login to service B and maybe be able to match contacts, chat
>> with people on other services and so on.
>> 
>>  you add 3D services on top then you have your virtual world and
>> this is where it becomes complicated.
>> 
>> The thing is though: Why group all this together into one big
>> chunk? It will be more likely in the future that you will have data
>> stored on several services: your profile might be on MySpace (or
>> one of many), you chat via IRC on freenode, you have photos on
>> flickr which you might want to use as textures. So IMHO it makes
>> sense to allow this to be split up into several services. The only
>> question is how to bind this together.
>> 
>> I already mentioned XRDS here once, which is basically a list of
>> type URI/service URI pairs. A user could describe via XRDS where
>> profile, friends list etc. is stored and the client or the
>> simulator could then go and fetch it. No big Agent Domain would be
>> needed and you also could support various services where client and
>> simulator could choose those they understand.
>> 
>> brokering. You don't want your data public (at least not all of
>> it). OAuth might give you some means of authorizing third parties
>> to give out data on your behalf. But the problem is of course that
>> you'd need to authorize each service individually which is not user
>> friendly.
>> 
>> authorization broker be implemented. I would prefer it be OAuth
>> based because libraries and understanding of OAuth is there (and of
>> course it's also at the IETF ;-). And maybe we come back here to
>> the original scalability problem of the AgentDomain but at least it
>> would be only one problem for the AD to solve (although the name
>> might be not correct anymore then because all the stuff related to
>> an agent would be spread across different services).
>> 
>> 
>> - profile interop - contactlist interop - group interop - chat
>> interop
>> 
>> etc.
>> 
>> The question to the group would now be: Would it be worthwhile to
>> try to use all those existing specifications and just build a way
>> around them to bundle those things? IMHO the implementation
>> wouldn't be so hard to do. It would be an area though where it's
>> very mixed with where the web/social networks are going so it would
>> make sense to do this together with web folks.
>> 
>> 
>> 
>> 
>> 
>> -- Christian
>> 
>> 
>> 
>> 
>> -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33,
>> 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben
>> Scheffler, Christian Scholz
>> 
>> email: [email-masked] fon: +49-241-4007300 fax:
>> +49-241-97900850
>> 
>> personal email: [email-masked] personal blog:
>> http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de,
>>  http://datawithoutborders.net
>> 
>> _______________________________________________ mmox mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/mmox

---

From: Jon Watte <[email-masked]>
Date: Thu, 02 Apr 2009 14:44:58 -0700

Christian Scholz wrote:
> Another option would be to join forces with the OAuth group at IETF 
> and check on how we could add identity to OAuth (there is discussion 
> about that already). Eventually this might be an easier choice and you 
> could do authorization in one step, at least for some centralized 
> services.

The first question is: does the OAuth "callback" URL work in a VW sense? 
At a minimum, this means that a VW needs to have a publicly available 
*incoming* URL for receiving authentication tokens. For a VW behind a 
firewall, that's not necessarily true. (Then again, OAuth doesn't work 
for an intranet web site behind a firewall, either)

Sincerely,

jw

---

From: Christian Scholz <[email-masked]>
Date: Thu, 02 Apr 2009 23:53:46 +0200

> for an intranet web site behind a firewall, either)

The redirect setup is only one example of obtaining the OAuth token. You 
can do it whatever way you want to (the new version of the spec also 
makes that clearer as it starts with just the way you actually do 
authorized requests and only explains in the second part the redirect 
mechanism).

But if you look at e.g. iMovie and how it uploads movies to YouTube you 
have an example of how a desktop app can do it (although it's not using 
OAuth I think but probably Google AuthSub but it's basically the same).

Basically instead of having a callback URL the client will simply wait 
until the user has finished authorization in the web browser. The server 
then might tell him to go back to the client and click "Continue". After 
that the client will contact the server again and will try to exchange 
the request token for an access token which only will work if the user 
authorized it.

I am not sure though I understand the question. You might also be 
talking about the server being behind a firewall and not reachable by 
the client. But then I guess you need some ports open anyway for the 
client to be able to connect any way.

-- Christian

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 2 Apr 2009 15:22:16 -0700

i think the way we were initially thinking about it is that "the agent  
domain" is the group of systems / interfaces that house information  
unique to or focused on agent based services while the "region domain"  
was the hypothetical place where virtual space based services lived.  
we proposed that division because services like identity, profiles,  
groups, presence, affiliation, group or proximal chat, item scheduling  
(i.e. - rezzing), avatar movement and instantiation, etc. all  
generally scale along the agent or virtual land / space axis. (they  
DEFINITELY do in second lifelike systems, and i would argue they also  
do in most other architectures.) in our nomenclature, we would  
probably refer to IM, presence, etc. as being "services" of the domain  
which most constrains their scaling behavior.

so for example, if you built a group IM system that requires you to  
authenticate yourself to whomever manages your virtual identity, the  
servers on the back end would encounter scaling problems as the number  
of groups (and presumably also the number of agents) grew. that's why  
_we_ call group IM an agent domain service.

we also use the term "domain" in it's more traditional sense to imply  
a bounds of authority. which is to say, we assume that all hosts and  
services inside a domain are administered by the same entity. that  
being said, there's no reason you can't have sub-domains, and there's  
no reason that two services associated with "the" agent domain can't  
be split across two administrative domains (like maybe yahoo or AOL  
get in the business of moving virtual world IM messages but don't want  
to deploy a world themselves.) it would require some coordination of  
identity management issues, but i'm sure they're tractable.

On Apr 2, 2009, at 2:02 PM, Hurliman, John wrote:

> authorization, asset storage, asset representation (content types  
> and metadata), communication and contact lists, etc. we would likely  
> find much more common ground between parties and could start  
> partitioning the work into manageable sized chunks.
>
> John
>
>> into

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 2 Apr 2009 15:50:49 -0700

yup. for what it's worth, i had several good chats with mark atwood at  
the ietf meeting. he's coming down to the bay area for the mysql  
conference, i hope to buy him a beer some evening and run a few  
proposals past him wrt OAuth and it's use in OGP.

and. ack. i should probably have mentioned this earlier. i got a lot  
of good feedback about the drafts we published, and one of the things  
that's going into the next rev of the auth draft is how to deal with  
transport authentication ( like when your transport manages  
authentication for you like client side certs and HTTP digest  
(*shudder*) ). eventually OpenID should go into a similar section, but  
we feel there are still a few open issues with it's use. declaring the  
solution to being "we just use XRI" and declaring victory seems a  
little hasty, but it seems like there's enough interest to warrant  
it's inclusion in any future charter / IDs / etc.

i haven't heard anyone say they have serious problems with OpenID in  
general. i mean... if someone was implying that OpenID kills puppies,  
i missed it. that being said, XRI / XRDS and OpenID are not in  
universal use, so it's unlikely a statement like "OGP will only ever  
use OpenID" will ever pass the humm test. but the statement "OpenID  
and XRDS should forever be banished from OGP" will also never pass the  
humm test.

which is to say... if anyone's willing to do the work to figure out  
how to wedge OpenID into OGP, i'm all for it. to be clear, in this  
context, the word "work" means:

1. you work with other list members requirements.
2. you produce a document describing how OpenID or XRDS can be used in  
conjunction with the existing spec (though the existing specs are cast  
in jello, not in stone, so there's some room to modify them if we  
absolutely have to.)
3. producing code to demonstrate it's use.. *cough*PyOGP*cough*

so.. to recap.. we (LL) have made no statement about OpenID one way or  
another. so... don't hold your breath waiting for us to deploy  
services that consume OpenID id services. still, it's gaining in  
popularity, so we're not going to ignore it, we want to make sure it's  
properly applied to the problem at hand. ditto with OAuth. ditto with  
SAML 1.1 / Shib 1.3.

-cheers
-meadhbh

On Apr 2, 2009, at 2:53 PM, Christian Scholz wrote:

> Jon Watte schrieb:
>> Christian Scholz wrote:
>>> Another option would be to join forces with the OAuth group at  
>>> IETF and check on how we could add identity to OAuth (there is  
>>> discussion about that already). Eventually this might be an easier  
>>> choice and you could do authorization in one step, at least for  
>>> some centralized services.
>> The first question is: does the OAuth "callback" URL work in a VW  
>> sense? At a minimum, this means that a VW needs to have a publicly  
>> available *incoming* URL for receiving authentication tokens. For a  
>> VW behind a firewall, that's not necessarily true. (Then again,  
>> OAuth doesn't work for an intranet web site behind a firewall,  
>> either)
>
> The redirect setup is only one example of obtaining the OAuth token.  
> You can do it whatever way you want to (the new version of the spec  
> also makes that clearer as it starts with just the way you actually  
> do authorized requests and only explains in the second part the  
> redirect mechanism).
>
> But if you look at e.g. iMovie and how it uploads movies to YouTube  
> you have an example of how a desktop app can do it (although it's  
> not using OAuth I think but probably Google AuthSub but it's  
> basically the same).
>
> Basically instead of having a callback URL the client will simply  
> wait until the user has finished authorization in the web browser.  
> The server then might tell him to go back to the client and click  
> "Continue". After that the client will contact the server again and  
> will try to exchange the request token for an access token which  
> only will work if the user authorized it.
>
> talking about the server being behind a firewall and not reachable  
> by the client. But then I guess you need some ports open anyway for  
> the client to be able to connect any way.
>
> -- Christian
>
>
>
> -- 
> COM.lounge GmbH
> http://comlounge.net

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 2 Apr 2009 15:52:50 -0700

krunk. i am totally having email problems. apologies if this is a  
duplicate.

-cheers
-meadhbh

---

From: Jon Watte <[email-masked]>
Date: Thu, 02 Apr 2009 16:12:08 -0700

Christian Scholz wrote:
> also makes that clearer as it starts with just the way you actually do 

When I register as a service provider for an OAuth service, I have to 
register a callback URL. That seems pretty hard-coded into the actual 
implementation to me. That service provider won't work with a service 
that doesn't have a user-visible callbacl URL.

> you have an example of how a desktop app can do it (although it's not 
> using OAuth I think but probably Google AuthSub but it's basically the 
> same).
>

The problem is not the desktop app not being reachable; the problem is 
the service requesting authentication not being reachable from the 
authentication provider.

> client to be able to connect any way.

The client can get to the service requesting authentication. The service 
can get to the authentication provider. The client can get to the 
authentication provider. The authentication provider can /not/ get to 
the service. Thus, any callback scheme between the services may fail. 
The current implementation of OAuth in the services I've seen uses this 
callback with a registered URL, so this is not something you can change 
by only changing the client, or only changing the requesting service AFAICT.

Sincerely,

jw

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 2 Apr 2009 16:13:24 -0700

hmm... there was a lot of discussion about this a year and some ago.  
("this" being how to wedge OpenID into SL)  i think it fell off  
everyone's radar 'cause there were larger fish to fry. i was looking  
in the goupies chat logs and logs from zero's office hours and sldev,  
but for the life of me i can't find the discussions i was thinking  
about. anyone else remember hashing over OpenID in the past? it might  
be a good place to start.

On Apr 2, 2009, at 2:27 PM, Christian Scholz wrote:

> In fact we could actually start with thinking about identification/ 
> authentication right away and maybe taking OpenID and see how it  
> might fit in a not web-based environment (read: VW client).
>
> about that already). Eventually this might be an easier choice and  
> you could do authorization in one step, at least for some  
> centralized services.
>
> We could start by fleshing out some more detailed use cases to see  
> what is needed, what can be provided by existing standards and what  
> might be missing and needs some inventing.
>
>>> _______________________________________________ mmox mailing list [email-masked]

---

From: Charles Krinke <[email-masked]>
Date: Thu, 2 Apr 2009 15:55:34 -0800

I believe that thanks to the efforts of JHurliman and others, we have OpenID
in the OpenSim server so we are ready to go.

 As long as JHurliman is hesitant on OGP, so am I personally, but we have
MXP, HyperGrid interop running now and have been able to accept AgentDomain
connections over OGP from the SecondLife BetaGrid.

On the AgentDomain bit, as long as we can perceive a way that other grids
can establish a connection *back* to a SecondLife grid with their own
implementation of AgentDomain, UGAIM or OGS (OpenGridServices), I personally
dont have a lot of objection other then that voiced by my respected peers.

So, lets move forward.

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: "Hurliman, John" <[email-masked]>
Date: Thu, 2 Apr 2009 18:02:24 -0600

> identity management issues, but i'm sure they're tractable.

I understand this. If you are Linden Lab and you are already in the business of running lots of independent services (content hosting, identity storage and authorization, instant messaging, inventory servers, simulators, etc) then it makes sense to lump every service you want to provide under one trust domain. Simulation can be a different domain so third party simulators like OpenSim can run under a separate trust domain and optionally connect to the aggregate Linden Lab service cloud. Tada! You have OGP. It's a great business model. Unless you are any company *except* Linden Lab and you want to provide a service such as content hosting without becoming a full virtual world service provider.

Using the current evolution of the web as historical evidence and assuming that specialized service providers will be the norm, lumping together instant messaging and content hosting under the same umbrella doesn't make any sense. This is why I'm in favor of starting from the ground up and defining each use case and service endpoint, rather than trying to figure out clever ways of shoehorning the "right" approach into Linden Lab's OGP.

John

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 2 Apr 2009 17:03:24 -0700

okay... if by "centralized manner" you're talking about something like  
the global PKI that PEM mandated then yes, let's not talk about that.

however. i don't think we were ever talking about that.

to date, the proposed use of X.509 has been to identify agent domains  
to region domains and region domains to each other. i don't think  
we're proposing the use of client certs for client applications to  
authenticate themselves to agent domains. or rather... no one's  
talking about REQUIRING it. as an option, it's perfectly fine, though  
a touch difficult to manage.

trust DOES lose it's meaning when you dilute your CP and CPS to enable  
universal enrollment. and don't get me started about the weak  
semantics of key usage in virtually every implementation.

however... remember that X.509 / PKIX are used to transport assertions  
about previously established trust relationships. it is possible for a  
relying party to map different cert chain trust points to different  
internal policies.

for example, one could have a "high security" CA with a CPS that  
requires execution of a legally binding agreement and the  
establishment of a $50,000 bond. then there could be a "low security"  
CA that only required an email account and a credit card number. when  
protocol from a peer identified with a cert issued off the high  
security CA, the relying party (let's assume it's an asset server  
trying to decide whether a simulator is trusted.) the relying party  
might then decide... "okay.. it's the high security CA.. i know if he  
does something untrustworthy i can impound funds from the bond escrow  
account, so sure.. have some sensitive resources." but if the next  
peer is identified with a cert from the low security CA, the relying  
party might decide only to divulge full-perm assets with a creative  
commons license.

so i guess what i'm saying is, we can't ignore the issue of trust, and  
while things are difficult, it is not outside the realm of possibility  
we could, in fact, establish a trust management system that  
communicates assertions about relationships independent of their  
interpretation. (i.e. - use X.509 in the way it's supposed to be used.)

-cheers
-meadhbh

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Thu, 2 Apr 2009 17:17:54 -0700

i would argue that there _are_ in fact OpenSim operators who would  
want to connect to linden servers and consume linden services.

we use URIs as caps and mandate consumers of these caps treat them as  
opaque web addresses explicitly because we want to support the use  
case where the host that responds to a seed cap request can provide a  
URI in a different administrative domain for other services.. um..  
like.. i dunno.. like where your identity and presence is managed on a  
server distinct from the one that provides SIP/RTP voice services.

i applaud your effort to shoehorn technologies into a codebase. we'll  
be over here trying to build a coherent set of services whose use  
semantics are conformable.

-cheers
-meadhbh

On Apr 2, 2009, at 5:02 PM, Hurliman, John wrote:

> I understand this. If you are Linden Lab and you are already in the  
> business of running lots of independent services (content hosting,  
> identity storage and authorization, instant messaging, inventory  
> servers, simulators, etc) then it makes sense to lump every service  
> you want to provide under one trust domain. Simulation can be a  
> different domain so third party simulators like OpenSim can run  
> under a separate trust domain and optionally connect to the  
> aggregate Linden Lab service cloud. Tada! You have OGP. It's a great  
> business model. Unless you are any company *except* Linden Lab and  
> you want to provide a service such as content hosting without  
> becoming a full virtual world service provider.
>
> Using the current evolution of the web as historical evidence and  
> assuming that specialized service providers will be the norm,  
> lumping together instant messaging and content hosting under the  
> same umbrella doesn't make any sense. This is why I'm in favor of  
> starting from the ground up and defining each use case and service  
> endpoint, rather than trying to figure out clever ways of  
> shoehorning the "right" approach into Linden Lab's OGP.
>
> John

---

From: Charles Krinke <[email-masked]>
Date: Thu, 2 Apr 2009 16:49:56 -0800

Yes, I would concur. There are OpenSim adopters that do wish and are using
OpenSim regions to connect to SecondLife using OGP and I applaud that use
case and wish to see it continue.

I have to admit that my personal bias came out a little bit. That personal
bias is that my personal heart is also attached to the OSGrid project, which
is a growing grid of regions that one day (I hope), there will exist some
proper and negotiated way to teleport from OSGrid to a SecondLife grid.
Whether or not that will happen is in the future and something yet to be
negotiated, but I wear two hats.

One of those hats is that of an OpenSim Core developer and the second hat is
that of one of the Directors of OSGrid. I try *really* hard to be fair to
all, so please pardon me if my OSGrid bias came out a little bit on the
"symmetry" question of interop.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Thu, Apr 2, 2009 at 4:17 PM, Meadhbh Hamrick (Infinity) <
[email-masked]> wrote:

> i would argue that there _are_ in fact OpenSim operators who would want to
> connect to linden servers and consume linden services.
>
> opaque web addresses explicitly because we want to support the use case
> where the host that responds to a seed cap request can provide a URI in a
> different administrative domain for other services.. um.. like.. i dunno..
> like where your identity and presence is managed on a server distinct from
> the one that provides SIP/RTP voice services.
>
> i applaud your effort to shoehorn technologies into a codebase. we'll be
> over here trying to build a coherent set of services whose use semantics are
> conformable.
>
> -cheers
> -meadhbh
>
>> business of running lots of independent services (content hosting, identity
>> storage and authorization, instant messaging, inventory servers, simulators,
>> etc) then it makes sense to lump every service you want to provide under one
>> trust domain. Simulation can be a different domain so third party simulators
>> like OpenSim can run under a separate trust domain and optionally connect to
>> the aggregate Linden Lab service cloud. Tada! You have OGP. It's a great
>> business model. Unless you are any company *except* Linden Lab and you want
>> to provide a service such as content hosting without becoming a full virtual
>> world service provider.
>>
>> Using the current evolution of the web as historical evidence and assuming
>> that specialized service providers will be the norm, lumping together
>> instant messaging and content hosting under the same umbrella doesn't make
>> any sense. This is why I'm in favor of starting from the ground up and
>> defining each use case and service endpoint, rather than trying to figure
>> out clever ways of shoehorning the "right" approach into Linden Lab's OGP.
>>
>> John

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Jon Watte <[email-masked]>
Date: Thu, 02 Apr 2009 21:40:45 -0700

> a touch difficult to manage.

I think that authentication comes in two flavors: Authenticating users, 
and authenticating entities that authenticate users. If you will, OAuth 
authenticates users, but how do you know who the OAuth provider is? That 
may be a separately established trust, that may be negotiated, or may be 
untrusted-but-traceable.

I agree. However, there may also be operators who want to consume some 
Linden services, and some other services. Thus, it makes sense in that 
context, like John claims, to un-bundle each service. If the protocol 
allows you to discover multiple services in one go, and even 
authenticate for multiple services in one go, that's probably fine (and 
maybe even desired), but there shouldn't be anything in the protocol 
that requires all the services to come in one bundle. Even if some 
providers can provide them all in a bundle, the user probably will want 
to un-bundle them in certain cases.

Sincerely,

jw

---

From: Christian Scholz <[email-masked]>
Date: Fri, 03 Apr 2009 11:11:40 +0200

Hi!

> proposals past him wrt OAuth and it's use in OGP.

I would actually like to learn more about those conversations you had at 
the meeting ;-)
And I am still looking forward to hear more about the ProtectServe stuff 
they are working on.

> and. ack. i should probably have mentioned this earlier. i got a lot of 
> good feedback about the drafts we published, and one of the things 
> solution to being "we just use XRI" and declaring victory seems a little 
> hasty, but it seems like there's enough interest to warrant it's 
> inclusion in any future charter / IDs / etc.
> 
> general. i mean... if someone was implying that OpenID kills puppies, i 
> missed it. that being said, XRI / XRDS and OpenID are not in universal 
> use, so it's unlikely a statement like "OGP will only ever use OpenID" 
> will ever pass the humm test. but the statement "OpenID and XRDS should 
> forever be banished from OGP" will also never pass the humm test.

I personally did not want to imply that OpenID should be the only thing 
to support. We always talked about some pluggable mechanism for 
authentication and I still think that's the way to go. As for a service 
catalogue it could simply list several authentication methods and the 
other side can select the best suited one.

> which is to say... if anyone's willing to do the work to figure out how 
> to wedge OpenID into OGP, i'm all for it. to be clear, in this context, 
> the word "work" means:
> 

I am certainly willing to work on use cases, requirements and discussing 
a solution but my personal priority would be on the general social 
networking case, not OGP (which might mean of course that this work 
might also be done outside this group if there is no interest in that). 
I am also not sure how to mix it with OGP. OAuth would be most likely a 
replacement for caps, wouldn't it? So maybe it would be then fitting 
into the spec.

I am with John here though and IMHO the Agent Domain really should be 
split into it's individual services which all are usable independantly 
of each other.

> another. so... don't hold your breath waiting for us to deploy services 
> that consume OpenID id services. still, it's gaining in popularity, so 
> we're not going to ignore it, we want to make sure it's properly applied 
> to the problem at hand. ditto with OAuth. ditto with SAML 1.1 / Shib 1.3.

I think we all want to have it properly applied :-) I think on this list 
we are right now also more struggling at defining "the problem at hand" ;-)

-- Christian

>>> VW behind a firewall, that's not necessarily true. (Then again, OAuth 
>>> doesn't work for an intranet web site behind a firewall, either)
>>
>> until the user has finished authorization in the web browser. The 
>> server then might tell him to go back to the client and click 
>> will try to exchange the request token for an access token which only 
>> will work if the user authorized it.
>>

---

From: Christian Scholz <[email-masked]>
Date: Fri, 03 Apr 2009 11:16:26 +0200

Meadhbh Hamrick (Infinity) schrieb:
> everyone's radar 'cause there were larger fish to fry. i was looking in 
> the goupies chat logs and logs from zero's office hours and sldev, but 
> for the life of me i can't find the discussions i was thinking about. 
> anyone else remember hashing over OpenID in the past? it might be a good 
> place to start.

I at least cannot remember a very specific discussion about it. I only 
remember you saying that it was at LL internally and there have been 
some concerns about it. Those never get published though (or I missed it).

So it would be good to know what these concerns might be.

Then again of course there are many issues with OpenID which are also 
known to the OpenID community, mainly regarding usability and phishing. 
So I would assume that these issues also apply to a use in virtual 
worlds. But eventually they will be solved. It probably would be good 
though to feed problems related to our space back to the community and 
work with them to find solutions.

-- Christian

>> identification/authentication right away and maybe taking OpenID and 
>> see how it might fit in a not web-based environment (read: VW client).
>>

---

From: Christian Scholz <[email-masked]>
Date: Fri, 03 Apr 2009 11:24:02 +0200

Hurliman, John schrieb:
>> we also use the term "domain" in it's more traditional sense to
>> imply a bounds of authority. which is to say, we assume that all
>> hosts and services inside a domain are administered by the same
>> entity. that being said, there's no reason you can't have
>> sub-domains, and there's no reason that two services associated
>> with "the" agent domain can't be split across two administrative
>> domains (like maybe yahoo or AOL get in the business of moving
>> virtual world IM messages but don't want to deploy a world
>> themselves.) it would require some coordination of identity
>> management issues, but i'm sure they're tractable.
> 
> different domain so third party simulators like OpenSim can run under
> a separate trust domain and optionally connect to the aggregate
> Linden Lab service cloud. Tada! You have OGP. It's a great business
> model. Unless you are any company *except* Linden Lab and you want to
> provide a service such as content hosting without becoming a full
> virtual world service provider.

It also reminds me of Facebook and Facebook connect where you also only 
get all or nothing. Moreover FB also defines who actually has access to 
_your_ data (e.g. Google has not). Nevertheless other players such as 
MySpace or Yahoo (and others) are becoming more open in a per-service 
level, e.g. providing OAuth based access to profile or friends data.

What's missing there is still some way to list all of your services 
together and to find out which services a site provides. But there is 
work going on to solve these problems. I guess a good resource is Eran's 
blog (which I also should monitor more closely as a lot has happened 
there since I last looked, namely thoughts about delegated authorization 
as we might need it and XRD vs. XRDS):

http://www.hueniverse.com

> assuming that specialized service providers will be the norm, lumping
> together instant messaging and content hosting under the same
> umbrella doesn't make any sense. This is why I'm in favor of starting
> from the ground up and defining each use case and service endpoint,
> rather than trying to figure out clever ways of shoehorning the
> "right" approach into Linden Lab's OGP.

+1

-- Christian

---

From: Morgaine <[email-masked]>
Date: Fri, 3 Apr 2009 11:58:24 +0100

John and Christian together have nailed a great candidate for the first step
in the process of interoperation, I believe.  Such initial unauthenticated
service discovery would provide the opportunity for choice that leads to
decoupling of services, whereas asking a bundling-prone VW provider for
options is predestined to offer you very little real choice.

On Fri, Apr 3, 2009 at 10:24 AM, Christian Scholz <[email-masked]> wrote:

Hurliman, John schrieb:
>> different domain so third party simulators like OpenSim can run under a
>> separate trust domain and optionally connect to the aggregate Linden Lab
>> service cloud. Tada! You have OGP. It's a great business model.  Unless you
>> are any company *except* Linden Lab and you want to provide a service such
>> as content hosting without becoming a full virtual world service provider.
>>
>
> It also reminds me of Facebook and Facebook connect where you also only get
> all or nothing. Moreover FB also defines who actually has access to _your_
> data (e.g. Google has not). Nevertheless other players such as MySpace or
> Yahoo (and others) are becoming more open in a per-service level, e.g.
> providing OAuth based access to profile or friends data.
>
> together and to find out which services a site provides. But there is work
> going on to solve these problems. I guess a good resource is Eran's blog
> (which I also should monitor more closely as a lot has happened there since
> I last looked, namely thoughts about delegated authorization as we might
> need it and XRD vs. XRDS):
>
>
> <http://www.hueniverse.com>

Those really are excellent points.

Morgaine.

---

From: Charles Krinke <[email-masked]>
Date: Fri, 3 Apr 2009 05:58:01 -0800

I commend you all for finding a way to move forward and authentication is
certainly an important one, but more importantly, working together is the
key.

To the extent we can have a dialog and express our personal opinions in
"soft" manner and do few if any 'it must be my way or the highway", then we
can perhaps get past talking "at" each other and closer to talking "to" each
other.

-- 
Charles Krinke
OpenSim Core Developer
OSGrid Director

---

From: Christian Scholz <[email-masked]>
Date: Fri, 03 Apr 2009 17:16:29 +0200

Hi!

> the service requesting authentication not being reachable from the

So lets look at the spec as it is right now:
http://tools.ietf.org/internet-drafts/draft-hammer-oauth-02.txt

And maybe we should use the same terminology because I might simply be
confused ;-)

So we have:

- a protected resource. This resides on a server and a client wants to
access it on behalf of the server. Could e.g. be a photo

- a client which wants to make an authenticated request to access the
protected ressource. For instance it could be a desktop app as iMovie or
it could be some server somewhere which wants to access e.g. this photo
(or a simulator which wants to access avatar data)

- a resource owner which is basically the user who owns that photo or
avatar.

(in the old spec there was a consumer which is now the client and a
service provider which is now the server storing the protected resource).

The main part of the new version of the specification is about how a
client is supposed to do an authenticated request to obtain the
protected resource. Basically it's using a token and client credentials
to sign the request. The client credential identify the client and the
token identify the resource owner (which need to have given consent to
access it beforehand).

If the signature is valid then access is granted.

Section 4 of the specification defines how a token can be obtained by
the client. But it also says that this is only one possible method. And
this method actually involves the callback URI.

If you now look in section 4.2 you see an OPTIONAL in the description of
oauth_callback. It says:

   oauth_callback
         OPTIONAL.  The client MAY specify an absolute URI for the
         server to redirect the resource owner back to the client when
         authorization has been obtained or denied.

If no callback URI is defined (as it would be definitely true for
desktop apps which can also act as a client) then the server simply
informs the user that this step is finished and the next action needs to
be taken in the client. Usually the user then switches back to the
client desktop app or maybe web page and clicks "Continue".

In an implementation with a web server as a client this might look like
follows:

1. The client web server obtains a temporary token
2. The client web server opens a popup for the resource owner with the
authorization URL of the server storing the protected resource
3. The resource owner (user) eventually logs into the server and gives
consent for the client to access that data (in that popup)
4. The server then tells the resource owner to continue on the client
and shows a "Close window" button.
5. The user clicks that and clicks "Continue" in the main web page of
the client
6. The client then exchanges the temporary token with an access token
behind the scenes.

Here no callback URI is used but usability is maybe also a bit limited
due to that.

Now in the case of virtual worlds we probably have one more party: The
VW client. So we have the following parties involved:

- VW client: The desktop app for using the VW
- VW server: The server the VW client connects to in the first place. It
also acts as a client towards other servers hosting protected resources.
- other servers: Those servers hosting e.g. the profile of a user or
textures or 3D objects

And here it becomes more complicated and there is maybe no solution yet
to it. So this part might be what needs thinking in terms of:

- How would authorization/authentication work at all in such a
distributed environment?
- How can this be implemented with e.g. OAuth (or other means)?

I hope at least the first part of my reply answers your question
regarding callback URIs. Of course another possibility would be to use a
non-web based mechanism for the client to get hold of the access token.
This might be defined in an OAuth Extension.

-- Christian

-- 
Christian Scholz                          Homepage: http://comlounge.net
COM.lounge GmbH                              blog: http://mrtopf.de/blog
Hanbrucher Str. 33                                       Skype: HerrTopf
52064 Aachen                             Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0                           E-Mail [email-masked]
Fax: +49 241 979 00 850                               IRC: MrTopf, Tao_T

neuer Podcast: Der OpenWeb-Podcast (http://openweb-podcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)

---

From: Jon Watte <[email-masked]>
Date: Fri, 03 Apr 2009 10:24:48 -0700

> And maybe we should use the same terminology because I might simply be

That is a re-wording and clarification of the version I had previously read.

I guess the question then is whether service provider implementations 
require the callback URL in their implementation, or whether they'll be 
OK with a NULL callback URL. I know of at least one service provider 
that has a form submission to obtain an application key where the 
callback URL cannot be left empty, but maybe it can be redirected to 
some URI that does nothing.

Regarding service discovery: Does anyone want to start talking about XRDS?
http://xrds-simple.net/core/1.0/

Sincerely,

jw

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 3 Apr 2009 12:04:23 -0600

>From: Jon Watte [mailto:[email-masked]]
>Sent: Friday, April 03, 2009 10:25 AM
>To: Christian Scholz
>Cc: Hurliman, John; [email-masked]

Yes

---

From: Christian Scholz <[email-masked]>
Date: Mon, 06 Apr 2009 23:56:37 +0200

> That is a re-wording and clarification of the version I had previously 

Right.

> some URI that does nothing.

Remember that OAuth is still fairly new and not all use cases or best 
practices have been researched fully yet. But now with Twitter also 
moving towards OAuth more people discover some potential problems such 
as that callback URL, e.g. iPhone applications.
There is some workaround though which was discussed regarding those apps 
which is using a protocol handler, e.g. secondlife:oauth_success which 
could then be catched by that respective application in case of desktop 
or iPhone apps.
You can of course also simply redirect to a dummy URI which simply 
instructs the user to click "Continue" on the original web page.

> http://xrds-simple.net/core/1.0/

Of course, although it's probably replaced soon by the XRD spec (sneak 
peak and examples here: 
http://www.hueniverse.com/hueniverse/2009/03/xrd-weekly-recap.html

So I guess we should name our little project simply "Service Discovery" 
and we need to find out what we actually want to do. The XRD spec for 
describing resources and the LRRD spec for discovering where to find the 
XRD document are already being written so our task might be to check if 
and how they are applicable to our problem space.

So we might need some use cases and requirements and the output might 
eventually be some description of how to apply the XRD suite to our problem.

I personally would be very much interested in what bigger parts a 
virtual world might actually consist of. Right now I guess it's a client 
and a server (or a cluster) in most cases, except Croquet which is only 
clients (is that right?). Now if we decompose things the question is how 
the actual workflow from starting the client to appearing in some 
simulator for other users might look like. And how moving from one 
simulator to another (usually called teleport, technically a login or 
handshake) might look like.

-- Christian