Subject: Re: [OAUTH-WG] AD Review of -22 (part II)

From: Eran Hammer <[email-masked]>
Date: Fri, 20 Jan 2012 18:04:17 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stephen Farrell
> Sent: Thursday, October 13, 2011 10:13 AM

> Suggested non-trivial clarifications:
> -------------------------------------
> 
> (1) 1.3.4 - "previously arranged" might trigger discusses on the document
> since it implies that this spec might not be suited for broad use. I think that
> making it clear that the normal mode for client developers is to work against
> an existing service (AS and resource server) would help to clarify that such
> arrangements are ok here.

Added new 'Interoperability' section to the introduction:

          OAuth 2.0 provides a rich authorization framework with well-defined security properties.
          However, as a rich and highly extensible framework with many optional components, this
          specification is likely to produce a wide range of non-interoperable implementations.
          In addition, this specification leaves a few required components partially or fully
          undefined (e.g. client registration, authorization server capabilities, endpoint
          discovery).

          This protocol was design with the clear expectation that future work will define
          prescriptive profiles and extensions necessary to achieve full web-scale
          interoperability.          

There is no way to sugar coat reality and hopefully by being blunt about it upfront, we will avoid a prolonged debate about the protocol's failings in that regard.

> (2) p11, in step (F) is there a way to distinguish between an access token that
> is invalid due to expiry vs. e.g. data corruption? Section 6 refers to 5.2 for the
> error codes but its not clear to me which one is returned for this case. I think
> clarifying that in section 6 or 5.2 is needed.

That depends on the token specification. Steps C-F are outside the scope of this document. I'll note that.
 
> (3) p13, 2.2 and 2.3 - these things happens at registration time right? I think
> making that clear is needed since we don't specify a registration protocol
> here.

The entire section 2 is 'Client Registration' which is described as out of scope for implementation details.
 
> (4) 2.3.1 uses the term "token endpoint" without definition (its defined in
> section 3) and in particular without making it clear if both access and refresh
> token issuance is covered (I guess it is).

Changed to 'when sending requests using password authentication'.

> (5) The same text about x-www-form-urlencoded is repeated various times,
> it'd be better to do that once and refer to it where necessary.

Not enough to be worth the change.

> (6) 3.1.2.2 states the rules for when AS'es are to require registration of
> redirection URIs. I think you need to clarify that some. First, you use the term
> "redirection_uri" for both a "complete" URI and for a scheme/authority/path
> triple that can be added to via a query component which is confusing.
> Second, its overall a very complex rule with a MUST, two MAYs and 3
> SHOULDs.  I do think it could be made clearer by putting the MUST up front
> and separating issues related to complete URI and triples separately from the
> when something MUST be registered.

New text:

   The authorization server MUST require the following clients to
   register their redirection endpoint:

   o  Public clients.
   o  Confidential clients utilizing the implicit grant type.

   The authorization server SHOULD require all clients to register their
   redirection endpoint prior to utilizing the authorization endpoint

   The authorization server SHOULD require the client to provide the
   complete redirection URI (the client MAY use the "state" request
   parameter to achieve per-request customization).  If requiring the
   registration of the complete redirection URI is not possible, the
   authorization server SHOULD require the registration of the URI
   scheme, authority, and path (allowing the client to dynamically vary
   only the query component of the redirection URI when requesting
   authorization).

   The authorization server MAY allow the client to register multiple
   redirection endpoints.

   Lack of a redirection URI registration requirement can enable an
   attacker to use the authorization endpoint as open redirector as
   described in Section 10.15.

> (7) 4.2.1 and elsewhere - refers back to 3.1.2 for the way in which the
> redirection-uri is OPTIONAL - I'm not sure that's sufficiently clear, 3.1.2 is
> quite long and discusses a bunch of things - couldn't it be made clearer when
> the messages are defined?

The reference is not for the OPTIONAL definition. I changed the coma to a period.

>  More generally, is there no way to avoid the
> extensive cross-referencing in the message field definitions? E.g. 4.2.2 has
> references to 7.1 and 3.3, and others are similar. Organizing the text for the
> benefit of the reader is a good thing so would it be worthwhile to do an
> editing pass for just this purpose - to reduce the number of forward
> references and minimize the number of pointers in general?

We've gone back and forth on this for 22 drafts and this is the best balance between readability and consistency we found. I'm inclined to avoid another reshuffle.

