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
