Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt

From: [email-masked]
Date: Sun, 9 May 2010 22:45:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Authentication Protocol Working Group of the IETF.

	Title           : The OAuth 2.0 Protocol
	Author(s)       : E. Hammer-Lahav, et al.
	Filename        : draft-ietf-oauth-v2-04.txt
	Pages           : 51
	Date            : 2010-05-09

This specification describes the OAuth 2.0 protocol.  OAuth provides
a method for making authenticated HTTP requests using a token - an
identifier used to denote an access grant with specific scope,
duration, and other attributes.  Tokens are issued to third-party
clients by an authorization server with the approval of the resource
owner.  OAuth defines multiple flows for obtaining a token to support
a wide range of client types and user experience.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-04.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.

---

From: Paul Madsen <[email-masked]>
Date: Mon, 10 May 2010 09:20:32 -0400

some feedback wrt the device flow

- 'verification URI' and 'authorization URI' are used interchangeably

- in the example messages, the verification code the client sends on its 
request for an access token is 'J2vC42OifV', not the same as that 
previously issued by the authorization server, namely '74tq5miHKB'

- in the following, 'provided by the client' might confuse, as it was 
the end-user that provided the code to the authorization server

    (F)  Assuming the end-user granted access, the authorization server
         validates the verification code provided by the client and
         responds back with the access token.

- the text 'The end-user manually types' and other similar would seem to 
unnecessarily preclude other possible mechanisms by which the 
verification URI and user code might be passed between client & 
user-agent ....

Related, is anybody thinking of a variant of the device flow where the 
user-agent sits on a device with QR-code capabilities, and so the user 
needn't type anything (uri or code)?

paul

On 5/10/2010 1:45 AM, [email-masked] wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 10 May 2010 11:03:00 -0700

> needn't type anything (uri or code)?

The end user will point their phone to the device screen and the phone
browser will take it from there? I think the device still needs to
show the URI and code as fallback, in case the user does not have a
smart phone, right?

Does the spec need to change in any way to support this? Isn't this
just a particular implementation?

Marius

---

From: Paul Madsen <[email-masked]>
Date: Tue, 11 May 2010 07:12:41 -0400

Yes that's the idea.

Where in the authorization server response would the QR code (or ref) 
go, especially if it also includes the uri & user code?

I don't see mention of an extensibility model by which additional params 
could be defined/added

On 5/10/2010 2:03 PM, Marius Scurtescu wrote:
> On Mon, May 10, 2010 at 6:20 AM, Paul Madsen<[email-masked]>  wrote:
>

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 11 May 2010 13:55:50 -0700

On Tue, May 11, 2010 at 4:12 AM, Paul Madsen <[email-masked]> wrote:
> Yes that's the idea.
>
> Where in the authorization server response would the QR code (or ref) go,
> especially if it also includes the uri & user code?

I don't know how QR codes are generated, but I was assuming that the
device can generate one without any help from the authz server, only
based on uri and code. That's not going to work?

Marius

---

From: Paul Madsen <[email-masked]>
Date: Tue, 11 May 2010 17:29:51 -0400

Hi Marius, I'm thinking the AS would create a 'dynamic' URI, embed it in 
a QR code and add it to the response to the client (perhaps as you say 
in addition to the raw URI & user code). There would be no user-code, as 
we would no longer be constrained by the user's short-term memory for 
strings

If (as you describe) the client creates the QR code from the 'raw' URI 
and user-code that the AS provided it, then there would need be 
sufficient OAuth smarts on the phone to reconstruct the URI and code 
from the QR code the client displayed

If, on the other hand, the AS creates the QR code from a URI it 
generates, then the phone need only launch a browser to load that URI.

paul

On 5/11/2010 4:55 PM, Marius Scurtescu wrote:
> On Tue, May 11, 2010 at 4:12 AM, Paul Madsen<[email-masked]>  wrote:
>    
>> Yes that's the idea.
>>
>> especially if it also includes the uri&  user code?
>>

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 11 May 2010 14:47:08 -0700

