The PIN could actually be delivered out of band at the time of authorization (via SMS, for example).
I agree that more shared secrets doesn't necessarily help things, but it's like FriendFeed's Remote Key... I'm not a huge fan of it since it puts the burden on the user to remember yet another SS, but insomuch as a PIN could enable a smoother desktop experience, as you've described, it might be worth prototyping at least. Chris On 1/29/09, George Fletcher <gffle...@aol.com> wrote: > > 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 >> >> > > > > > -- 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 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 -~----------~----~----~----~------~----~------~--~---
