[oauth] draft-dehora-farrell-oauth-accesstoken-creds-00.txt and OAUTH Extensions in the Charter

["Hannes Tschofenig" <[e-mail]>]

Stephen ask me how their document
draft-dehora-farrell-oauth-accesstoken-creds-00.txt is reflected in the
charter text. 

Independent of this particular document, I believe that we should focus our
initial efforts on the Base OAUTH specification rather than working on
extensions. As such, I would say that (depending on the progress of the work
with the main specification) we should discuss extensions in the summer
timeframe. 

Regarding this specific extension: I read through
draft-dehora-farrell-oauth-accesstoken-creds-00.txt and wanted to make sure
that I understood the extension correctly. Here is a message flow that Jeff
created some time ago. This document suggests to skip the message exchanges
marked as (2.*). This means that the redirect from the Service Provider to
the Customer and the subsequent steps of user authentication and
authorization are replaced with the ability to carry some username/password
in the Access token when the Consumer sends the request to the Service
Provider. 

                                            photos.example.net
                                              +----------+
                                              |          |
                                              | OAuth    |
                    printer.example.com       | Service  |
                        +--------+            | Provider |
                        |        |            |          |
                        | OAuth  |            |[protected|
                        |Consumer|            |resources]|
  +----+                |        |            |          |
  | UA |                |  [RP]  |            |   [SP]   |
  +-+--+                +---+----+            +----+-----+
    |                       |                      |
    | 1.0. User Agent inter-|                      |
    | acts with Consumer    |                      |
    | site [optional]       |                      |
    |<--------------------->|                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 1.1. UA informs/directs                      |
    | Consumer to do something                     |
    | with a resource (photo)                      |
    | at SP                 |                      |
    |---------------------->|                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    |                       | 1.2. Consumer attempts
    |                       | accessing photo at SP|
    |                       |--------------------->|
    |                       |                      |
    |                       |                      |
    |                       | 1.3. SP replies with |
    |                       | a HTTP 401 containing|
    |                       | a "OAuth" www-authn  |
    |                       | header field         |
    |                       |<---------------------|
    |                       |                      |
    |                       |                      |
    |                       | 1.4. Consumer replies|
    |                       | with a request for   |
    |                       | "unauthorized Request|
    |                       | Token" (uRT) via POST|
    |                       | to SP's "request token
    |                       | URL"                 |
    |                       |--------------------->|
    |                       |                      |
    |                       |                      |
    |                       | 1.5. SP issues uRT & |
    |                       | token secret to      |
    |                       | Consumer.            |
    |                       |<---------------------|
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 2.0. Consumer redirects                      |
    | UA to SP "User Author-|                      |
    | ization URL" including|                      |
    | the uRT.              |                      |
  +<- - - - - - - - - - - - |                      |
  . | (indirected via UA)   |                      |
  . |                       |                      |
  +-------------------------+--------------------->|
    |                       |                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 2.2. User authenticates with the Service     |
    | Provider (optional methods vary, realization |
    | is out of scope)                             |
    |<============================================>|
    | 2.3. User grants or declines permission      |
    | for the Service Provider allow Consumer      |
    | access to the resource (photo).              |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 2.4. If permision granted, UA redirected back|
    | to Consumer's "Callback URL", conveying the  |
    | uRT.                  |                      |
  +<- - - - - - - - - - - - - - - - - - - - - - - -|
  . | (indirected via UA)   |                      |
  . |                       |                      |
  . |                       |                      |
  +------------------------>|                      |
    |                       |                      |
    |                       |                      |
    |                       |3.0. Consumer requests|
    |                       |Access token, supplies|
    |                       |uRT.                  |
    |                       |--------------------->|
    |                       |                      |
    |                       |                      |
    |                       |                      |
    |                       |3.1. SP grants Access |
    |                       | Token.               |
    |                       |<---------------------|
    |                       |                      |
    |                       |                      |
    |                       |4.x. Consumer uses the|
    |                       |Access Token, Access  |
    |                       |Token Secret, Consumer|
    |                       |Key, and Consumer Secret
    |                       |to make authenticated |
    |                       |request(s) to the Service
    |                       |Provider.             |
    |                       |=====================>|
    |                       |           .          |
    |                       |           .          |
    |                       |           .          |
    |                       |                      |


My personal view is that this goes a bit against the OAUTH idea. Unless the
username/password is again created using some other mechanism (which the
document does not describe) then there are vulnerability that OAUTH was
initially meant to deal with. Additionally, the result is less likely to be
easy to deploy. 

As a justification for the work the following argument is provided: "HTTP
redirection to a browser is unavailable or unsuitable, such as intermediary
aggregators and mobile or settop devices." I wonder whether this is really a
problem in today's mobile devices to justify this optimization. 

Maybe I just didn't capture the idea properly.  

Ciao
Hannes