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