Re: [mmox] OGP scalability concerns
"Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com> Thu, 02 April 2009 22:49 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 EA01B3A6CBB for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 15:49:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.224
X-Spam-Level:
X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, 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 mAvoRIIlmf99 for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 15:49:47 -0700 (PDT)
Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id BD4393A6AD4 for <mmox@ietf.org>; Thu, 2 Apr 2009 15:49:47 -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 E0C731414003; Thu, 2 Apr 2009 15:50:49 -0700 (PDT)
From: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
To: Christian Scholz <cs@comlounge.net>
In-Reply-To: <49D533EA.4010301@comlounge.net>
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>
Message-Id: <4DF1C9A3-6170-4448-95DD-A3C72901A53A@lindenlab.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 02 Apr 2009 15:50:49 -0700
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:49:49 -0000
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
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Lawson English
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Jason Giglio
- Re: [mmox] OGP scalability concerns Rob Lanphier
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Christian Scholz