Re: [ogpx] Fwd: Context for Service Establishment in OGP
"Hurliman, John" <john.hurliman@intel.com> Mon, 01 June 2009 18:09 UTC
Return-Path: <john.hurliman@intel.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 CEABA3A6AB3 for <ogpx@core3.amsl.com>;
Mon, 1 Jun 2009 11:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 i-h5Kga0TcmT for
<ogpx@core3.amsl.com>; Mon, 1 Jun 2009 11:09:39 -0700 (PDT)
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by
core3.amsl.com (Postfix) with ESMTP id E0AB53A6E55 for <ogpx@ietf.org>;
Mon, 1 Jun 2009 11:09:37 -0700 (PDT)
Received: from orsmga002.jf.intel.com ([10.7.209.21]) by
orsmga102.jf.intel.com with ESMTP; 01 Jun 2009 10:58:40 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.41,285,1241420400"; d="scan'208";a="417826313"
Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by
orsmga002.jf.intel.com with ESMTP; 01 Jun 2009 11:17:07 -0700
Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by
rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi;
Mon, 1 Jun 2009 12:09:38 -0600
From: "Hurliman, John" <john.hurliman@intel.com>
To: Infinity Linden <infinity@lindenlab.com>, "ogpx@ietf.org" <ogpx@ietf.org>
Date: Mon, 1 Jun 2009 12:09:34 -0600
Thread-Topic: [ogpx] Fwd: Context for Service Establishment in OGP
Thread-Index: Acni420dz4vcpQD8SmGbyULEvP/lIwAAKlLQ
Message-ID: <62BFE5680C037E4DA0B0A08946C0933D90EA7B13@rrsmsx506.amr.corp.intel.com>
References: <3a880e2c0906010249n34bf1b3di1aa588a6ba9b9bde@mail.gmail.com>
<62BFE5680C037E4DA0B0A08946C0933D90EA7AC2@rrsmsx506.amr.corp.intel.com>
<3a880e2c0906011103y2ad4482bh42a688eacb3876d7@mail.gmail.com>
<3a880e2c0906011104l5969aedatc7b93e89a19f5aca@mail.gmail.com>
In-Reply-To: <3a880e2c0906011104l5969aedatc7b93e89a19f5aca@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [ogpx] Fwd: 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: Mon, 01 Jun 2009 18:09:40 -0000
(I made the same mistake in response) If it's of any use, I wrote a C# library called OpenMetaverse.Http that is capable of generating root certificates and signed client certificates that can be fed into HttpWebRequest as an SSL client cert, plus some basic routines for doing the cert checks on the server. Right now it's only doing a very crude check to make sure the root certificate shows up somewhere in the certificate chain of the client cert and that the chain is valid. No revocation checks or anything. John > -----Original Message----- > From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf > Of Infinity Linden > Sent: Monday, June 01, 2009 11:04 AM > To: ogpx@ietf.org > Subject: [ogpx] Fwd: Context for Service Establishment in OGP > > whoops... sent "reply" instead of "reply to all"... > > > ---------- Forwarded message ---------- > From: Infinity Linden <infinity@lindenlab.com> > Date: Mon, Jun 1, 2009 at 11:03 AM > Subject: Re: [ogpx] Context for Service Establishment in OGP > To: "Hurliman, John" <john.hurliman@intel.com> > > > kk. david and i are threatening to just go off and hack OpenSim to > handle the X.509 client certiness. i think we're probably going to do > a few more rounds of thought experiments and documenting before we run > off and do that, though. > > we might want to all three meet in world somewhere (with the agenda > and minutes of the meeting posted here so other interested peeps can > participate) and come up with a plan for merging your OAuth stuff with > the X.509 stuff we're doing. > > in theory... at the end of this process, we'll have a document that > describes what we've been doing; what worked; what didn't. we then get > to add that to a draft somewhere and declare victory. > > -cheers > > On Mon, Jun 1, 2009 at 10:43 AM, Hurliman, John > <john.hurliman@intel.com> wrote: >> Great to see these ideas written down and being refined. I'm eager to >> see the client cert + OAuth example. >> >> John >> >>> -----Original Message----- >>> From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On >>> Behalf Of Infinity Linden >>> Sent: Monday, June 01, 2009 2:50 AM >>> To: ogpx@ietf.org >>> Subject: [ogpx] Context for Service Establishment in OGP >>> >>> whoops... that last message went out without context... >>> >>> 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 >>> >>> more details and examples forthcoming. >>> >>> -cheers >>> -meadhbh >>> _______________________________________________ >>> ogpx mailing list >>> ogpx@ietf.org >>> https://www.ietf.org/mailman/listinfo/ogpx >> _______________________________________________ >> ogpx mailing list >> ogpx@ietf.org >> https://www.ietf.org/mailman/listinfo/ogpx >> > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx
- [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