Re: [ogpx] Context for Service Establishment in OGP

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

> -----Original Message-----
> From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf 
> Of Infinity Linden
> Sent: Tuesday, June 02, 2009 2:52 PM
> To: Christian Scholz
> Cc: ogpx@ietf.org
> Subject: Re: [ogpx] Context for Service Establishment in OGP
> 
> 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 mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx