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

[Sebastian.Ebling]

Hi William,

Thank you very much for your very detailed response!

May be I was a bit gruff. I simply expected best practices about Android 
Account Manager vs. native OAuth in the Android Implementation Details section. 
I did not realize, that it is addressed by “Non-Browser External User-Agents” 
within the security considerations.

Nevertheless, I highly appreciate this BCP document and also the work that has 
been done in behind to improve browser integration in Android and iOS.

Best regards

Sebastian

--
Sebastian Ebling / sebastian.ebl...@telekom.de / +49 6151 
5838207<tel:+4961516807135>
Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)



Von: William Denniss [mailto:wdenn...@google.com]
Gesendet: Freitag, 3. März 2017 03:13
An: Ebling, Sebastian
Cc: oauth@ietf.org<mailto:oauth@ietf.org>
Betreff: Re: [OAUTH-WG] review draft-ietf-oauth-native-apps-07

The Android Account Manager isn't standard OAuth, unlike this BCP.  Thus, the 
Account Manager pattern falls under the security considerations section 
"Non-Browser External User-Agents" and is officially out of scope of the 
specification.

To answer your question though, this BCP is the Google recommended way to do 
standards-based OAuth on Android. Some official references:

OAuth 2.0 for Mobile & Desktop 
Apps<https://developers.google.com/identity/protocols/OAuth2InstalledApp> 
(which directly references this BCP! Scroll to the bottom)
Set up SSO with Chrome Custom Tabs with Android for 
Work<https://developer.android.com/work/guide.html#sso>
Your Apps at work - Google I/O 2016<https://youtu.be/Za0OQo8DRM4?t=22m57s>
Modernizing OAuth interactions in Native Apps for Better Usability and 
Security<https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html>

NB. every time you see "AppAuth" in those docs, it's a reference to the library 
that implements the pattern defined by this BCP.

The utility of Account Manager really depends on your use-case. I expect that 
most people who need to deal with non-Google ASes on Android will migrate over 
to the pattern outlined in this BCP.  People who deal exclusively with the 
Google IdP (e.g. display a Google Sign-in button) will likely keep doing what 
they're doing, which is fine.

The main drawback of the Account Manager pattern was that you need to have an 
app from the authorization server (AS) installed which can't always be 
guaranteed.  That's why this is less of a problem with Google's IdP, since all 
phones that have the Play store come with the Google authentication agent.

Even if you can guarantee that the authentication app will be installed, there 
is overhead on the AS such as maintenance and updates for the native 
authorization app component.  I participated in many discussions over a two 
year period in the OAuth and OpenID communities, and the general consensus was 
that requiring the AS to provide a native app was a burden, and harmful to 
interop, which lead to the drafting of this BCP which doesn't require any 
native code to be maintained and distributed by the AS.



On Mon, Feb 27, 2017 at 12:22 AM, 
<sebastian.ebl...@telekom.de<mailto:sebastian.ebl...@telekom.de>> wrote:
Hi all,

I have a question that relates to section B.2. Android Implementation Details.

I understand this as a working group best practice. Unfortunately this does not 
necessarily meet the Google instruction for Android. There is a lot of 
documentation out there pointing to the Android Account Manager and I do not 
get these both together.

Any idea?

Best Regards

Sebastian

--
Sebastian Ebling / 
sebastian.ebl...@telekom.de<mailto:sebastian.ebl...@telekom.de>
Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)



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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Samuel Erdtman]

Thanks Denis!

On Fri, Mar 3, 2017 at 7:37 AM, William Denniss  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  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  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 
>>> 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  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
  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 

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

[Samuel Erdtman]

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  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  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  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
>>  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 
>> wrote:
>>
>>> Hi,
>>>
>>> I just had a question on best practice. In this document a large part of
>>> the 

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

[Sebastian.Ebling]

Hi all,

I have a question that relates to section B.2. Android Implementation Details.

I understand this as a working group best practice. Unfortunately this does not 
necessarily meet the Google instruction for Android. There is a lot of 
documentation out there pointing to the Android Account Manager and I do not 
get these both together.

Any idea?

Best Regards

Sebastian

-- 
Sebastian Ebling / sebastian.ebl...@telekom.de
Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Sebastian.Ebling]

Hi,

there is a typo in B.4. 
Search for "are are" and replace it with "are".

Best regards

Sebastian

-- 
Sebastian Ebling / sebastian.ebl...@telekom.de / +49 6151 5838207
Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Justin Richer]

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  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  > wrote:
> 
> I don't think 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 
>>  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 > > 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 

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

[Denis]

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 
 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 > 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 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Samuel Erdtman]

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 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth