On Tue, Apr 28, 2009 at 2:57 PM, Peter Keane <pjke...@gmail.com> wrote: > > On Tue, Apr 28, 2009 at 7:41 AM, Hubert Le Van Gong <hubert...@gmail.com> > wrote: >> >> I also saw 2 additional ideas that might help >> (and are not necessarily exclusive with the 2 proposals): >> >> (3) Make Request tokens one-time only >> (4) Request that the user logs in at the Consumer before the request >> token request > > Actually, there is no requirement that the Consumer have any notion of > identity, in which case the consumer has no mechanism to sign user in. > The idea here is that you can leverage the the SP's authentication > service as long as you can verify that the u...@sp == u...@consumer. > And the only way to do that is w/ an out-of-band agreement, such as a > PIN that the user gets upon sign-in at the SP and must type in at the > consumer.
So if I understand your use case, in addition to delegated authorization of Consumer to access a resource at SP, OAuth also provides for delegated authentication of the user at the Consumer by the SP? Just trying to get my head around that case... Hubert > > --peter > >> >> Are those off the table? >> I think (3), although potentially difficult to deploy, would significantly >> help. >> Maybe (3) and (4) could be added in the spec as Best Practice or >> Recommendations? >> >> Hubert >> >> >> >> On Sun, Apr 26, 2009 at 7:48 AM, Eran Hammer-Lahav <e...@hueniverse.com> >> wrote: >>> >>> Let's see if we can take a quick break from the discussion and get a sense >>> of where we are. Please answer the questions to follow. >>> >>> --- >>> >>> We have identified 2 solutions listed here: >>> >>> https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory >>> >>> >>> * Signed Approval URLs >>> >>> This proposal breaks the protocol into two separate flows, one for >>> Consumers capable of launching a browser and accepting callbacks, and >>> another for those who can't. It requires a significant rewrite of the >>> specification because of the way the flow and signature are mixed together >>> in the current Core 1.0 specification. >>> >>> >>> * Signed Callback URLs >>> >>> This proposal makes the callback URL part of the signed request for Request >>> Token (which does not allow an attacker to manipulate it), and adds some >>> unpredictable value to the callback redirection that is needed to get an >>> Access Token. >>> >>> The spec changes include (see quick reference at the bottom): >>> >>> - Move the oauth_callback parameter from 6.2.1 to 6.1.1 >>> - Add a new parameter to 6.2.3 which is needed to make 6.3.1 >>> >>> --- >>> >>> Open questions: >>> >>> 1. Am I missing a completely different alternative? If yes, please create a >>> new wiki page and point to it (if you don't have access ask or email it to >>> someone who does). >>> >>> 2. Given the simplicity of the Signed Callback URLs *specification change*, >>> I would like to instead of asking people which solution they prefer, to ask >>> people if they have a strong objection to using the Signed Callback URLs >>> solution, and if so, to explain why? >>> >>> 3. For the Signed Callback URLs solution, what to call the new parameter >>> returned in 6.2.3? Suggestions so far included: >>> >>> - pin >>> - verifier >>> - chaperon >>> - callback token >>> - callback secret >>> >>> 4. And, should the new parameter be added to 6.3.1 (oauth_token + >>> oauth_something) or replace the value of the oauth_token parameter? >>> >>> The second option basically returns an authorized token which is used with >>> the existing secret from 6.1.2. The benefit of a new parameter is it is >>> easier to follow the protocol. The benefit of reusing oauth_token to make >>> 6.3.1 is that is keeps the signed request consistent with all other signed >>> requests (no new parameters). >>> >>> EHL >>> >>> --- >>> >>> Quick Reference >>> >>> 6.1.1. Consumer Obtains a Request Token >>> 6.1.2. Service Provider Issues an Unauthorized Request Token >>> 6.2.1. Consumer Directs the User to the Service Provider >>> 6.2.2. Service Provider Authenticates the User and Obtains Consent >>> 6.2.3. Service Provider Directs the User Back to the Consumer >>> 6.3.1. Consumer Requests an Access Token >>> 6.3.2. Service Provider Grants an Access Token >>> >>> >>> > >>> >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
