Re: [OAUTH-WG] review draft-ietf-oauth-native-apps-07

[Samuel Erdtman <[e-mail]>]

Thanks Denis!

On Fri, Mar 3, 2017 at 7:37 AM, William Denniss <[e-mail]> wrote:

> Thanks all for the great discussion. I tweaked the discussion on
> public/confidential clients to rely more on the OAuth2 definition (it was a
> bit duplicative), and I reordered the security considerations so it flows
> better, but have kept the normative language for now. Let's see how it pans
> out during the finalization process.
>
> On Mon, Feb 27, 2017 at 8:47 AM, Samuel Erdtman <[e-mail]> wrote:
>
>> Thanks for the replies.
>>
>> If there are no formal guidelines from IETF I think we should just
>> proceed it is a good and informative spec, it was just to me it felt
>> slightly of.
>>
>> Based on the conversation I have no objections taking this draft to RFC.
>>
>> //Samuel
>>
>> On Wed, Feb 22, 2017 at 12:09 AM, Justin Richer <[e-mail]> wrote:
>>
>>> 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 like them, preferring all normative material be in the “body” of
>>> the spec itself. I was given the impression that it was more of a stylistic
>>> choice than anything, but I can only speak from my personal experience.
>>>
>>>  — Justin
>>>
>>> On Feb 21, 2017, at 3:17 PM, William Denniss <[e-mail]>
>>> wrote:
>>>
>>> The only real requirement in that section I guess is the use of PKCE
>>> (8.2).  That requirement could be moved to the body of the doc, while
>>> keeping the longer discussing around code interception in the security
>>> considerations.  To me the remaining text are indeed security best
>>> practices / clarifications.
>>>
>>> Other OAuth WG RFCs have requirement level capitalization in the
>>> Security Section like RFC7591. I always assumed these were best-practice
>>> security requirements. But if the style is really not to do this, the
>>> requirement level capitalization could be dropped from that section in the
>>> native apps BCP.
>>>
>>> On Tue, Feb 21, 2017 at 12:50 AM, Denis <[e-mail]> wrote:
>>>
>>>>
>>>> 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 <[e-mail]>
>>>> 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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>