> On a similar note, 4.1 & 4.2 call out specific errors, but 4.3 defers to 5.2, why?
> Be good if that could be made more consistent at the TOC level.

Because 4.3 doesn't use the authorization endpoint.

> (8) How can the AS protect against brute force attacks in 4.3.2?  I think you
> could give a bit more guidance, e.g. say to rate-limit or generate alerts or
> whatever, but not as normative text, just good hints.

Ok.

> (9) In 10.12 you say how a client can protect against CSRF via the state field
> but you don't say how the AS can do the same in order to satisfy the MUST in
> the last para of 10.12.  Can you not add a hint or reference here?

The WG sentiment was that server developers do not require as much hand holding as the client developers. If the authors of the original text want to propose text, I'm happy to include it.

> 
> Some nits: (Stuff that seemed more serious at first:-)
> ---------
> 
> (1) In 2.3.1 I think you're ruling out putting the client_id and client_secret in
> the request URL - is that right? If so, that's good, but I think it needs calling
> out since people do that all the time and it'd be good to say why its bad to do
> that.

Added:

           The parameters can only be transmitted in the request body and MUST NOT be included in the
            request URI

> (2) The redirection endpoint is introduced in 3.2.1 but is not listed at the start
> of section 3 which only lists two endpoints.

I think you mean 3.1.2. Added.

> (3) In 4.1.2 what does it mean to "attempt" to revoke tokens?  Why can't the
> AS just revoke them? (Where revoke == not accept them when they are
> next presented, right?)

Can't revoke self-encoded tokens (e.g. stateless on the server). Changed 'attempt' to 'when possible'

> (4) I think this is just language but wanna check. 4.1.2.1 and
> 4.2.2.1 errors have a state field. Text says: "If a valid "state"
> parameter was present..." which would imply that state variables are either
> valid or invalid according to the AS. I don't think that's the case, and nor
> should it be. (If it were, I'd have a security concern that I could use otherwise
> crap requests to probe for good state values.) s/valid// I think?

Yep.
 
> (5) I don't get the benefit of saying the client SHOULD ignore unknown fields
> in the response in 4.2.2 - what's effectively the difference between that and
> "MUST ignore" - I don't get it, and hence don't see why you don't say MUST
> ignore.

Changed all 'ignore' to MUST.
 
> (6) Why say "MUST NOT issue a refresh token" in 4.2.2? Are you making an
> assumption that access & refresh tokens are distinguishable to anyone other
> than the issuer? If not, then is this just saying "don't make a mistake"?

No. It's a security concern that developer might decide to be flexible and provider a refresh token in addition to an access token using this flow.

> (7) 5.1 says that the client SHOULD ignore "unrecognized response
> parameters" - does that mean unrecognized parameters in the JSON entity
> body? Is it clear enough as-is that those are "response parameters"?

Changed 'parameters' to 'value names in the response'.

> (8) How does the use of TLS on endpoints used for end-user interaction
> "reduce the risk of phishing attacks"? I don't get that. Maybe you mean that
> TLS+users actually checking server identity reduces the risk of successful
> phishes? I think that's a bit different. (I do like the MUST though.)

Dropped 'phishing'. If the authors of the original text would like to explain, I'll put it back in.

(To be continued...)

EHL

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 21 Jan 2012 01:11:37 +0000

Same response as for part I from me,

S

On 01/21/2012 01:04 AM, Eran Hammer wrote:
>> On a similar note, 4.1&  4.2 call out specific errors, but 4.3 defers to 5.2, why?
>> assumption that access&  refresh tokens are distinguishable to anyone other

---

From: Justin Richer <[email-masked]>
Date: Thu, 26 Jan 2012 09:06:38 -0500

I realize that -23 is already published with the below text, but since 
this is a whole new section and nobody else seemed to bring it up, I 
wanted to make sure it wasn't missed by the WG.

