Subject: [OAUTH-WG] OAuth 2.0 for Native Apps: Call for Adoption Finalized

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 4 Feb 2016 20:18:24 +0100

Hi all,

On January 19th I posted a call for adoption of the OAuth 2.0 for Native
Apps specification, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15400.html

There was very positive feedback during the Yokohama IETF meeting to
work on this document in the OAuth working group. More than 10 persons
responded positively to the call on the mailing list as well.

Several persons provided additional input for content changes during the
call and here are the relevant links:
http://www.ietf.org/mail-archive/web/oauth/current/msg15434.html
http://www.ietf.org/mail-archive/web/oauth/current/msg15435.html
http://www.ietf.org/mail-archive/web/oauth/current/msg15438.html

Tony also noted that this document should become an Experimental RFC
rather than a Standards Track RFC. The chairs will consult with the
Security Area directors on this issue.

To conclude, based on the call <draft-wdenniss-oauth-native-apps> will
become the starting point for work in OAuth. Please submit the document
as draft-ietf-oauth-native-apps-00.txt.

Ciao
Hannes & Derek

---

From: Justin Richer <[email-masked]>
Date: Thu, 4 Feb 2016 20:13:47 -0500

I’d like to note that when Tony brought up it being Experimental on the list, several of us (myself included) pointed out that Informational is the correct designation for this specification.

 — Justin

> On Feb 4, 2016, at 2:18 PM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Adam Lewis <[email-masked]>
Date: Fri, 5 Feb 2016 09:10:52 -0600

+1 that it should be Informational.

Also, I never got to respond to the original request, but I am heavily in
favor of this draft. I talk with a lot of native app developers who are
clueless about how to implement OAuth.  The core RFC is very web app
oriented.  I look forward to having a more profiled RFC to point them to :-)

adam

On Thu, Feb 4, 2016 at 7:13 PM, Justin Richer <[email-masked]> wrote:

> I’d like to note that when Tony brought up it being Experimental on the
> list, several of us (myself included) pointed out that Informational is the
> correct designation for this specification.
>
>  — Justin
>

---

From: George Fletcher <[email-masked]>
Date: Fri, 5 Feb 2016 10:30:28 -0500

+1

On 2/5/16 10:10 AM, Adam Lewis wrote:
> Also, I never got to respond to the original request, but I am heavily 
> in favor of this draft. I talk with a lot of native app developers who 
> are clueless about how to implement OAuth. The core RFC is very web 
> app oriented.  I look forward to having a more profiled RFC to point 
> them to :-)
>
> adam
>
> On Thu, Feb 4, 2016 at 7:13 PM, Justin Richer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I’d like to note that when Tony brought up it being Experimental
>     on the list, several of us (myself included) pointed out that
>     Informational is the correct designation for this specification.
>
>      — Justin
>
>     > On Feb 4, 2016, at 2:18 PM, Hannes Tschofenig
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > Hi all,
>     >
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
Chief Architect
Identity Services Engineering     Work: [email-masked]
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

---

From: John Bradley <[email-masked]>
Date: Fri, 5 Feb 2016 13:13:37 -0300

The chairs approved this as a working group document.

The initial version I posted is marked as an intended status as a "Best Current Practice”

The advantage of a BCP is that it can be updated to include new information as things change.

The spec has no extensions to OAuth 2 or MUST’s to profile it.  

Like the TLS BCP it provides implementation advice for developers to safely use the “Standards Track” specifications.

If that is the wrong intended Category it can be changed by the WG chairs at any time.

Thanks for supporting the document.  I hope that we can expand it with more specific advice for developers on native platforms
beyond just iOS and Android.   However what we can do will depend on people with experience in other platforms contributing.

Regards
John B.

> On Feb 5, 2016, at 12:10 PM, Adam Lewis <[email-masked]> wrote:
> 
> Also, I never got to respond to the original request, but I am heavily in favor of this draft. I talk with a lot of native app developers who are clueless about how to implement OAuth.  The core RFC is very web app oriented.  I look forward to having a more profiled RFC to point them to :-)
> 
> adam
> 
> On Thu, Feb 4, 2016 at 7:13 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> > On Feb 4, 2016, at 2:18 PM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi all,
> >
> > http://www.ietf.org/mail-archive/web/oauth/current/msg15400.html <http://www.ietf.org/mail-archive/web/oauth/current/msg15400.html>
> >
> > http://www.ietf.org/mail-archive/web/oauth/current/msg15434.html <http://www.ietf.org/mail-archive/web/oauth/current/msg15434.html>
> > http://www.ietf.org/mail-archive/web/oauth/current/msg15435.html <http://www.ietf.org/mail-archive/web/oauth/current/msg15435.html>
> > http://www.ietf.org/mail-archive/web/oauth/current/msg15438.html <http://www.ietf.org/mail-archive/web/oauth/current/msg15438.html>
> >
> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>

---

From: William Denniss <[email-masked]>
Date: Fri, 5 Feb 2016 11:01:03 -0800

Thank you everyone for your support, and adoption of this document!

This spec doesn't modify the OAuth 2.0 protocol, rather it provides a set
of technical guidelines for implementing OAuth 2.0 for native apps in a
secure and usable way. The intent is a document that has the technical
approval of this working group, and the IETF as a whole, as per RFC1818.
Based on this, I believe "Best Current Practice" is indeed the correct
designation for this document.

