Subject: [OAUTH-WG] Alternative Upgrade Flow

From: Justin Richer <[email-masked]>
Date: Fri, 16 Jul 2010 12:48:24 -0400

The current proposal for a 1.0->2.0 upgrade flow is to use the assertion
profile and pass the OAuth token in there. Instead, one could create an
endpoint that speaks the 1.0 protocol fully, signatures and client
secrets and everything, but issues 2.0 tokens, JSON and all. It's a
hybridized endpoint also, but put together with the opposite pieces. In
both cases, you put a 1.0 token in one end and get a 2.0 token out the
other. But in this case, the request being made is a completely vanilla
OAuth 1.0 protected resource access request. 

Does this really need a separate endpoint, or can we extend the
grant_type options to include "oath1.0" in an extension? I know that
extensions aren't currently allowed to make new grant_types -- I think
they should be able to and and proposing that we allow that extension
point. I dislike the reasoning of "just cram it all into an assertion to
extend", since it doesn't allow for clients to separate out their
parameters easily.

 -- Justin

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 16 Jul 2010 09:56:17 -0700

> OAuth 1.0 protected resource access request.

I already proposed something like that, if there is interest I can
update the proposal to be in line with the latest spec:
http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html

Marius

---

From: Justin Richer <[email-masked]>
Date: Fri, 16 Jul 2010 13:03:46 -0400

Oh hey, so you did. And I even agreed to it back then! Yeah, let's
update it. Between this and the other proposed upgrade flow, we should
cover most ways people would want to trade one flavor of token for
another. 

 -- Justin

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 17 Jul 2010 14:30:57 +0200

I think we gonna need additional end points anyway, e.g. for token 
revocation. So why not use another endpoint for that purpose? That way 
the tokens endpoint is not overloaded to much.

regards,
Torsten.

Am 16.07.2010 18:48, schrieb Justin Richer:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "William Mills" <[email-masked]>
Date: Mon, 19 Jul 2010 08:58:36 -0700

Seems like we could also simply put up a 1.0a PR that issues a 2.0
token.  That avoids wedging 1.0 stuff into 2.0. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Torsten Lodderstedt
> Sent: Saturday, July 17, 2010 5:31 AM
> To: Justin Richer
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] Alternative Upgrade Flow
> 
> I think we gonna need additional end points anyway, e.g. for 
> token revocation. So why not use another endpoint for that 
> purpose? That way the tokens endpoint is not overloaded to much.
> 
> regards,
> Torsten.
> 
> > The current proposal for a 1.0->2.0 upgrade flow is to use the 
> > assertion profile and pass the OAuth token in there. Instead, one 
> > could create an endpoint that speaks the 1.0 protocol fully, 
> > signatures and client secrets and everything, but issues 
> 2.0 tokens, 
> > JSON and all. It's a hybridized endpoint also, but put 
> together with 
> > the opposite pieces. In both cases, you put a 1.0 token in 
> one end and 
> > get a 2.0 token out the other. But in this case, the request being 
> > made is a completely vanilla OAuth 1.0 protected resource 
> access request.
> >
> > point. I dislike the reasoning of "just cram it all into an 
> assertion 
> > to extend", since it doesn't allow for clients to separate 
> out their 
> > parameters easily.
> >
> >   -- Justin
> >

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 19 Jul 2010 10:37:26 -0700

> token.  That avoids wedging 1.0 stuff into 2.0.

That's exactly what the bridge endpoint is doing.

Marius