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

[Adrian Imach <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]>
Sent: May 18, 2017 2:14 PM
To: William Denniss<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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
<[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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
>> <[e-mail]<mailto:[e-mail]>> 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
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
>
> --
>
> Best regards,
> Kathleen



--

Best regards,
Kathleen

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth