I was having a discussion last week regarding different uses of OAuth (initially around using OAuth as a binding for SAML messages) and in the discussion worked through the following use case.
A "client" or user-agent wants to authenticate a user to the user's IdP. Doing so requires signing and ideally a "proof-of-possession" mechanism of the user's credentials. There have already been proposals of using the OAuth signing mechanism with an API that passes the loginid/password over SSL. What is different about this proposal, is that the loginid is specified as the access token value and the password is specified as the access token secret. This way, the password is used to sign the request but never traverses the connection. Use of the consumer token and secret is optional but works fine with the current OAuth signature mechanism. In prinicple, OAuth is trying to keep the user from giving their credentials to any service other than their identity provider. However, in the case of a "client" wanting to authenticate the user to the user's identity provider (potentially where no browser exists), this seems like a much better mechanism than passing the credentials on the wire. Thoughts? Thanks, George --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
