Re: [mmox] The Story So Far...

Christian Scholz <cs@comlounge.net> Wed, 18 February 2009 01:26 UTC

Return-Path: <cs@comlounge.net>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23B23A69FF for <mmox@core3.amsl.com>; Tue, 17 Feb 2009 17:26:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.066
X-Spam-Level:
X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWXqFa1B1wfT for <mmox@core3.amsl.com>; Tue, 17 Feb 2009 17:26:21 -0800 (PST)
Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 62C9F3A6941 for <mmox@ietf.org>; Tue, 17 Feb 2009 17:26:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id BB6541CE037D; Wed, 18 Feb 2009 02:26:32 +0100 (CET)
Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-a27Y7k14Ue; Wed, 18 Feb 2009 02:26:23 +0100 (CET)
Received: from [192.168.178.40] (pD9EBE698.dip.t-dialin.net [217.235.230.152]) by post.comlounge.net (Postfix) with ESMTP id ACF191CE0378; Wed, 18 Feb 2009 02:26:19 +0100 (CET)
Message-ID: <499B63B9.90102@comlounge.net>
Date: Wed, 18 Feb 2009 02:26:17 +0100
From: Christian Scholz <cs@comlounge.net>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <B8A94709-07E4-4FF8-B321-A4123E9DC633@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> <499B557A.2010106@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D501FDD32@rrsmsx506.amr.corp.intel.com> <3E2F33BB-0648-4101-BE28-58A164D3A66F@lindenlab.com>
In-Reply-To: <3E2F33BB-0648-4101-BE28-58A164D3A66F@lindenlab.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "mmox@ietf.org" <mmox@ietf.org>
Subject: Re: [mmox] The Story So Far...
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2009 01:26:22 -0000

Meadhbh Hamrick (Infinity) schrieb:
> cool. the existing OGP protocol can be "retasked" to carry OpenID 
> information, though it was neither designed for this nor was there any 
> public discussion about doing it.
> 
> now that there's public discussion about doing it, lemme dig up my notes 
> about some of the issues we thought we had with it and we can move 
> forward with putting it into the protocol.

That sounds great and I would be very interested in the issues (and 
maybe the openid mailing list as well). Would be great to actually also 
have that implemented in the client ;-) Another idea might here be 
though to use OAuth for the client as well. It would then basically work 
like the flickr uploadr works by opening a web site where you confirm 
access and by some token exchange in the background. This would 
eliminate the problem of needing a web browser for OpenID (but might 
have security implications as you give full access and are not asked for 
a password again for some amount of time).

But just brainstorming here.. definitely a problem which needs to get 
tackled regarding OpenID in general as more and more devices might not 
have a web browser or maybe are too annoying to use that way.

-- Christian


> 
> On Feb 17, 2009, at 5:02 PM, Hurliman, John wrote:
> 
>> The proposal for a virtual world identity service that I've been 
>> typing away at uses OpenID, OpenID Attribute Exchange, and OpenID 
>> Token Exchange to define a base set of interfaces and attributes for 
>> virtual world identity. In my opinion, there's a balancing act between 
>> asserting that virtual worlds add nothing new to the equation and 
>> nothing needs to be developed, and asserting that virtual worlds are 
>> an entirely new problem and throwing away the last decade or more of 
>> work.
>>
>> John
>>
>>> -----Original Message-----
>>> From: Christian Scholz [mailto:cs@comlounge.net]
>>> Sent: Tuesday, February 17, 2009 4:25 PM
>>> To: Hurliman, John
>>> Cc: mmox@ietf.org
>>> Subject: Re: [mmox] The Story So Far...
>>>
>>> Hi!
>>>
>>> Hurliman, John schrieb:
>>>
>>>>
>>>> The agent domain concept takes several independent services (identity,
>>> presence, inventory) and lumps them together into a single trust domain.
>>> This inhibits the development of a widely distributed ecosystem like we
>>> find on the web today, and is really only convenient for large virtual
>>> world service providers that already have a vertical stack of services.
>>> It also drags in the assumption that there must be a backend
>>> communication layer between services such as inventory and simulation
>>> regions.
>>>
>>> Speaking of the web: There are already a lot of social networks out
>>> there which are right now going to work on interoperability regarding
>>> profile data, activity streams, authentication and general authorization
>>> (based on efforts like OAuth (now also here at IETF), OpenID,
>>> OpenSocial, PortableContacts, XRDS-Simple etc.).
>>>
>>> It would be great if these efforts can be integrated so that we don't
>>> have the problem in the end to bring web and virtual world together
>>> although both have basically the same idea of distributed services (and
>>> even partly the same services).
>>>
>>> So let me ask in the question: Is this of general interest for this
>>> group to try to bridge that web/VW gap as well?
>>>
>>> I think it would be of value because many of the protocols are already
>>> in use and thus are understood, have library support and so on.
>>>
>>> That being said IMHO the Agent Domain really could be far more separated
>>> into separate services. All you maybe need is one starting point for
>>> your identity and some service catalogue which lists where all the other
>>> services are, either your individual ones (where is my profile, where
>>> are my group memberships) or service level ones (where is the region
>>> info, which login methods do you support).
>>>
>>> -- Christian
>>>
>>>
>>> -- 
>>> Christian Scholz
>>> Blog: http://mrtopf.de/blog
>>> Company: http://comlounge.net
>>> Podcasts: http://datawithoutborders.net, http://openweb-podcast.de
>>>
>> _______________________________________________
>> mmox mailing list
>> mmox@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmox
> 
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox


-- 
Christian Scholz
Blog: http://mrtopf.de/blog
Company: http://comlounge.net
Podcasts: http://datawithoutborders.net, http://openweb-podcast.de