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
On 01/26/2012 12:49 PM, Eran Hammer wrote:
-----Original Message-----
From: Justin Richer [mailto:jric...@mitre.org]
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
