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

[Kathleen Moriarty]

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

[John Bradley]

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 <***@gmail.com> wrote:
>
> 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
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

[Kathleen Moriarty]

Hi,

On Tue, Apr 25, 2017 at 9:09 AM, John Bradley <***@ve7jtb.com> wrote:
> Thanks Kathleen,
>
> William and I will address these shortly.
>
> 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.

>
> 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..

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


>
> John B.
>
>
>> On Apr 24, 2017, at 10:47 PM, Kathleen Moriarty <***@gmail.com> wrote:
>>
>> 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
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>



--

Best regards,
Kathleen

[William Denniss]

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:

On Mon, Apr 24, 2017 at 6:47 PM, Kathleen Moriarty <
***@gmail.com> wrote:

> 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.


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.

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.
>
>
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.


> 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.
>

Fixed.


> 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.
>

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


> 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.
>

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.

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.
>

I believe this is addressed now.

Section 8.11
> s/uri/URI/
>
>
Fixed.

Best,
William


>
> --
>
> Best regards,
> Kathleen
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

[Kathleen Moriarty]

Hi William,

Thank you for making the updates. Just a few notes inline and I'll
kick off IETF last call.

On Wed, Apr 26, 2017 at 5:50 PM, William Denniss <***@google.com> wrote:
> 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:
>
> On Mon, Apr 24, 2017 at 6:47 PM, Kathleen Moriarty
> <***@gmail.com> wrote:
>>
>> 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.
>
>
> 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.

Great, thank you.
>
>> 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.
>>
>
> 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.
>

Sounds good, thank you!

>>
>> 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.
>
>
> Fixed.
>
>>
>> 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.
>
>
> Yes, they are. In the definition section, "app" is defined as "shorthand for
> native app". Is that OK, or should I revise?

I missed that, but if it's defined, then you are covered. Thanks.

>
>>
>> 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.
>
>
> 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.

Perfect, thanks. The point in asking was just for other reviews that
will follow.

>
>> 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.
>
>
> I believe this is addressed now.
>
>> Section 8.11
>> s/uri/URI/
>>
Thank you.
>
> Fixed.
>
> Best,
> William
>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>



--

Best regards,
Kathleen

[Kathleen Moriarty]

Hi,

Will there be a new document posted today/tomorrow to address last
call comments/the GenART review? I'd like to add the ballot for the
IESG review and telechat next week, , but it would be best on the
updated draft to avoid duplicate comments.

Thank you,
Kathleen

On Tue, May 2, 2017 at 2:34 PM, Kathleen Moriarty
<***@gmail.com> wrote:
> Hi William,
>
> Thank you for making the updates. Just a few notes inline and I'll
> kick off IETF last call.
>
> On Wed, Apr 26, 2017 at 5:50 PM, William Denniss <***@google.com> wrote:
>> 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:
>>
>> On Mon, Apr 24, 2017 at 6:47 PM, Kathleen Moriarty
>> <***@gmail.com> wrote:
>>>
>>> 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.
>>
>>
>> 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.
>
> Great, thank you.
>>
>>> 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.
>>>
>>
>> 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.
>>
>
> Sounds good, thank you!
>
>>>
>>> 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.
>>
>>
>> Fixed.
>>
>>>
>>> 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.
>>
>>
>> Yes, they are. In the definition section, "app" is defined as "shorthand for
>> native app". Is that OK, or should I revise?
>
> I missed that, but if it's defined, then you are covered. Thanks.
>
>>
>>>
>>> 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.
>>
>>
>> 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.
>
> Perfect, thanks. The point in asking was just for other reviews that
> will follow.
>
>>
>>> 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.
>>
>>
>> I believe this is addressed now.
>>
>>> Section 8.11
>>> s/uri/URI/
>>>
> Thank you.
>>
>> Fixed.
>>
>> Best,
>> William
>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> ***@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
>
> --
>
> Best regards,
> Kathleen



--

Best regards,
Kathleen

[John Bradley]

William and I just discussed it and the goal is to get a new draft out addressing those comments today or tomorrow.

John B.


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Kathleen Moriarty<mailto:***@gmail.com>
Sent: May 18, 2017 2:14 PM
To: William Denniss<mailto:***@google.com>
Cc: ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps

