Ah ha. I get it. That makes sense -- though it does seem like the goal should be to move away from asking for usernames and passwords.
This, however, speaks to my concept of an account pin, where you could authorize desktop apps with an easy-to-remember pin that doesn't give you full account access, but only allows you to validate that you own the account. So you would have a full access password (seldom used) and an identification PIN -- almost like a security question (we know how well those work). So instead of a user inputting their username and password, they would input their username and PIN, and the PIN would be used to sign the request, proving to the SP that it's the right user -- and then the SP would provide the access token. Is that a similar but equally effective approach? Chris On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher <[email protected]> wrote: > > Thanks for this history Chris. I remember it still being "API > authentication" in the first drafts of the OAuth IPR document; because > it was one of my comments on the doc:) > > ---- > > Here is an example usage. Again, this is more about leveraging the OAuth > signature mechanism than trying to represent the whole OAuth flow. > > Currently at AOL we have a clientLogin API that allows a "client" (think > destop app or mobile device) to authenticate a user and then access > services at AOL. Basically, the authentication credentials are exchanged > for a token that is used subsequently to access the APIs. The user's > credentials are only passed to the AOL authentication service, over SSL, > for validation. > > With the method suggested, the same validation could take place but the > password would not be present in the request. Instead it would be used > to sign the request. The request is only valid if the receiving > authentication system can generate the signature using the password for > that user. The successful response of such a request would be the API > access token currently used. > > Another possibility (the example from the initial discussion) is using > this mechanism with TLS in order to return to the "client" a SAML > Holder-of-Key Assertion. This is the same concept of exchanging one set > of credentials for another credential (in this case a SAML Assertion). > > I realize that there are security issues with allowing a "client" or API > based authentication mechanism, but there are certain cases where it > provides a better user experience and the user is comfortable trusting > the application/device. > > Thanks, > George > > Chris Messina wrote: > > Hmm. Historically the separation came from the way the communities > > grew up actually. There were thoughts initially to make OAuth and > > extension of OpenID but because I was wary of the politics within the > > OpenID community, I pushed for keeping OAuth completely separate and > > avoid having to do anything with authentication (so that it could be > > used with OpenID, but would have its own adoption curve). > > > > The typo on the homepage was probably my fault, since, being the > > identity n00b, I didn't realize the difference until after I went home > > from the DevHouse where I put up the homepage after a couple beers. It > > didn't change because (apparently!) no one else seemed to read it that > > closely. > > > > Funny how these things develop -- not always out of explicit > > intention, but just because of the time allotted to get the thing out > > the door! > > > > ...as for your idea, George, I think I get it, and it sounds > > interesting. Can you give a concrete example where that could be used > > today? > > > > Chris > > > > On Wed, Jan 28, 2009 at 12:58 PM, Hans Granqvist <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > Yep. The entire authentication/authorization discussion is sadly > > muddled. > > The OAuth/OpenID hybrid proposal is adding to the confusion. > > > > Sometimes I feel like we (people who have interest in the two > > concepts) > > maintain there is a difference to justify standards' existence, > > even if > > it's largely an academic difference with no pragmatic real meaning. > > > > Other times it feels okay that they should be separate. Just one > > of those > > things, I guess. > > > > For the longest time oauth.net <http://oauth.net> claimed OAuth > > was for API authentication > > and no one really noticed. > > > > The only thing worth being very strict about, IMO, is identity and > > authentication. Never the twain should meet. > > > > It's HMACs all the way down anyway :) > > > > Hans > > > > > > On Wed, Jan 28, 2009 at 12:02 PM, John Kristian > > <[email protected] <mailto:[email protected]>> wrote: > > > > > > Yes, a digital signature can be used for authentication. SSL/TLS is > > > one example. OAuth specifies some signing algorithms that could be > > > used for the purpose. > > > > > > But it seems dangerous to extend OAuth to do authentication as > > well as > > > authorization. Better for OAuth to focus on doing one thing really > > > well. > > > > > > > > > > > > > > > > > > > -- > > Chris Messina > > Citizen-Participant & > > Open Web Advocate-at-Large > > > > factoryjoe.com <http://factoryjoe.com> # diso-project.org > > <http://diso-project.org> > > citizenagency.com <http://citizenagency.com> # vidoop.com > > <http://vidoop.com> > > This email is: [ ] bloggable [X] ask first [ ] private > > > > > > > > > -- Chris Messina Citizen-Participant & Open Web Advocate-at-Large factoryjoe.com # diso-project.org citizenagency.com # vidoop.com This email is: [ ] bloggable [X] ask first [ ] private --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
