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*_.
This sentence is incorrect. The right sentence should be :
The authorization server*should *authenticate the client whenever possible.
RFC 6749 is not an example to follow.
Denis
I do think it's normal to have normative text in the Security
Considerations. RFC6749 has a lengthy Security Considerations section
<https://tools.ietf.org/html/rfc6749#section-10> with a lot of
normative text.
Think of it this way: Sections 4 to 7 describe how to use native app
URI schemes to perform OAuth flows from the app to browser and back.
If you only read those sections, you could have a functioning (but
potentially insecure) OAuth flow in a native app. The security section
adds some security requirements and clarifications for implementing
Sections 4-7, like using PKCE, and more.
Reviewing sub-section by sub-section:
8.1 Definitely belongs here, as the the whole BCP is about native-app
URI schemes, whereas doing OAuth in a WebView doesn't need those (as
the client can just pluck out the code from any redirect URI)
8.2 Requires that servers who want to follow the native apps BCP
support PKCE, and recommends that they reject requests from clients
who don't. This *could* be in the main doc, but since PKCE is an
existing thing, and is purely additive from a security perspective, I
think this reference works fine. Originally I talked about PKCE more
in the doc body, but some reviewers thought it was then a little
duplicative of the PKCE doc itself.
8.3 This reads like classic security considerations to me, clarifying
some details of 7.3
8.4 Part of this reads a little new-ish, regarding distinguishing
native clients from web ones. But on review, I think could just be
re-worded to reference RFC6749 Section 2.1.
8.5 This one belongs where it is since the body of the BCP is talking
about the code flow.
8.6 Totally belongs.
8.7 to 8.11 belong IMO, they are security clarifications of
long-standing topics.
My methodology when reviewing this was: is the text introducing a new
topic directly related to native apps or sections 4-7, or does it
discuss an old security topic in the context of native apps, or add
security related discussions of the content in 4-7. Of all those, I
really only see a bit of new topic related to native apps in 8.4, and
in actual fact it that sub-section should probably be reworded since
RFC6749 already establishes the public client type, which native apps
are and a reference would be more appropriate (which would reduce it
to just clarifying an old topic).
What do you think of this analysis? Do you have any specific sections
or text you feel are better suited in the document body? I will take
an action item to revise section 8.4.
On Mon, Feb 20, 2017 at 9:57 PM, Samuel Erdtman <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I just had a question on best practice. In this document a large
part of the normative text is located under Security Considerations.
I had previously seen Security Considerations as things to think
about when implementing not so much as MUSTs and MUST NOTs.
I think it is okay to have it this way but it surprised me a bit
and wanted to ask if there is any best practice for the Security
Considerations section saying what type of information it should
include.
Best Regards
Samuel Erdtman
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