On Tue, May 11, 2010 at 2:29 PM, Paul Madsen <[email-masked]> wrote:
> Hi Marius, I'm thinking the AS would create a 'dynamic' URI, embed it in a
> QR code and add it to the response to the client (perhaps as you say in
> addition to the raw URI & user code). There would be no user-code, as we
> would no longer be constrained by the user's short-term memory for strings

I see, this would allow for a longer user code. Yes, an extension
would be needed for this case.

> If (as you describe) the client creates the QR code from the 'raw' URI and
> user-code that the AS provided it, then there would need be sufficient OAuth
> smarts on the phone to reconstruct the URI and code from the QR code the
> client displayed

The client can simply append the user code as a query parameter, so
the phone still deals with just a URL. But I guess the authz server
may or may not accept that (it could require a special param name for
the code or POST only).

> If, on the other hand, the AS creates the QR code from a URI it generates,
> then the phone need only launch a browser to load that URI.

Maybe we should start a thread about extensions. Sounds like a good
topic for next week :-)

Thanks for clarifying.

Marius

---

From: <[email-masked]>
Date: Wed, 12 May 2010 08:22:09 +0200

I suggest a change to 

"3.4.  Client Credentials

   When requesting access from the authorization server, the client
   identifies itself using a set of client credentials.  The client
   credentials include a client identifier and an OPTIONAL symmetric
   shared secret.  The means through which the client obtains these
   credentials are beyond the scope of this specification, but usually
   involve registration with the authorization server."

I don't like the "symmetric shared secret" and would like this to be
"beyond the scope of this spec".

I suggest to change that paragraph e.g. to:

"3.4.  Client Credentials

   When requesting access from the authorization server, the client
   authenticates itself using its credentials. The type of credentials
   is beyond the scope of this specification. The means through which 
   the client obtains these credentials are beyond the scope of this 
   specification, but usually involve registration with the 
   authorization server."

-Axel

Ps.
If the client has an e.g. RSA-keypair then it could use the private key
to sign the request and thereby authenticate itself.
The public key would need to be exchanged before out-of-band. Or it
could be a certificate that is e.g. issued by the authorization server
or a party that the authorization server trusts.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Monday, May 10, 2010 7:45 AM
To: [email-masked]
Cc: [email-masked]
Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Open Authentication Protocol Working
Group of the IETF.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 11 May 2010 23:25:10 -0700

But it is not beyond the scope. We define a parameter just for that called client_secret. If you want to use something else, you need to define an extension that replaces that with something else.

EHL

> Of [email-masked]
> Sent: Tuesday, May 11, 2010 11:22 PM
> To: [email-masked]
> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt
> 
> I suggest a change to
> 
> "3.4.  Client Credentials
> 
> I don't like the "symmetric shared secret" and would like this to be "beyond
> the scope of this spec".
> 
> If the client has an e.g. RSA-keypair then it could use the private key to sign
> the request and thereby authenticate itself.
> The public key would need to be exchanged before out-of-band. Or it could
> be a certificate that is e.g. issued by the authorization server or a party that
> the authorization server trusts.
> 
> This specification describes the OAuth 2.0 protocol.  OAuth provides a
> method for making authenticated HTTP requests using a token - an identifier
> used to denote an access grant with specific scope, duration, and other
> attributes.  Tokens are issued to third-party clients by an authorization server
> with the approval of the resource owner.  OAuth defines multiple flows for
> obtaining a token to support a wide range of client types and user
> experience.
> 
> implementation to automatically retrieve the ASCII version of the Internet-
> Draft.

---

From: David Recordon <[email-masked]>
Date: Tue, 11 May 2010 23:29:49 -0700

Yes, the Client authenticating using a RSA key pair seems like it
should be a different flow.

---

From: <[email-masked]>
Date: Wed, 12 May 2010 08:43:09 +0200

