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

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 9 Mar 2009 22:31:10 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 09, 2009 12:00 PM
To: [email-masked]
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.
W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1kZWhvcmEtZmFycmVsbC1vYXV0aC1hY2Nlc3N0b2tlbi1jcmVkcy0wMS50eHQNCg==

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Mar 2009 09:56:36 +0000

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:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> oauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: George Fletcher <[email-masked]>
Date: Tue, 10 Mar 2009 11:57:21 -0400

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

---

From: Onyx Raven <[email-masked]>
Date: Tue, 10 Mar 2009 22:02:10 -0600

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 <[email-masked]> wrote:
> 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).
>
> "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:
>>
>>> 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
>>>
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of [email-masked]
>>> 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.
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>>
>>>

---

From: Justin Hart <[email-masked]>
Date: Tue, 10 Mar 2009 22:16:22 -0600

Sorry, I should use my real-name identity for the list here.  Anyway,
I realize that what I describe below is sort of the compliment of the
'Valet key' and similar to the approval-queue as described in the blog
post below.  If I'm not missing any pieces, I think its a fully viable
alternative.

I'm looking to implement at least one of these methods as a
non-login-based alternative to the web redirects (avoiding direct
auth) for devices for Photobucket.  I sort of like the 'activation
key' method, as below, myself.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 10 Mar 2009 22:12:06 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Onyx Raven
> Sent: Tuesday, March 10, 2009 9:02 PM

> parameter format of using 'xoauth_' not used anymore?

As the person who suggested it in the first place, I would like us to stop using the xoauth_ prefix. The spec language actually allows using oauth_ for protocol extensions since technically, they are not server-specific if they are documented as standard extentions.

One of the benefits of the IETF process is that we can easily setup an IANA registry for people to register their extension parameters. This will remove the issue of parameter collision and will also encourage people to write specs for their extentions.

EHL