Subject: Re: [OAUTH-WG] Pushing "OAuth 2.0 for Native Apps" to the IESG -- Short Working Group Last Call

From: Nat Sakimura <[email-masked]>
Date: Wed, 01 Mar 2017 14:11:03 +0000

It looks generally good. Thanks William and John for creating it.

I spotted a few nits.

NS1: MUST is not a recommendation
================================
In 8.5, it says:

(which is a recommended in Section 7.1.1
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07#section-7.1.1>)

However, in 7.1.1, it is a MUST, i.e., required instead of recommended. So,
"recommended" in the above sentence needs to be changed to "required".

NS2: Dynamically registered client can be treated as a confidential client
=======================================================
In 8.9
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07#section-8.9>.
it says:

Authorization servers that still require a shared secret for native app
clients MUST treat the client as a public client

As it is a MUST, we have to qualify it a little more as it is ok to treat
it as a confidential client if the client does dynamically register the
copy and obtain shared secret that is only shared between the copy of the
app and the server.

Suggests:

Authorization servers that still require a statically included shared
secret for native app clients MUST treat the client as a public client

NS3: Sever Mix-up
======================
8.11
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07#section-8.11>.
talks about mix-up mitigation but misses one of the points. Specifically:

* the app MUST store the redirect uri in the request with the "session" and
MUST verify that it exactly matches with the URI of the endpoint that it
received the response.

Cheers,

Nat Sakimura

On Wed, Mar 1, 2017 at 5:51 AM Brian Campbell <[email-masked]>
wrote:

> -07 LGTM
>
> On Feb 20, 2017 2:53 AM, "Hannes Tschofenig" <[email-masked]>
> wrote:
>
> Hi all,
>
> after the working group last call of the "OAuth 2.0 for Native Apps"
> document July last year (see
> https://www.ietf.org/mail-archive/web/oauth/current/msg16534.html) I
> had, as a shepherd, collected IPR confirmations (see
> https://www.ietf.org/mail-archive/web/oauth/current/msg16672.html) and
> produced a shepherd writeup (see
> https://www.ietf.org/mail-archive/web/oauth/current/msg16702.html).
>
> Since version -03 and the current version -07 a fair amount of text has
> been changed, see
>
> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-oauth-native-apps-03.txt&url2=https://tools.ietf.org/id/draft-ietf-oauth-native-apps-07.txt
>
> Although most of those changes are editorial and normative changes have
> been discussed on the mailing list I believe it is fair to let the group
> take a brief look at the final version.
>
> For this reason we will issue a short, one week, working group last call
> before pushing the document to the IESG.
>
> So, please provide your comments to the list no later than February 27th.
>
> Here is the link to the document again:
> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07
>
> Ciao
> Hannes & Derek
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: William Denniss <[email-masked]>
Date: Thu, 2 Mar 2017 18:13:22 -0800

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, <[email-masked]> 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 / [email-masked]
> Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)
>
>
>

---

From: William Denniss <[email-masked]>
Date: Thu, 2 Mar 2017 22:38:02 -0800

Thank you for the excellent feedback Nat. I believe I have addressed all
the points you raised in the latest version (08).

On Wed, Mar 1, 2017 at 6:11 AM, Nat Sakimura <[email-masked]> wrote:

> However, in 7.1.1, it is a MUST, i.e., required instead of recommended.
> So, "recommended" in the above sentence needs to be changed to "required".
>
>
> * the app MUST store the redirect uri in the request with the "session"
> and MUST verify that it exactly matches with the URI of the endpoint that
> it received the response.
>
> Cheers,
>
> Nat Sakimura
>
>
>
>> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/
>> id/draft-ietf-oauth-native-apps-03.txt&url2=https://
>> tools.ietf.org/id/draft-ietf-oauth-native-apps-07.txt
>>

---

From: <[email-masked]>
Date: Mon, 6 Mar 2017 17:29:13 +0000

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 / [email-masked] / +49 6151 5838207<tel:+4961516807135>
Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)

Von: William Denniss [mailto:[email-masked]]
Gesendet: Freitag, 3. März 2017 03:13
An: Ebling, Sebastian
Cc: [email-masked]<mailto:[email-masked]>
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, <[email-masked]<mailto:[email-masked]>> 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 / [email-masked]<mailto:[email-masked]>
Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)

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