Hi,

Will there be a new document posted today/tomorrow to address last
call comments/the GenART review? I'd like to add the ballot for the
IESG review and telechat next week, , but it would be best on the
updated draft to avoid duplicate comments.

Thank you,
Kathleen

On Tue, May 2, 2017 at 2:34 PM, Kathleen Moriarty
<***@gmail.com> wrote:
> Hi William,
>
> Thank you for making the updates. Just a few notes inline and I'll
> kick off IETF last call.
>
> On Wed, Apr 26, 2017 at 5:50 PM, William Denniss <***@google.com> wrote:
>> 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:
>>
>> On Mon, Apr 24, 2017 at 6:47 PM, Kathleen Moriarty
>> <***@gmail.com> wrote:
>>>
>>> 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.
>>
>>
>> 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.
>
> Great, thank you.
>>
>>> 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.
>>>
>>
>> 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.
>>
>
> Sounds good, thank you!
>
>>>
>>> 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.
>>
>>
>> Fixed.
>>
>>>
>>> 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.
>>
>>
>> Yes, they are. In the definition section, "app" is defined as "shorthand for
>> native app". Is that OK, or should I revise?
>
> I missed that, but if it's defined, then you are covered. Thanks.
>
>>
>>>
>>> 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.
>>
>>
>> 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.
>
> Perfect, thanks. The point in asking was just for other reviews that
> will follow.
>
>>
>>> 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.
>>
>>
>> I believe this is addressed now.
>>
>>> Section 8.11
>>> s/uri/URI/
>>>
> Thank you.
>>
>> Fixed.
>>
>> Best,
>> William
>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> ***@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
>
> --
>
> Best regards,
> Kathleen



--

Best regards,
Kathleen

[Adrian Imach]

Hi ,

Can I ask one more time to unsubscribe me from your mailing list. Thank you.

Adrian Imach

On 18 May 2017, at 19:56, John Bradley <***@ve7jtb.com<mailto:***@ve7jtb.com>> wrote:

William and I just discussed it and the goal is to get a new draft out addressing those comments today or tomorrow.

John B.


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

From: Kathleen Moriarty<mailto:***@gmail.com>
Sent: May 18, 2017 2:14 PM
To: William Denniss<mailto:***@google.com>
Cc: ***@ietf.org<mailto:***@ietf.org>
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-native-apps

Hi,

Will there be a new document posted today/tomorrow to address last
call comments/the GenART review? I'd like to add the ballot for the
IESG review and telechat next week, , but it would be best on the
updated draft to avoid duplicate comments.

Thank you,
Kathleen

On Tue, May 2, 2017 at 2:34 PM, Kathleen Moriarty
<***@gmail.com<mailto:***@gmail.com>> wrote:
> Hi William,
>
> Thank you for making the updates. Just a few notes inline and I'll
> kick off IETF last call.
>
> On Wed, Apr 26, 2017 at 5:50 PM, William Denniss <***@google.com<mailto:***@google.com>> wrote:
>> 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:
>>
>> On Mon, Apr 24, 2017 at 6:47 PM, Kathleen Moriarty
>> <***@gmail.com<mailto:***@gmail.com>> wrote:
>>>
>>> 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.
>>
>>
>> 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.
>
> Great, thank you.
>>
>>> 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.
>>>
>>
>> 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.
>>
>
> Sounds good, thank you!
>
>>>
>>> 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.
>>
>>
>> Fixed.
>>
>>>
>>> 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.
>>
>>
>> Yes, they are. In the definition section, "app" is defined as "shorthand for
>> native app". Is that OK, or should I revise?
>
> I missed that, but if it's defined, then you are covered. Thanks.
>
>>
>>>
>>> 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.
>>
>>
>> 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.
>
> Perfect, thanks. The point in asking was just for other reviews that
> will follow.
>
>>
>>> 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.
>>
>>
>> I believe this is addressed now.
>>
>>> Section 8.11
>>> s/uri/URI/
>>>
> Thank you.
>>
>> Fixed.
>>
>> Best,
>> William
>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> ***@ietf.org<mailto:***@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
>
> --
>
> Best regards,
> Kathleen



--

Best regards,
Kathleen

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth