Re: [oauth] FW: I-D Action:draft-dehora-farrell-oauth-accesstoken-creds-01.txt

[Onyx Raven <[e-mail]>]

I think I would rather see an exchange for a real access token as is
in the spec.  This way, the provider can easily change backends, and
the consumer can cache the credentials without any directly-derived
data.

For consumers who for one reason or another just cannot do the web
redirect dance, we at Photobucket have been doing a 'direct login'
which exchanges username and hashed password for access token
credentials, and it is only given for 'known' partners.  We've been
clear in our licensing of the method that user-agents nor consumers
should cache the user inputs, but the access tokens instead.  Mobile
and device consumers are already using it.  Its not basic/digest, its
a specific REST POST, but its in the same spirit as the spec.

IIRC, when I was first implementing OAuth SP a year ago, there were
some example use cases where the Consumer/UserAgent could request the
temporary token, and present it to the user to enter on a different
channel.  I am reminded that this is essentially the way Netflix
device activation works.  You get the activation key, and then on your
PC, you login to your account on the provider and enter the key.  That
signs the request, and back on the device, it either waits for a
button-press to attempt to proceed, or auto-checks the key to see if
it's signed.  The device can then complete the oauth access token
procedure.  This seems to be a convenient way of obtaining an access
token, which is fully supported by the current OAuth Core spec if
implemented properly.  I know that's not the direct intention of the
spec in the subject, but it is an alternative.

Back to the spec in the subject - aside from the blow question about
rfc2617 HTTP Basic (or even Digest), is the current oauth extension
parameter format of using 'xoauth_' not used anymore?

On Tue, Mar 10, 2009 at 9:57 AM, George Fletcher <[e-mail]> wrote:
> A few comments on this spec...
>
> Would a viable addition to this current specification be to allow the access
> token to be constructed from the username and password? (e.g. access token
> key == username, access token secret == password).
>
> This allows the password to not be sent in the clear over a
> "mutally-authenticated transport layer". I realize that using the password
> in this way requires the server to have a stored copy of the clear text
> password, but it seems like allowing this mechanism could reduce the
> requirement on the "mutally-authenticated transport layer". And may be
> viable and preferred in some circumstances.
>
> Also, in OAuth each part of the flow has a defined endpoint. I didn't see
> that defined in this spec. What about defining the extension to have a
> specific endpoint 'client_auth' that can be discovered via XRDS?
>
> Thanks,
> George
>
> Stephen Farrell wrote:
>>
>> Basic or Digest would, I think, represent the consumer
>> authenticating as itself and could in fact be mixed with
>> the consumer passing on the user's credentials in order
>> to get an access token. (That was explicitly called out
>> in -00 but removed here since we bumped the security
>> level somewhat. Could add it back though.)
>>
>> So, at least for the aggregator use case, I think these
>> are a) semantically different and b) might even be used
>> at the same time and so shouldn't be mixed.
>>
>> I could imagine however an option for a user agent to
>> use Basic or Digest in an exchange that'd result in
>> acquisition of an access token. (Which is I guess what
>> your blog post below is about.) But since that'd require
>> a change to the browser to be generally useful we didn't
>> go there. I'd have to think about whether that'd work
>> for mobile use cases, but I suspect that the requirement
>> for two round-trips'd work against it there.
>>
>> S.
>>
>> Eran Hammer-Lahav wrote:
>>
>>>
>>> Here's a silly question, why not just use HTTP Basic or Digest auth to
>>> accomplish the same thing? Ask for a token using the actual resource owner's
>>> server credentials (username and password) and, well, get one.
>>>
>>> Am I missing something?
>>>
>>> More ideas in
>>> http://www.hueniverse.com/hueniverse/2009/02/beyond-the-oauth-web-redirection-flow.html
>>>
>>> EHL
>>>
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of [e-mail]
>>> Sent: Monday, March 09, 2009 12:00 PM
>>> To: [e-mail]
>>> Subject: I-D Action:draft-dehora-farrell-oauth-accesstoken-creds-01.txt
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>  Title           : OAuth Access Tokens using credentials
>>>  Author(s)       : B. hOra, S. Farrell
>>>  Filename        : draft-dehora-farrell-oauth-accesstoken-creds-01.txt
>>>  Pages           : 13
>>>  Date            : 2009-03-09
>>>
>>> OAuth Access Tokens using credentials is a technique for allowing user
>>> agents to obtain an OAuth access token on behalf of a user without requiring
>>> user intervention or HTTP redirection to a browser.
>>> OAuth itself is documented in the OAuth Core 1.0 Specification.Editorial
>>> Note
>>>
>>> To provide feedback on this Internet-Draft, email the authors.
>>>
>>> A URL for this Internet-Draft is:
>>>
>>> http://www.ietf.org/internet-drafts/draft-dehora-farrell-oauth-accesstoken-creds-01.txt
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> oauth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> _______________________________________________
>> oauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> _______________________________________________
> oauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>