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 > >
- [ogpx] Context for Service Establishment in OGP Infinity Linden
- Re: [ogpx] Context for Service Establishment in O… Hurliman, John
- [ogpx] Fwd: Context for Service Establishment in … Infinity Linden
- Re: [ogpx] Fwd: Context for Service Establishment… Hurliman, John
- Re: [ogpx] Fwd: Context for Service Establishment… Infinity Linden
- Re: [ogpx] Fwd: Context for Service Establishment… Hurliman, John
- Re: [ogpx] Context for Service Establishment in O… Christian Scholz
- Re: [ogpx] Context for Service Establishment in O… David W Levine
- Re: [ogpx] Context for Service Establishment in O… Infinity Linden
- Re: [ogpx] Context for Service Establishment in O… Hurliman, John