I guess you could say the flow I proposed is a one token exchange. There is only the access token that is returned back to the consumer from the authorization callback.
As for the whole callback parameter, I don't like it at all. I see it as bad practice of dynamically setting this URL. It should be possible to just use a single URL that you register with the provider. I just can't think of an use case that would require a dynamic callback. On Sat, Apr 25, 2009 at 12:00 AM, Dossy Shiobara <[email protected]> wrote: > > On 4/25/09 12:31 AM, pkeane wrote: > > If I am following correctly, this should work. But there are a few > > drawbacks I see. It is fairly dramatically different from the way > > OAuth works now for all parties: user, consumer, provider. > > Right. OAuth, as it is specified in 1.0, has flaws that will require > changes that affect all parties. > > > It also seems quite complex (maybe I am being dense :) to me, a > > hallmark of a good security scheme is simplicity and clarity to the > > extent possible. > > I dunno, it seems remarkably simple to me. Matter of fact, I don't see > any ways to make it any simpler without losing important security. > > -- > Dossy Shiobara | [email protected] | http://dossy.org/ > Panoptic Computer Network | http://panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
