When I brought RFCs 7591, 7592, and 7662 up through the finalization process, I
learned that there are two camps out there on normative requirements in the
security considerations section. Some like them, as long as they don’t
contradict requirements/advice in previous sections, and some don’t
Adding some examples would probably be helpful, yes. Thanks. Some will
maybe be more possible/sensible than others (like I don't know what exactly
to show in an example of binding a refresh token) but I'll endeavor to add
some useful examples in a future revision.
On Tue, Feb 21, 2017 at 1:36
The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".
--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749=4945
--
Type: Editorial
A new meeting session request has just been submitted by Stephanie McCammon, on
behalf of the oauth working group.
-
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Stephanie McCammon
Number of
I *don't thin**k* it's normal to have normative text in the Security
Considerations, hence I support Samuel's position.
Let us look at the first MUST from RFC 6749 in the Security
Considerations section:
The authorization server*_MUST_ *authenticate the client_*whenever
possible*_.