> There is no way to sugar coat reality and hopefully by being blunt about it upfront, we will avoid a prolonged debate about the protocol's failings in that regard.
I think it's a good idea to call it out, and I don't want to "sugarcoat" 
it either, but the phrase "this specification is likely to produce a 
wide range of non-interoperable implementations" is a bit overdramatic 
in its tone. Instead, I think we should point to other documents that 
are being developed explicitly along side of this, such as at the 
beginning of RFC2904 (http://tools.ietf.org/html/rfc2904). I suggest 
text like the following instead:

    OAuth 2.0 provides a rich authorization framework with well-defined
    security properties. However, as a rich and highly extensible
    framework with many optional components, this specification does not
    seek to define all components needed for a fully interoperable
    deployment within this document. Instead, this specification is
    intended to work with complimentary documents that define token
    types [MAC] [Bearer], token formats [JWT] [SAML], client
    registration [Dynamic Reg?], endpoint discovery [XRD] [SWD], and
    other considerations.

    This protocol was designed with the clear expectation that future
    work will define prescriptive profiles and extensions necessary to
    achieve full web-scale interoperability.

  -- Justin

---

From: John Bradley <[email-masked]>
Date: Thu, 26 Jan 2012 11:11:15 -0300

Yes Justin's rewording makes it sound less like non-interoperability is a desired outcome.

On 2012-01-26, at 11:06 AM, Justin Richer wrote:

> I realize that -23 is already published with the below text, but since this is a whole new section and nobody else seemed to bring it up, I wanted to make sure it wasn't missed by the WG.
> 
> I think it's a good idea to call it out, and I don't want to "sugarcoat" it either, but the phrase "this specification is likely to produce a wide range of non-interoperable implementations" is a bit overdramatic in its tone. Instead, I think we should point to other documents that are being developed explicitly along side of this, such as at the beginning of RFC2904 (http://tools.ietf.org/html/rfc2904). I suggest text like the following instead:
> 
> OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, this specification does not seek to define all components needed for a fully interoperable deployment within this document. Instead, this specification is intended to work with complimentary documents that define token types [MAC] [Bearer], token formats [JWT] [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD], and other considerations.
> This protocol was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.
> 
> 
>  -- Justin
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer <[email-masked]>
Date: Thu, 26 Jan 2012 10:49:44 -0700

> From: Justin Richer [mailto:[email-masked]]
> Sent: Thursday, January 26, 2012 6:07 AM
> To: Eran Hammer
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] AD Review of -22 (part II)
> 
> I realize that -23 is already published with the below text, but since this is a
> whole new section and nobody else seemed to bring it up, I wanted to make
> sure it wasn't missed by the WG.

> I think it's a good idea to call it out, and I don't want to "sugarcoat" it either,
> but the phrase "this specification is likely to produce a wide range of non-
> interoperable implementations" is a bit overdramatic in its tone. Instead, I
> think we should point to other documents that are being developed explicitly
> along side of this, such as at the beginning of RFC2904
> (http://tools.ietf.org/html/rfc2904). I suggest text like the following instead:
>
> OAuth 2.0 provides a rich authorization framework with well-defined security
> properties. However, as a rich and highly extensible framework with many
> optional components, this specification does not seek to define all
> components needed for a fully interoperable deployment within this
> document. Instead, this specification is intended to work with complimentary
> documents that define token types [MAC] [Bearer], token formats [JWT]
> [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD],
> and other considerations.
> This protocol was designed with the clear expectation that future work will
> define prescriptive profiles and extensions necessary to achieve full web-
> scale interoperability.

This does sugarcoat the fact that 2.0 does not provide *any* guaranteed interoperability. The implementations I've seen so far have simply adopted a *profile* of this document along with bearer tokens. We've already seen feedback on this list where client developers were surprised and frustrated with such implementations when trying to reuse code across providers and this is only going to get more noticeable. And then of course we have the insane complexity of the over-architected solutions, adding layer after layer to solve problems that are as simple as making a parameter required and well specified.

We've also seen questions about providers looking to claim OAuth 2.0 support while maintaining all their existing architecture and security properties, seeking to push the boundaries of what is permitted by the specification. We've gone to a place where *anything* can be made to look like OAuth. We've seen implementations doing nothing but exchanging SAML assertions for JSON-formatted assertions (or other SAML assertions), without any actual resource owner participation, calling itself OAuth. And sadly, it can.

I'm against adding such a laundry list of references. I am also opposed to implying that using these extensions will achieve interoperability because they will not in their current state. The only way to achieve interoperability at this point is by getting rid of most of the optional components (removed or made required), and tightening the definition of others. Or alternatively, come out with a full blown discovery and negotiation protocol - something that would be extremely premature at this point. How can you design a good discovery/negotiation protocol before you have even a partial picture of what it is you want to discovery/negotiate.

Instead, I proposing a small tweak (marked with [[ ]]) to the language:

---
1.7.  Interoperability

   OAuth 2.0 provides a rich authorization framework with well-defined
   security properties.  However, as a rich and highly extensible
   framework with many optional components, [[ on its own, ]] this specification is likely
   to produce a wide range of non-interoperable implementations.  In
   addition, this specification leaves a few required components
   partially or fully undefined (e.g. client registration, authorization
   server capabilities, endpoint discovery).

   This protocol was designed with the clear expectation that future work
   will define prescriptive profiles and extensions necessary to achieve
   full web-scale interoperability.
---

I can appreciate feeling a little sting from such a disclaimer but we all deserve it for failing to do our job. We took on a successful, simple, narrow, and useful protocol and turned it into mush because after more than 2 years we have failed to find common ground on almost anything that is required to achieve interoperability. Instead we now rely on popular providers such as Facebook and Twitter to set the tone for the rest of the industry, filling in the gaps.

My personal frustration is from the fact that a significant number of working group members put the interest of their corporate overlord above what is good for the web. They have aggressively promoted an agenda based on product lines already in advance stages of development and refused to compromise if that meant making changes to their products. We have produced the closest heir to WS-* I've seen in many years, and that's nothing to be proud of.

The result is pretty obvious: claiming OAuth 2.0 support or even compliance is meaningless. It's the difference between dancing the tango and dancing to rock music. One gives you a beautifully synced performance while the other put personal expression on a pedestal. Which one do you think is better for a web protocol?

It's time to own the results of our work and to clearly state that this is the best we were able to produce, and let the industry take over and solve through running code the problems we were too fragmented to solve here.

EHL

---

From: Phil Hunt <[email-masked]>
Date: Thu, 26 Jan 2012 10:15:51 -0800

If an app developer writes their own client, than their OAuth code becomes bound in with the code connecting to the underlying resource API which may or may not be standardized.  Regardless the tight coupling of OAuth plus an API can only be inter-operable in that specific combination.

This will be mitigated through the eventual emergence of client toolkits which keep the resource API and the authorization API cleanly separated. This may lead to further specs and refinements to OAuth2 down the road. But we don't have enough data for that today.

IMHO I think for RESTful services, fuzzy interoperability is the nature of the technology for now because of its other benefits.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Thu, 26 Jan 2012 16:21:08 -0500

I really don't see it this way, as a failure. Instead, I think we've 
managed to successfully scope the document to address important 
practices and bits of the protocol that will work in tandem with other 
documents to solve different use cases. One of the biggest problems that 
we saw coming in from OAuth1.0 was that it tried to be all things to all 
people all at once, which also didn't help interoperability. I think 
that what we have is a more composable UNIXy approach here. Namely, 
OAuth 2 core/framework/whatever does one thing and does it well: it 
outlines a standard means and structure for getting a token. Does that 
help you use the token against a web service, do service discovery, pack 
information into the token itself? No, but it wasn't meant to. It was 
meant to leave enough space for other docs to take care of that.

But I do not think that it's gone so far as to leave a morass of 
unusable components, much in the way that WS-* did, and I don't think 
the comparison is a fair one. I think the separations are clean and the 
usage profiles are clear.

By pointing developers to other specifications, most of which are 
products of this very working group or members of this working group 
under other umbrellas, we *can* provide a wider view of the world. At 
the absolute least, I think it needs to point to the two token type 
docs, and I'd suggest at least keeping the two token format docs as 
well. And as was pointed out by Phil Hunt, this notion of loosely 
coupled specs and components is actually *beneficial* to today's web 
environment. This is another way that this work differs from WS-*: if 
you're doing one part of WS-*, you're not going to get away without 
doing the rest of it too if you want to have a working system. As you 
point out, and somewhat lament, this is not the case with OAuth 2. You 
can do some parts, and not others, and utalize just the bits that you 
need. The fact that I can use the same endpoints and mechanisms for 
user-delegated auth and machine-directed auth is very powerful, and the 
fact that I can use the same exact client libraries to fetch and use 
both random-hex tokens and signed JWTs is equally powerful. The fact 
that I can reuse 90% of that code and also get signed MAC tokens is 
likewise powerful.

Thus, I stand by my originally-suggested text and respectfully submit it 
to the editor and working group for consideration of inclusion in this 
section.

  -- Justin

---

From: Eran Hammer <[email-masked]>
Date: Thu, 26 Jan 2012 15:12:44 -0700

The specification already has informative references to the two token
types. From purely practical standpoint, I am not adding any more
references because that creates more dependencies and longer wait time.

There is nothing factually incorrect about the current text. It already
makes it clear that additional work is required and expected. It is also a
fact that it will produce a wide range an non-interoperable
implementations unlike, say, HTTP. We have to make this clear to the
reader upfront because every reader outside this WG has exactly the
opposite expectation, especially coming from 1.0.

I'll make the small tweak proposed below before this goes to the RFC
editor, but am not making any other changes to the text unless you can
show it is factually incorrect or incomplete.

EHL

On 1/26/12 1:21 PM, "Justin Richer" <[email-masked]> wrote:

>>>this is a
>>>security
>>>will
>> This does sugarcoat the fact that 2.0 does not provide *any* guaranteed
>>interoperability. The implementations I've seen so far have simply
>>adopted a *profile* of this document along with bearer tokens. We've
>>already seen feedback on this list where client developers were
>>surprised and frustrated with such implementations when trying to reuse
>>code across providers and this is only going to get more noticeable. And
>>then of course we have the insane complexity of the over-architected
>>solutions, adding layer after layer to solve problems that are as simple
>>as making a parameter required and well specified.
>>
>> We've also seen questions about providers looking to claim OAuth 2.0
>>support while maintaining all their existing architecture and security
>>properties, seeking to push the boundaries of what is permitted by the
>>specification. We've gone to a place where *anything* can be made to
>>look like OAuth. We've seen implementations doing nothing but exchanging
>>SAML assertions for JSON-formatted assertions (or other SAML
>>assertions), without any actual resource owner participation, calling
>>itself OAuth. And sadly, it can.
>>
>> I'm against adding such a laundry list of references. I am also opposed
>>to implying that using these extensions will achieve interoperability
>>because they will not in their current state. The only way to achieve
>>interoperability at this point is by getting rid of most of the optional
>>components (removed or made required), and tightening the definition of
>>others. Or alternatively, come out with a full blown discovery and
>>negotiation protocol - something that would be extremely premature at
>>this point. How can you design a good discovery/negotiation protocol
>>before you have even a partial picture of what it is you want to
>>discovery/negotiate.
>>
>>work
>> I can appreciate feeling a little sting from such a disclaimer but we
>>all deserve it for failing to do our job. We took on a successful,
>>simple, narrow, and useful protocol and turned it into mush because
>>after more than 2 years we have failed to find common ground on almost
>>anything that is required to achieve interoperability. Instead we now
>>rely on popular providers such as Facebook and Twitter to set the tone
>>for the rest of the industry, filling in the gaps.
>>
>> My personal frustration is from the fact that a significant number of
>>working group members put the interest of their corporate overlord above
>>what is good for the web. They have aggressively promoted an agenda
>>based on product lines already in advance stages of development and
>>refused to compromise if that meant making changes to their products. We
>>have produced the closest heir to WS-* I've seen in many years, and
>>that's nothing to be proud of.
>>
>> The result is pretty obvious: claiming OAuth 2.0 support or even
>>compliance is meaningless. It's the difference between dancing the tango
>>and dancing to rock music. One gives you a beautifully synced
>>performance while the other put personal expression on a pedestal. Which
>>one do you think is better for a web protocol?
>>
>> It's time to own the results of our work and to clearly state that this
>>is the best we were able to produce, and let the industry take over and
>>solve through running code the problems we were too fragmented to solve
>>here.
>>
>> EHL
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

---

From: agks mehx <[email-masked]>
Date: Sun, 29 Jan 2012 19:19:46 +0700

I would be unhappy if things were sugarcoated any further.  This is
definitely a rare specification where OPTIONAL parameters in the API can be
REQUIRED by a conforming implmentation (as I discussed in my note on the
scope parameter for which the proposed modification does not really change
much)

I appreciate that there is a cautionary statement that this specification
may produce non-interoperable client / server implementations, as I
discovered upon writing my first client.

The cautionary statement would be invaluable to programmers in the wild who
are not used to the unusual semantics of this particular specification.

Hence I strongly support (if it counts) keeping the language the way Eran
Hammer has suggested.