Subject: [ogpx] Context for Service Establishment in OGP

From: Infinity Linden <[email-masked]>
Date: Mon, 1 Jun 2009 02:49:48 -0700

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

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 1 Jun 2009 11:43:58 -0600

Great to see these ideas written down and being refined. I'm eager to see the client cert + OAuth example.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Infinity Linden
> Sent: Monday, June 01, 2009 2:50 AM
> To: [email-masked]
> Subject: [ogpx] Context for Service Establishment in OGP
> 
> 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:
> 
> 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
> 
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx

---

From: Infinity Linden <[email-masked]>
Date: Mon, 1 Jun 2009 11:04:20 -0700

whoops... sent "reply" instead of "reply to all"...

---------- Forwarded message ----------
From: Infinity Linden <[email-masked]>
Date: Mon, Jun 1, 2009 at 11:03 AM
Subject: Re: [ogpx] Context for Service Establishment in OGP
To: "Hurliman, John" <[email-masked]>

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

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 1 Jun 2009 12:09:34 -0600

(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

> Sent: Monday, June 01, 2009 11:04 AM
> To: [email-masked]
> Subject: [ogpx] Fwd: Context for Service Establishment in OGP
> 
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Infinity Linden
>>> establishment URL, you'll get a seed cap back * with that seed cap,
>>> you can request those specific capabilities you require
>>>

---

From: Infinity Linden <[email-masked]>
Date: Mon, 1 Jun 2009 11:19:36 -0700

cool. lemme go look at it. i think the one thing we're looking at
doing that's "allowed by pkix, x.509 and TLS; but not implemented by
many libraries" is the ability to do cert chain validation based on
the root AND an intermediate cert. i'm most familiar with OpenSSL that
allows you to define a callout for cert chain validation (but which is
a royal pain in the keester to implement). i'm assuming other stacks
have the ability to do similar callouts, and it sounds like you're
about 95% of the way there already.

hmm... lemme write down a few notes about where i think we're at with
the PKI stuff so peeps can see if it makes sense to them

-cheers
-m

---

From: "Hurliman, John" <[email-masked]>
Date: Mon, 1 Jun 2009 12:57:59 -0600

Yes, that's what .NET does. You define a callback that has access to a helper function to determine if all the crypto bits are in the right spot, but other than a basic sanity check you have to walk the certificate chain yourself and do your own checks. "Does the fingerprint of this cert match my intermediate cert or the root cert? If yes..."

John

> From: Infinity Linden [mailto:[email-masked]]
> Sent: Monday, June 01, 2009 11:20 AM
> To: Hurliman, John
> Cc: [email-masked]
> Subject: Re: [ogpx] Fwd: Context for Service Establishment in OGP
> 
>> 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
>> 
>>> participate) and come up with a plan for merging your OAuth stuff
>>> with the X.509 stuff we're doing.
>>> 
>>> 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
>>> 
>>>>> regarding X.509, and at some point it made sense to abstract the
>>>>> three different authentication / authorization schemes into a single
>>>>> 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:
>>>>> 
>>>>> 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
>>>>> defined service establishment URL, you'll get a seed cap back * with
>>>>> that seed cap, you can request those specific capabilities you
>>>>> require
>>>>>

---

From: Christian Scholz <[email-masked]>
Date: Tue, 02 Jun 2009 21:22:59 +0200

Hi!

First of all great to see some action again :-)

And who is actually coming to Stockholm?

> * 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: [email-masked]
fon: +49-241-4007300
fax: +49-241-97900850

personal email: [email-masked]
personal blog: http://mrtopf.de/blog
personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net

---

From: David W Levine <[email-masked]>
Date: Tue, 2 Jun 2009 15:32:13 -0400

I will be there. 

Christian Scholz <[email-masked]> 
Sent by: [email-masked]
06/02/2009 03:22 PM

To
Infinity Linden <[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
Re: [ogpx] Context for Service Establishment in OGP

Hi!

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

personal email: [email-masked]
personal blog: http://mrtopf.de/blog
personal podcasts: http://openweb-podcast.de, 
http://datawithoutborders.net

---

From: Infinity Linden <[email-masked]>
Date: Tue, 2 Jun 2009 14:52:27 -0700

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 <[email-masked]> wrote:
> 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

---

From: "Hurliman, John" <[email-masked]>
Date: Tue, 2 Jun 2009 18:20:25 -0600

And just for context, the Cable Beach architecture doesn't replace CAPS entirely either. One or more capabilities are returned alongside the final access token, so the access token becomes junk data (since the consumer has already received what they came for).

In my opinion, the access token in OAuth is just one common token system for implementations to use. It goes to great lengths to support other systems, and you don't get better integration with existing services or a medal for sticking "closer to the intention of the spec" if you use the default OAuth request token instead of capabilities.

John

> Sent: Tuesday, June 02, 2009 2:52 PM
> To: Christian Scholz
> Cc: [email-masked]
>>  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
>> personal blog: http://mrtopf.de/blog personal podcasts:
>> http://openweb-podcast.de, http://datawithoutborders.net
>> 
>>