I'm more leveraging authentication mechanisms than creating one but yes I agree it would require the Consumer to handle identity. Not sure how to handle the case where the Consumer doesn't do identity. I presume this corresponds to the 2-legged scenario where, rougly, user = Consumer?
Hubert On Fri, Apr 24, 2009 at 5:12 PM, pkeane <[email protected]> wrote: > > > > On Apr 24, 8:41 am, Hubert Le Van Gong <[email protected]> wrote: >> Great discussion! >> >> If I'm correct we'd be OK if, during the authorization step, SP could get a >> confirmation that the user whom has just authenticated is the same than >> the one that triggered the 1st step at the Consumer (request token >> retrieval). >> >> How about something like: >> >> - Since in the std 3-legged scenario, the user logs in before the request for >> the request token is performed, the Consumer could maintain a mapping >> between the user's ID and the request token. >> >> - We could then add a "confirmation step" just after the authorization one >> (before redirecting to the callback URL) where >> the SP redirects the UA (along with the request token) to the Consumer >> so that the latter can verify the mapping. If the user has an >> existing authenticated >> session (at the Consumer) then this can be transparent. If not the user >> authenticates. In both case the Consumer can then check that the >> current user corresponds to the one in its mapping table. > > This is correct, but it's important to point out that you have thus > created an authentication mechanism (and authentication is hard). > Note also that as it stands, consumers might have no concept of > "identity" at all. It always struck me that OAuth was trying to get > "free lunch" (as in "there is no...") in this regard. So I'd like to > see it stated up front that we need to authenticate between user at > step A and user at step B, then provide mechanisms w/ varying degrees > of UX goodness vs. security assurance that address it. *Note* that a > consumer w/ a good authentication mechanism already (and many have it) > have the opportunity to provide a much more secure OAuth interaction. > Perhaps there could be a "high assurance" flavor of OAuth that > required the consumer to have an autentication mechanism. Just > thinking.... > >> >> I realize it requires an extra step but, lacking identity federation, that's >> the >> only thing I can think of... >> >> HTH >> Hubert > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