For example, many implementations don't allow redirection URIs for
non-"https" schemes, though RFC6749 doesn't have this restriction. Our BCP
documents how to allow these schemes in redirect URIs safely for native
apps. The advice is based on our experience supporting native clients in
this way for several years.

In X years, if the mobile landscape has changed, I suspect we might revise
the document to point to the new best practices of the time.
BCP-designation helps with this by giving us a stable reference for the
practice of using standards-compliant OAuth with native apps.

On Fri, Feb 5, 2016 at 8:13 AM, John Bradley <[email-masked]> wrote:

> Like the TLS BCP it provides implementation advice for developers to
> safely use the “Standards Track” specifications.
>
> Thanks for supporting the document.  I hope that we can expand it with
> more specific advice for developers on native platforms
> beyond just iOS and Android.   However what we can do will depend on
> people with experience in other platforms contributing.
>
> Regards
> John B.
>
>

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 9 Feb 2016 14:39:28 +0000

Hi

OAuth2 spec recommends how to deal with a missing response_type, set an 
error as a query or fragment parameter, depending on whether it is the 
authorization code or implicit flow and redirect.

This implies that authorization code and implicit handlers listen on 
different paths, for example,

code: /code
implicit: /implicit

so if a response type is missing the handler will know how to set the 
error on the redirect uri, as a query or a fragment.....

However, I'd like to have a single handler, example (from the OIDC core):

"https://server.example.com/authorize"

which will support both the code and implicit flows.

Here, 'response_type' is an obvious hint on what kind of flow is in 
process, however, if it is missing, how will a server know how to report 
a missing response_type error if it uses a shared "/authorize" path.

I think in such cases reporting 400 is reasonable. Do you agree ?

Thanks, Sergey

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 9 Feb 2016 18:09:38 +0200

Hi Sergey,

Yes, HTTP 400 is one way to handle a missing response_type with a
"universal" authz endpoint.

Or, you could encode the error in the query string as well as the
fragment, and redirect back to the client.

Vladimir

On 09/02/16 16:39, Sergey Beryozkin wrote:
> Hi
>
> OAuth2 spec recommends how to deal with a missing response_type, set
> an error as a query or fragment parameter, depending on whether it is
> the authorization code or implicit flow and redirect.
>
> process, however, if it is missing, how will a server know how to
> report a missing response_type error if it uses a shared "/authorize"
> path.
>

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 9 Feb 2016 16:21:01 +0000

Hi Vladimir

Thanks for the response,
> "universal" authz endpoint.
Indeed, looks like it makes sense
> fragment, and redirect back to the client.
I'm not sure if that can be done in a 'universal' endpoint case because 
it is not known if a client is running in the implicit context or code 
flow context. Though I guess it a client is restricted at the 
registration time to run only in the code or implicit flows then it will 
provide a hint...

Cheers, Sergey

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 10 Feb 2016 09:59:03 +0200

On 09/02/16 18:21, Sergey Beryozkin wrote:
> I'm not sure if that can be done in a 'universal' endpoint case
> because it is not known if a client is running in the implicit context
> or code flow context. Though I guess it a client is restricted at the
> registration time to run only in the code or implicit flows then it
> will provide a hint...

If you set both the query and the fragment you'll take care of both flows :)

---

From: Sergey Beryozkin <[email-masked]>
Date: Wed, 10 Feb 2016 10:09:48 +0000

Hi

I got it, thanks for clarifying the idea :-)

Thanks, Sergey

---

From: John Bradley <[email-masked]>
Date: Wed, 10 Feb 2016 10:30:27 -0300

This trick works for the response types that use the GET POST and fragment encoded response modes. 

In the future if we do a Java Script response mode as is being proposed that might not always be the case.

Just a heads up.

Regards
John B.
> On Feb 10, 2016, at 7:09 AM, Sergey Beryozkin <[email-masked]> wrote:
> 
> Hi
>

---

From: Eduardo Gueiros <[email-masked]>
Date: Mon, 15 Feb 2016 16:18:30 -0700

+1 Being in the mobile space myself and constantly meeting with native app
developers I've heard my share of horror stories on how OAuth was
implemented, myself being guilty of being "creative" around OAuth.

This draft is be of great value to those of us who are around these
developers, we'll be helping bringing awareness about the correct practices
suggested in the document.

On Fri, Feb 5, 2016 at 8:10 AM, Adam Lewis <[email-masked]
> wrote:

-- 
-- 
*Eduardo Gueiros*
*Director, Mobile B.U.* |  Jive Communications, Inc.
jive.com  |  [email-masked] <[email-masked]>*
<http://www.facebook.com/jive.communications.inc>
<http://www.twitter.com/getjive> <http://goplus.us/jive>
<http://www.youtube.com/jivetalks>
<http://www.linkedin.com/company/jive-communications-inc>

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 16 Feb 2016 08:22:52 +0000

Fwiw, French govt's FranceConnect, which uses OpenID Connect, has sample
apps using web views, and not using PKCE :-( (haven't looked in more
details; don't know whether their AS supports PKCE).
I just implemented PKCE in Ozwillo 10 days ago after reading this doc. I
still have some work to do to properly support native apps though, and then
I could build a sample app.

Le mar. 16 févr. 2016 00:18, Eduardo Gueiros <[email-masked]> a écrit :

> On Fri, Feb 5, 2016 at 8:10 AM, Adam Lewis <
> [email-masked]> wrote:
>