I would rename "client_secret" to "client_credential" and "secret_type"
to "credential_type". 
The client_credential might be a shared secret denoted by e.g.
"credential_type=shared_secret".

-Axel

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Wednesday, May 12, 2010 8:25 AM
To: Nennker, Axel; [email-masked]
Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt

But it is not beyond the scope. We define a parameter just for that
called client_secret. If you want to use something else, you need to
define an extension that replaces that with something else.

EHL

> I don't like the "symmetric shared secret" and would like this to be
"beyond
> The public key would need to be exchanged before out-of-band. Or it
could
directories.
> This draft is a work item of the Open Authentication Protocol Working
Group
> of the IETF.
Internet-

---

From: <[email-masked]>
Date: Wed, 12 May 2010 08:44:58 +0200

But that gives us a flow for each type of client credential.
I think it is better to talk about client_credentials and credential_type in flow that abstracts for credential types.

-Axel

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 11 May 2010 23:47:06 -0700

I wouldn't.

The fact is that the current spec provides a symmetric secret for authenticating clients. Extending this to use something else is trivial. Since this will be the majority of implementation (based on current deployment), I see no reason to make the spec harder to read and implement for something that is not even proposed.

EHL

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 11, 2010 11:43 PM
> To: Eran Hammer-Lahav; [email-masked]
> But it is not beyond the scope. We define a parameter just for that called
> client_secret. If you want to use something else, you need to define an
> extension that replaces that with something else.
> 
> EHL
>

---

From: <[email-masked]>
Date: Wed, 12 May 2010 10:50:23 +0200

I challenge the claim that the spec gets harder to read. In fact the
spec becomes cleaner if we move from one special case to a general
description.
Implementing other authn schemes while keeping the spec hardwired to
shared-secrets might be trivial but those implementations will always be
hacks.

I think that the proposed changes (client_secret -> client_credential,
secret_type -> credential_type) are simple and clear as can be.

Whether other autn schemes are proposed or not is not that relevant. 
I think that hardwiring "things" (authn schemes, digest algorithms) is
always a bad idea. A standard should be simple to implement while beeing
extensible without "hacks".

-Axel

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Wednesday, May 12, 2010 8:47 AM
To: Nennker, Axel; [email-masked]
Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-04.txt

I wouldn't.

The fact is that the current spec provides a symmetric secret for
authenticating clients. Extending this to use something else is trivial.
Since this will be the majority of implementation (based on current
deployment), I see no reason to make the spec harder to read and
implement for something that is not even proposed.

EHL

> But it is not beyond the scope. We define a parameter just for that
called
> > be a certificate that is e.g. issued by the authorization server or
a
> party that
a
> > with the approval of the resource owner.  OAuth defines multiple
flows
> for

---

From: Paul Madsen <[email-masked]>
Date: Wed, 12 May 2010 06:57:29 -0400

But client_secret is not defined specific to a given flow - its used by 
the web server, user name, and client credentials flows.

I can find no mention of the client using the client_secret for crypto 
authentication - the text of 5.3 'Crypto Tokens Requests' is very 
specific to clients authenticating their resource requests, not their 
requests to the AS.

Is the client_secret limited to be a bearer token?

This earlier message [1] of Eran's suggests that a crypto authentication 
was in scope at one point

"We are still very likely to have a PK-based method for obtaining 
*authorization* (a token)"

[1] - http://www.ietf.org/mail-archive/web/oauth/current/msg00654.html

On 5/12/2010 2:29 AM, David Recordon wrote:
> On Tue, May 11, 2010 at 11:25 PM, Eran Hammer-Lahav<[email-masked]>  wrote:
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 12 May 2010 08:44:43 -0700

There is a bit of confusion here.

We had clear consensus that the client credentials are only used to obtain a token, not to access protected resources. Some flows use just the client identifier, while others use both the identifier and shared secret. The assertion flow doesn't use it at all.

