Subject: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 24 Apr 2017 21:47:05 -0400

Hello,

Thanks for taking the time to document this best practice and the
implementations in the appendix. I have one comment and a few nits.

Security Considerations:
I think it would go a long way to organize these as ones that apply to
this best practice and ones (8.1 and the example in 8.2) about
alternate solutions.  This could also be done through some added text,
but making this clear would be helpful.  Maybe moving 8.1 and 8.2
until after the rest of the sections would be enough and then clearly
state the intent of this text.

IANA Section:
Just a note - you might get some questions about this, but i do think
it's fine to leave that text, although unnecessary.

Nits:
Section 5, punctuation
OLD:
   By applying the same principles from the web to native apps, we gain
   benefits seen on the web like the usability of a single sign-on
   session, and the security of a separate authentication context.
NEW:
   By applying the same principles from the web to native apps, we gain
   benefits seen on the web, like the usability of a single sign-on
   session and the security of a separate authentication context.

The document has text that says 'native app' in some places and 'app'
in others, I assume these are used interchangeably?  It seems that
they are used interchangeably.

Really nitty:
Section 7.2,
Since you are still in the example, did you mean URL in the following:

Such claimed HTTPS URIs can be used as OAuth redirect URIs.
Such claimed HTTPS URLs can be used as OAuth redirect URIs.

And again in the last paragraph of this section.

I'm only asking since you specify URL earlier in this section, so you
were more specific for the example and then drop back to URI (which is
correct, but wondering if you wanted to continue at the same level of
specificity or if there was a reason to just say URI here.

Section 8.11
s/uri/URI/

-- 

Best regards,
Kathleen

---

From: John Bradley <[email-masked]>
Date: Tue, 25 Apr 2017 10:09:56 -0300

Thanks Kathleen,

William and I will address these shortly.

We can take out the IANA section completely if you think it is better.

In the current implementations on Android and iOS Universal Links/App Links and  are only http or HTTPS schema URI making them URL.

So while all URL are URI, we could be more specific if that is OK with the style police.  I thought the URL term was currently discouraged..

John B.

> On Apr 24, 2017, at 10:47 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 25 Apr 2017 10:37:01 -0400

Hi,

> We can take out the IANA section completely if you think it is better.

No, I think it's fine.  Let's see what happens.  It could be helpful
text for some readers, I was just pointing out that some questions may
arise.

> So while all URL are URI, we could be more specific if that is OK with the style police.  I thought the URL term was currently discouraged..

You have it in a couple of places already, so consistency would be
easier to argue if you felt it was needed in the places where it is
already, hence my comment.  I can't be sure what the URI style police
will say, but consistency helps in most situations.  If this is
specific to an example, that's fine.  If the general pattern could be
a URI (not a URL), then just be sure that is clear in the text.

Please let me know when it is ready and I'll start the IETF last call.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: William Denniss <[email-masked]>
Date: Wed, 26 Apr 2017 14:50:56 -0700

Thank you for your review Kathleen.

Version 10 which addresses your comments is out:
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-10

Replies inline:

> state the intent of this text.

Good idea, I think that will help with the readability a lot. I have moved
the "Embedded User-Agent" section to the end, and clarified the purpose.

The reason it's included at all, is that OAuth itself documents two ways to
do native OAuth. This document recommends only one of those ways, and I
thought that detailing why the other way is no longer best-practice would
be helpful to readers.

> it's fine to leave that text, although unnecessary.
I think I may have mis-read https://tools.ietf.org/html/rfc5226#section-6.1.
There is an example of a document that has no IANA actions but still
provides a justification for why that is the case, but in that example it
uses a non-IANA registry unlike this BCP.

In our case, we are definitely operating in an IANA-controlled namespace,
but using a private section of the namespace designed for that purpose.
The intent was to point out that we are following IANA guidelines
correctly.  Happy to remove it (or indicate that it should be removed
during publication) if it seems superfluous.

For now, in the latest update I have clearly stated "This document has no
IANA actions.", but retained the discussion.

>    session and the security of a separate authentication context.

Fixed.

> they are used interchangeably.

Yes, they are. In the definition section, "app" is defined as "shorthand
for native app". Is that OK, or should I revise?

> Such claimed HTTPS URLs can be used as OAuth redirect URIs.

I have migrated to use URI exclusively, other than 2 references to URL
where I'm referring to platform-specific naming / colloquialisms.

I also changed instances of "custom URI scheme" to "private-use URI
scheme", the latter being the terminology used by RFC7595.

> specificity or if there was a reason to just say URI here.

I believe this is addressed now.

Section 8.11
> s/uri/URI/
Fixed.

Best,
William