Re: [mmox] OGP scalability concerns

"Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com> Thu, 02 April 2009 22:51 UTC

Return-Path: <infinity@lindenlab.com>
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 613FE3A6A63 for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 15:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.219
X-Spam-Level:
X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1]
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 08bpbI0-vPXn for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 15:51:49 -0700 (PDT)
Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id C070A3A6832 for <mmox@ietf.org>; Thu, 2 Apr 2009 15:51:48 -0700 (PDT)
Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id CD9D01414003; Thu, 2 Apr 2009 15:52:50 -0700 (PDT)
Message-Id: <4157ED40-0960-43DB-959A-41AD795521C8@lindenlab.com>
From: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
To: Christian Scholz <cs@comlounge.net>
In-Reply-To: <49D533EA.4010301@comlounge.net>
Content-Type: multipart/alternative; boundary="Apple-Mail-13-560049226"
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 02 Apr 2009 15:52:50 -0700
References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <CD02023C-3E7B-4E76-8429-11035C827E53@lindenlab.com> <f0b9e3410904011701i2ccb03d4r1b48d33cfe3988ea@mail.gmail.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com><49D51A7D.8000104@comlounge.net><62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel .com><49D52DCD.2000806@comlounge.net> <49D531DA.4080006@gmail.com> <49D533EA.4010301@comlounge.net>
X-Mailer: Apple Mail (2.930.3)
Cc: "mmox@ietf.org" <mmox@ietf.org>, Jon Watte <jwatte@gmail.com>
Subject: Re: [mmox] OGP scalability concerns
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: Thu, 02 Apr 2009 22:51:50 -0000

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

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.
>
> 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
>
>
>
> -- 
> COM.lounge GmbH
> http://comlounge.net
> Hanbrucher Strasse 33, 52064 Aachen
> Amtsgericht Aachen HRB 15170
> Geschäftsführer: Dr. Ben Scheffler, Christian Scholz
>
> email: info@comlounge.net
> fon: +49-241-4007300
> fax: +49-241-97900850
>
> personal email: cs@comlounge.net
> personal blog: http://mrtopf.de/blog
> personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox