Subject: [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10

From: wangzitao <[email-masked]>
Date: Mon, 22 May 2017 03:05:04 +0000

Reviewer: Zitao Wang (Michael)

Review result: Has Nits

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Document reviewed:  draft-ietf-oauth-native-apps-10

Summary:

OAuth 2.0 authorization requests from native apps should only be made
through external user-agents, primarily the user's browser. This
specification details the security and usability reasons why this is
the case, and how native apps and authorization servers can implement

this best practice.

I think the document is written very clear, except some small nits:

Page 3:     The last sentence of introduction-- "This practice is also known as the AppAuth pattern".

I suggest adding a reference to explain the AppAuth pattern.

Page 3:     Terminology -- "OAuth".

I suggest modifying to: "OAuth"   The Web Authorization (OAuth) protocol.  In this document, OAuth refers to OAuth 2.0 [RFC6749].

Page 4:     Terminology -- "web-view"  A web browser UI component.

Does it mean "User Information"?  Suggest expanding this abbreviation.

Page 5:     Figure 1.   Does the browser and authorization endpoint are some kinds of "external user-agent"? Suggest describing it more clearly.

Page   9:   PKCE [RFC7636] details how this limitation can be used to execute a code interception attack (see Figure 1).

Does the Figure 1 means "Figure 1 of RFC7636"?

Page10:     However, as the Implicit Flow cannot be protected by PKCE
Seems here, the reference be omitted.

A run of idnits revealed no errors, flaws. There were 1 warning and 1 comments though

  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the

     document.

  Miscellaneous warnings:

  ----------------------------------------------------------------------------

  -- The document date (April 26, 2017) is 14 days in the past.  Is this

     intentional?

  Checking references for intended status: Best Current Practice

  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references

     to lower-maturity documents in RFCs)

     No issues found here.

     Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).

_______________________________________________

OPS-DIR mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/ops-dir

---

From: William Denniss <[email-masked]>
Date: Mon, 22 May 2017 12:08:36 -0700

Thanks for your review Zitao!

Version 12 addresses your comments. Detailed responses below:

On Sun, May 21, 2017 at 8:05 PM, wangzitao <[email-masked]> wrote:

> I have reviewed this document as part of the Operational
> directorate’s ongoing effort to review all IETF documents being processed
> by the IESG.  These comments were written with the intent of improving the
> operational aspects of the IETF drafts. Comments that are not addressed in
> last call may be included in AD reviews during the IESG review.  Document
> editors and WG chairs should treat these comments just like any other last
> call comments.
>
>
>
> through external user-agents, primarily the user’s browser. This
>
> Page 3:     The last sentence of introduction-- “This practice is also
> known as the AppAuth pattern”.
>
Done

> I suggest modifying to: "OAuth"   The Web Authorization (OAuth) protocol.
> In this document, OAuth refers to OAuth 2.0 [RFC6749].
>
I went with:
"In this document, OAuth refers to the OAuth 2.0 Authorization Framework
[RFC6749]."

The phrase "Web Authorization (OAuth) protocol" only seems to appear in our
WG Charter, and not general usage
<https://www.google.com/search?q=web+authorization+protocol>.

> Does it mean "User Information"?  Suggest expanding this abbreviation.
Done.

> Page 5:     Figure 1.   Does the browser and authorization endpoint are
> some kinds of "external user-agent"? Suggest describing it more clearly.
>

Now states:
"illustrates the interaction of the native app with a browser
        external user-agent to authorize the user. "

Page   9:   PKCE [RFC7636] details how this limitation can be used to
> execute a code interception attack (see Figure 1).
>
> Does the Figure 1 means “Figure 1 of RFC7636”?
>

Good catch. I delete the figure reference, since the entire spec talks
about this attack, which is likely sufficient.

> Seems here, the reference be omitted.

Added.

>   == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
I ran it myself with verbose output, and got:

tmp/draft-ietf-oauth-native-apps__1_.txt(435): Found possible FQDN
'com.example.app' in position 5; this doesn't match RFC 2606's
suggested ".example" or ".example.(com|org|net)".

We are actually using a RFC2606 domain name here, but in reverse domain
name notation which is causing this warning.

No changes required.

> [email-masked]

---

From: wangzitao <[email-masked]>
Date: Tue, 23 May 2017 02:50:17 +0000

Cool! This changes/explains make sense to me.

Best Regards!
-Michael

发件人: William Denniss [mailto:[email-masked]]
发送时间: 2017年5月23日 3:09
收件人: wangzitao
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10

On Sun, May 21, 2017 at 8:05 PM, wangzitao <[email-masked]<mailto:[email-masked]>> wrote:

Review result: Has Nits

I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary:

this best practice.

Page 3:     The last sentence of introduction-- “This practice is also known as the AppAuth pattern”.

Done

I suggest modifying to: "OAuth"   The Web Authorization (OAuth) protocol.  In this document, OAuth refers to OAuth 2.0 [RFC6749].
I went with:
"In this document, OAuth refers to the OAuth 2.0 Authorization Framework [RFC6749]."

The phrase "Web Authorization (OAuth) protocol" only seems to appear in our WG Charter, and not general usage<https://www.google.com/search?q=web+authorization+protocol>.

Done.

Now states:

Good catch. I delete the figure reference, since the entire spec talks about this attack, which is likely sufficient.

Added.

     document.

tmp/draft-ietf-oauth-native-apps__1_.txt(435): Found possible FQDN 'com.example.app' in position 5; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)".

We are actually using a RFC2606 domain name here, but in reverse domain name notation which is causing this warning.

No changes required.

  Miscellaneous warnings:

     intentional?

     No issues found here.

OPS-DIR mailing list