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.
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.
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
