Yes, using a PIN instead of a password would work as well. The general principle is that the user is using a "remembered shared secret" to sign the request to prove they "know" it. The OAuth signature mechanism provides a convenient way to do the "proof".
One interesting question about your PIN idea is whether a PIN should be associated with a Consumer via some other, out-of-band provisioning process (i.e. the PIN is specific to the Consumer token). Or whether a PIN should be associated with a set of generic authorization capabilities. This is more useful if a user has only a few identities and a central way to manage authorization. In the current model of each SP also being the IdP for it's service, using a PIN model just increases the number of "shared secrets" the user has to remember. However, it does provide a way to authorize limited capabilities that passwords don't. As for software asking for passwords, I believe this has a relatively narrow scope. For instance the AOL desktop client asking for the AOL password. I agree that we should move away from the current model where Facebook asks for the AOL password when finding friends. Thanks, George Chris Messina wrote: > 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 <gffle...@aol.com > <mailto:gffle...@aol.com>> 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 > <h...@granqvist.com <mailto:h...@granqvist.com> > > <mailto:h...@granqvist.com <mailto:h...@granqvist.com>>> 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> > <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 > > <jmkrist...@gmail.com <mailto:jmkrist...@gmail.com> > <mailto:jmkrist...@gmail.com <mailto:jmkrist...@gmail.com>>> 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> <http://factoryjoe.com> # > diso-project.org <http://diso-project.org> > > <http://diso-project.org> > > citizenagency.com <http://citizenagency.com> > <http://citizenagency.com> # vidoop.com <http://vidoop.com> > > <http://vidoop.com> > > This email is: [ ] bloggable [X] ask first [ ] private > > > > > > > > > > > -- > 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 > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
