Re: [ogpx] Context for Service Establishment in OGP

Infinity Linden <infinity@lindenlab.com> Tue, 02 June 2009 21:52 UTC

Return-Path: <infinity@lindenlab.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D9D03A69D4 for <ogpx@core3.amsl.com>; Tue, 2 Jun 2009 14:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level:
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 qysuBj8QioLZ for <ogpx@core3.amsl.com>; Tue, 2 Jun 2009 14:52:28 -0700 (PDT)
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id 200823A68E0 for <ogpx@ietf.org>; Tue, 2 Jun 2009 14:52:28 -0700 (PDT)
Received: by an-out-0708.google.com with SMTP id c3so6274101ana.4 for <ogpx@ietf.org>; Tue, 02 Jun 2009 14:52:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.126.15 with SMTP id y15mr327749anc.71.1243979547304; Tue, 02 Jun 2009 14:52:27 -0700 (PDT)
In-Reply-To: <4A257C13.20407@comlounge.net>
References: <3a880e2c0906010249n34bf1b3di1aa588a6ba9b9bde@mail.gmail.com> <4A257C13.20407@comlounge.net>
Date: Tue, 2 Jun 2009 14:52:27 -0700
Message-ID: <3a880e2c0906021452v2af887b0q98a5a971155dd2ef@mail.gmail.com>
From: Infinity Linden <infinity@lindenlab.com>
To: Christian Scholz <cs@comlounge.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "ogpx@ietf.org" <ogpx@ietf.org>
Subject: Re: [ogpx] Context for Service Establishment in OGP
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2009 21:52:29 -0000

hey tao. i'll be in stockholm too.

as for OAuth... i think right now we're looking at just service
establishment, and i think the main use case is for an agent domain to
use a remote service that already has OAuth enabled (perhaps something
like Zha's AD pointing towards OpenSim instances with a cable beach
asset backend.) it is NOT a complete re-imagining of the protocol to
abandon caps and replace then with OpenID/OAuth/XRDS.

-cheers
-m

On Tue, Jun 2, 2009 at 12:22 PM, Christian Scholz <cs@comlounge.net> wrote:
> Hi!
>
> First of all great to see some action again :-)
>
> And who is actually coming to Stockholm?
>
>> i've been talking with John Hurliman about OAuth and David Lavine
>> regarding X.509, and at some point it made sense to abstract the three
>> different authentication / authorization schemes into a single
>> "service establishment pattern." The message I just sent out really
>> describes only the mechanism (and only enough mechanism to understand
>> the concept.) over the next couple of weeks, i'd like to add some more
>> detail to this and integrate it into the OGP : Authentication
>> document. So feedback will definitely be welcomed.
>>
>> to recap:
>>
>> * there are three different types of authentication / authorization:
>> password, X.509 and OAuth
>> * password auth is appropriate for user -> server authentication
>> * X.509 is appropriate for server <-> server authentication, and
>> * OAuth is appropriate for server -> distant peer (whom you may not
>> have an explicit trust relationship with.)
>> * in all cases, you start with an authenticator (a password, a
>> certificate or a token) and by presenting it to a server at a well
>> defined service establishment URL, you'll get a seed cap back
>> * with that seed cap, you can request those specific capabilities you
>> require
>
> I personally would prefer it more if OAuth would replace those caps (as you
> probably know). Are there any plans to do more than just the initial step?
> Also what problem we are trying to solve here? What is an example use case?
> I think that would help me to understand the context even more :-)
>
>
> -- 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
>
>