We had clear consensus that an asymmetric secret solution, whether it was for tokens or client credentials is out of scope. Adding support for a symmetric token secret using HMAC was the compromise, since many people consider the bearer token approach to be the most likely one to win wide adoption (I'm representing consensus, not necessarily agreeing with it).

Extensions are not hacks (unless they are poorly written). Profiles are not hacks. An extension saying: "instead of including the 'client_secret', include a 'signature' parameter with your request" isn't a hack.

We are still likely to see a PK-based solution in the form of an extension flow (for example, the client makes a request where the client identifier is a domain name and the request is signed using the client's private key; the server verifies the request by getting the client's public key from its host-meta document for the domain used in the client identifier). Such a PK solution can be a new flow or an extension to existing flows. Either way, it will be in a separate document.

We are also likely to see a PK-based solution for token secrets, similar to the OAuth RSA approach. However, it is far from clear which private key will be used to sign protected resources requests. The client's? A token-specific PK? Is this going to be a combination of a token flow and protected resource extension? I don't know because I don't have any actual use cases in mind right now. But the spec was written to make sure
It will not prevent this from being added later on.

The current client identifier and client secret are what we have wide consensus on. We are still discussing how to send these, but from the answers so far, there is enough support to keep the parameters in (with or without support for sending them using Basic as an alternative method).

EHL

> Of Paul Madsen
> Sent: Wednesday, May 12, 2010 3:57 AM
> To: [email-masked]
> But client_secret is not defined specific to a given flow - its used by the web
> server, user name, and client credentials flows.
> 
> authentication - the text of 5.3 'Crypto Tokens Requests' is very specific to
> clients authenticating their resource requests, not their requests to the AS.
> 
> This earlier message [1] of Eran's suggests that a crypto authentication was in
> scope at one point
> 
> >>> From: [email-masked] [mailto:[email-masked]] On
> >>> Behalf Of [email-masked]
> >>> If the client has an e.g. RSA-keypair then it could use the private
> >>> key to sign the request and thereby authenticate itself.
> >>> could be a certificate that is e.g. issued by the authorization
> >>> server or a party that the authorization server trusts.
> >>>
> >>> From: [email-masked] [mailto:[email-masked]] On
> >>> Behalf Of [email-masked]
> >>> owner.  OAuth defines multiple flows for obtaining a token to
> >>> support a wide range of client types and user experience.
> >>>
> >>> Internet- Draft.

---

From: Prateek Mishra <[email-masked]>
Date: Wed, 12 May 2010 12:39:15 -0400

Eran,

I want to support the idea of a minimal specification, that supports the 
basic use-case with no frills. Successful standards are usually small 
and with strong focus on a few key use-cases

But the specification does need to point to or document some 
extensibilty points. Otherwise, implementations will hard-wire the exact 
form of credential described in the specification and profiles will be 
viewed as alternatives not as variants. Instead, it would be good if 
implementations were somewhat "pluggable" with respect to the security 
credential exchanges between

1) client (SP) and authorization service
2) client (SP) and resource server

I realize this creates more work for the folks actually writing the 
specification (versus us lurkers) but it does increase the value of this 
effort by an order of magnitude.

I guess I should take an action to explain how this might be 
accomplished in  the present draft.

- prateek

>>> On Tue, May 11, 2010 at 11:25 PM, Eran Hammer-
>>>       
>> Lahav<[email-masked]>  wrote:
>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 12 May 2010 10:08:29 -0700

The spec should only directly enable extensibility where extensibility is a requirement/use case. For example, we know we are going to have more flows, so the spec should define the process to add new flows and register their 'type' value. Same with other HMAC algorithms.

However, making something extensible because it *might* be used in the future just makes the protocol more complicated for no gain. If someone has specific use cases around other client credentials, please share them so we can make sure they are either supported or enabled as an extension. But saying that we are sure to have other types of credentials so let's make sure the spec is ready for them is a no-starter.

