Re: [mmox] OGP scalability concerns
Christian Scholz <cs@comlounge.net> Thu, 02 April 2009 21:53 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 C56D43A6A7C for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 14:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.162
X-Spam-Level:
X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, J_CHICKENPOX_36=0.6]
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 g3GC0dJIAhpD for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 14:53:03 -0700 (PDT)
Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 7ADD33A67A1 for <mmox@ietf.org>; Thu, 2 Apr 2009 14:52:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 9D86F1CE0145; Thu, 2 Apr 2009 23:53:46 +0200 (CEST)
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 0uaCbBOT0EMV; Thu, 2 Apr 2009 23:53:45 +0200 (CEST)
Received: from [192.168.2.101] (pC19EBF8B.dip.t-dialin.net [193.158.191.139]) by post.comlounge.net (Postfix) with ESMTP id 22BDF1CE00CC; Thu, 2 Apr 2009 23:53:45 +0200 (CEST)
Message-ID: <49D533EA.4010301@comlounge.net>
Date: Thu, 02 Apr 2009 23:53:46 +0200
From: Christian Scholz <cs@comlounge.net>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Jon Watte <jwatte@gmail.com>
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>
In-Reply-To: <49D531DA.4080006@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "mmox@ietf.org" <mmox@ietf.org>
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 21:53:04 -0000
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
- 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