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 <ve7...@ve7jtb.com> wrote: > 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 <adam.le...@motorolasolutions.com> > wrote: > > +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 <jric...@mit.edu> 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 < >> hannes.tschofe...@gmx.net> wrote: >> > >> > 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 >> > >> > >> > >> > _______________________________________________ >> > 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 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