Also, it's not a bad thing that extending the protocol is a bit of a challenge. Extensions, by definition, hurt interop. There should be some burden in extending to make people reconsider and try to work with what they have.

In other words, extensibility, like everything else, must be driven by use cases and requirements. We spent months discussing why we need signatures and ended up with good technical reasons and limited support to just those uses.

And this is truly *not* aimed at anyone in particular: I'm getting tired of people lecturing the group about what makes a good standard. There are plenty of examples of simple and complex, successful and failed standards out there. What makes a standard successful is what makes fashion successful - influential people (or companies) start using it. If you have a *technical* argument for or against a feature, please make it, but enough with the lectures about why we are here, what makes standards successful, and other theories.

EHL

> From: Prateek Mishra [mailto:[email-masked]]
> Sent: Wednesday, May 12, 2010 9:39 AM
> To: Eran Hammer-Lahav
> Cc: [email-masked]
> I want to support the idea of a minimal specification, that supports the basic
> use-case with no frills. Successful standards are usually small and with strong
> focus on a few key use-cases
> 
> But the specification does need to point to or document some extensibilty
> points. Otherwise, implementations will hard-wire the exact form of
> credential described in the specification and profiles will be viewed as
> alternatives not as variants. Instead, it would be good if implementations
> were somewhat "pluggable" with respect to the security credential
> exchanges between
> 
> 
> I realize this creates more work for the folks actually writing the specification
> (versus us lurkers) but it does increase the value of this effort by an order of
> magnitude.
> 
> I guess I should take an action to explain how this might be accomplished in
> the present draft.
> 
> - prateek
> 
> 
> > We had clear consensus that the client credentials are only used to obtain a
> token, not to access protected resources. Some flows use just the client
> identifier, while others use both the identifier and shared secret. The
> assertion flow doesn't use it at all.
> >
> > We had clear consensus that an asymmetric secret solution, whether it was
> for tokens or client credentials is out of scope. Adding support for a
> symmetric token secret using HMAC was the compromise, since many
> people consider the bearer token approach to be the most likely one to win
> wide adoption (I'm representing consensus, not necessarily agreeing with it).
> >
> > Extensions are not hacks (unless they are poorly written). Profiles are not
> hacks. An extension saying: "instead of including the 'client_secret', include a
> 'signature' parameter with your request" isn't a hack.
> >
> > We are still likely to see a PK-based solution in the form of an extension
> flow (for example, the client makes a request where the client identifier is a
> domain name and the request is signed using the client's private key; the
> server verifies the request by getting the client's public key from its host-
> meta document for the domain used in the client identifier). Such a PK
> solution can be a new flow or an extension to existing flows. Either way, it
> will be in a separate document.
> >
> > We are also likely to see a PK-based solution for token secrets,
> > similar to the OAuth RSA approach. However, it is far from clear which
> private key will be used to sign protected resources requests. The client's? A
> token-specific PK? Is this going to be a combination of a token flow and
> protected resource extension? I don't know because I don't have any actual
> use cases in mind right now. But the spec was written to make sure It will not
> prevent this from being added later on.
> >
> > The current client identifier and client secret are what we have wide
> consensus on. We are still discussing how to send these, but from the
> answers so far, there is enough support to keep the parameters in (with or
> without support for sending them using Basic as an alternative method).
> >
> > EHL
> >
> >
> >
> >> Behalf Of Paul Madsen
> >> But client_secret is not defined specific to a given flow - its used
> >> by the web server, user name, and client credentials flows.
> >>
> >> I can find no mention of the client using the client_secret for
> >> crypto authentication - the text of 5.3 'Crypto Tokens Requests' is
> >> very specific to clients authenticating their resource requests, not their
> requests to the AS.
> >>
> >> This earlier message [1] of Eran's suggests that a crypto
> >> authentication was in scope at one point
> >>
> >> [1] -
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg00654.html
> >>
> >> client_secret. If you want to use something else, you need to define
> >> an extension that replaces that with something else.
> >>
> >>>> EHL
> >>>>
> >>>>
> >>>>
> >>>>> I don't like the "symmetric shared secret" and would like this to
> >>>>> be "beyond the scope of this spec".
> >>>>>
> >>>>> If the client has an e.g. RSA-keypair then it could use the
> >>>>> private key to sign the request and thereby authenticate itself.
> >>>>> The public key would need to be exchanged before out-of-band. Or
> >>>>> it could be a certificate that is e.g. issued by the authorization
> >>>>> This specification describes the OAuth 2.0 protocol.  OAuth
> >>>>> provides a method for making authenticated HTTP requests using a
> >>>>> token - an identifier used to denote an access grant with specific
> >>>>> scope, duration, and other attributes.  Tokens are issued to
> >>>>> third-party clients by an authorization server with the approval
> >>>>> of the resource owner.  OAuth defines multiple flows for obtaining
> >>>>> a token to support a wide range of client types and user experience.
> >>>>>

---

From: Robert Sayre <[email-masked]>
Date: Wed, 12 May 2010 19:19:11 -0400

On Wed, May 12, 2010 at 1:08 PM, Eran Hammer-Lahav <[email-masked]> wrote:
>
> And this is truly *not* aimed at anyone in particular: I'm getting tired of people lecturing the group about what makes a good standard.

Oh, I wouldn't expect it to stop. The group has a bunch of unrelated
stuff grouped into one document. There seems to be consensus to do
that, but it still runs counter to the conventional wisdom.

> What makes a standard successful is what makes fashion successful - influential people (or companies) start using it.

You mean like SOAP?

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 12 May 2010 16:37:23 -0700

> From: Robert Sayre [mailto:[email-masked]]
> Sent: Wednesday, May 12, 2010 4:19 PM
> To: Eran Hammer-Lahav
> Cc: Prateek Mishra; [email-masked]
> > And this is truly *not* aimed at anyone in particular: I'm getting tired of
> people lecturing the group about what makes a good standard.
> 
> Oh, I wouldn't expect it to stop. The group has a bunch of unrelated stuff
> grouped into one document. There seems to be consensus to do that, but it
> still runs counter to the conventional wisdom.

Can you point to specific parts that should not be grouped together?

EHL

---

From: Robert Sayre <[email-masked]>
Date: Wed, 12 May 2010 20:41:25 -0400

> Can you point to specific parts that should not be grouped together?

Sure, to give one example, I would make the device flow a separate
spec immediately. That seems only distantly related to other things in
the spec, and may not be really necessary by the time the standard
matures.

I mean, Facebook engineers have already said they felt comfortable
shipping certain pieces of the spec because they seem stable. Why
isn't the group hammering out nits in those pieces, writing test
suites, and declaring victory? You can always add more later.

Anyway, I've said my piece on this point quite enough. Many new
readers will probably bring it up, though. That shouldn't be
surprising.

-- 

Robert Sayre

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 13 May 2010 12:12:04 +0200

Am 13.05.2010 02:41, schrieb Robert Sayre:
> On Wed, May 12, 2010 at 7:37 PM, Eran Hammer-Lahav<[email-masked]>  wrote:
>    
>>      

Why does this hold for the device flow and not for other flows? For us 
(Deutsche Telekom), the device flow is one of the most important pieces 
of the spec since we want to use OAuth for a variety of autonomous 
devices with limited input capabilities (Set Top Boxes, TV Sets, 
handsets, ....).

regards,
Torsten.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 13 May 2010 19:56:13 -0400

On Thu, May 13, 2010 at 6:12 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> (Deutsche Telekom), the device flow is one of the most important pieces of
> the spec since we want to use OAuth for a variety of autonomous devices with
> limited input capabilities (Set Top Boxes, TV Sets, handsets, ....).

I'm not saying the use case is invalid. Are you saying Deutsche
Telekom can't implement the device flow if it is not finalized at
precisely the same time as the other parts of OAuth?

-- 

Robert Sayre