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. > >>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
