Fair points. I also think this is an area where good online documentation, and books like *OAuth 2 in Action* can help, and possibly help a lot sooner.
On Thu, Apr 7, 2016 at 4:15 PM, Adam Lewis <adam.le...@motorolasolutions.com > wrote: > +1 > > I will not comment on the timeline for this, but I will passionately > endorse the need for an OAuth 2.1 spec. > > Speaking as somebody who now has spent years advocating for, and building > out public safety / first responder architectures built on an OAuth 2.0 > architecture, I can say 2 things with conviction: > > The good: OAuth 2.0 has enabled incredible use cases for us, and it is a > gift that keeps on giving, the new WG efforts around POP and token exchange > are solving even more use cases for us. This is hands down one of the best > WGs I've known, and the work done here is nothing short of awesome. > > The bad: I have yet to meet anybody outside of the WG that really > understands OAuth 2.0. I mean "really" understands it. (to this day, I > still think it is only because of the good graces of others in this WG like > John and Justin that I understand it with the depth that I do). People > talk about it at high levels, they talk about tokens, but still don't get > what it is trying to solve nor how to securely deploy it. 99% of the people > I meet still don't get the difference between authentication and delegated > authorization. I have dedicated massive amounts of cycles trying to > educate my own community (and anybody else I meet for that matter). I > personally found the core RFC very hard to digest, and now I need to refer > to N more, many of which should be folded into a new 2.1 core spec. All > this given, It is no wonder there are so many insecure implementations of > it. > > So here's to OAuth 2.1 :-) > > -adam > > On Thu, Apr 7, 2016 at 1:56 PM, Hardt, Dick <d...@amazon.com> wrote: > >> I think there are already years of implementation and experience since 2.0 >> >> If we wait until all the outstanding issues and new features have had >> implementations and experience, we will never do a 2.1 as there continues >> to be new things. >> >> I would suggest a 2.1 be a clean, simple document of the core spec in one >> document that includes the security and implementation recommendations. >> >> Alternative title: OAuth, The Good Parts. :) >> >> — Dick >> >> >> >> >> On 4/7/16, 3:25 PM, someone claiming to be "OAuth on behalf of Mike >> Jones" <oauth-boun...@ietf.org on behalf of michael.jo...@microsoft.com> >> wrote: >> >> Yes - an intentionally conservative, implementation- and >> experience-driven path. >> >> Revising OAuth 2.0 is a *big deal*. We shouldn't even be talking about >> it until we've completed steps 1-5 below - *including* the "iterate" step, >> as necessary. If we get this wrong, we'll fragment OAuth, which is a >> terrible and irresponsible outcome we should consciously avoid at all costs. >> >> In particular, we should not recharter for an OAuth 2.1 until we already >> know what will be in it and know from deployment experience that it's the >> right stuff. >> >> -- Mike >> >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] >> Sent: Thursday, April 7, 2016 3:16 PM >> To: Mike Jones <michael.jo...@microsoft.com> >> Cc: Samuel Erdtman <sam...@erdtman.se>; Anthony Nadalin < >> tony...@microsoft.com>; oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth 2.1 >> >> Hi Mike, >> >> in my opinion, you described a possible path towards 2.1. Would you agree? >> >> best regards, >> Torsten. >> >> > Am 07.04.2016 um 13:38 schrieb Mike Jones <michael.jo...@microsoft.com >> >: >> > >> > I am strongly against creating a 2.1 spec until we have at least a year >> of deployment experience with the contents we're adding to 2.0, so as not >> to fragment the OAuth marketplace. >> > >> > I think we should: >> > 1. Continue working on new security mitigations in new drafts (such >> > as mix-up-mitigation, etc.) that add features to use with 2.0 2. >> > Continue working on PoP specs (such as pop-key-distribution, etc.) >> > that add features to use with 2.0 3. Continue working on other new >> > specs (such as discovery, resource-indicators, etc.) that add features >> > to use with 2.0 4. Learn from deployment experience with all of them >> > 5. Iterate if the deployment experience tells us that we need to >> > >> > Only after we believe we have all the features right and we know that >> they work together well should we consider creating a 2.1. If we rush to a >> 2.1 and get it wrong, we'll lose developers' trust and we'll never get it >> back. >> > >> > -- Mike >> > >> > -----Original Message----- >> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Samuel >> > Erdtman >> > Sent: Thursday, April 7, 2016 12:48 PM >> > To: Anthony Nadalin <tony...@microsoft.com> >> > Cc: oauth@ietf.org >> > Subject: Re: [OAUTH-WG] OAuth 2.1 >> > >> > +1 on a 2.1 version >> > >> > -1 on defining scopes more precisely in 2.1 >> > >> > Sent from my iPhone >> > >> >> On 7 apr. 2016, at 14:46, Anthony Nadalin <tony...@microsoft.com> >> wrote: >> >> >> >> I don't belive that scopes should be defined more precisely as this >> opaqueness was a design feature, I'm not seeing the reason why scopes need >> to be defined, as these are application specific. >> >> >> >> -----Original Message----- >> >> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten >> >> Lodderstedt >> >> Sent: Thursday, April 7, 2016 5:32 AM >> >> To: George Fletcher <gffle...@aol.com> >> >> Cc: oauth@ietf.org >> >> Subject: Re: [OAUTH-WG] OAuth 2.1 >> >> >> >> Hi all, >> >> >> >> as I already said in the meeting: I would very much prefer to have an >> extension/update of RFC 6819 covering all "new" threats, including: >> >> - mix up >> >> - code injection aka copy and paste >> >> - open redirector at AS and client >> >> - potential other threats in the context of "dynamic" OAuth >> >> >> >> I also assume mitigations for (at least some of) the threats need to >> go into an update of RFC 6749 as normative text. To give an example: if we >> agree on using the state parameter at the token endpoint to mitigate code >> injection, this MUST be part of the core spec (request description and >> security consoderations). Otherwise, noone will even consider it. >> >> >> >> We should also use the opportunity to improve/enhance the text of the >> spec. In the course of the last years, we have learned a lot about >> ambiquities of the text and how different implementations utilize OAuth. >> >> >> >> I think time is right to define scopes more precisely. As the >> discussions in the last days proved again (at least for me), scope is not >> sufficiently defined to come up with interoperable implementations. >> Additionally, there seems to be a need to represent resource server >> locations (to not say identities :-)) in this context. >> >> >> >> To bundle all changes in a version 2.1 would also make communication >> into the market much easier. >> >> >> >> best regards, >> >> Torsten. >> >> >> >>> Am 06.04.2016 um 16:05 schrieb George Fletcher <gffle...@aol.com>: >> >>> >> >>> I'd definitely prefer a single solution document to many little ones >> that have to be combined to actually build a secure solution. It's already >> getting complex with the additional specs that have been added. >> >>> >> >>> Additionally, I'm not against working on OAuth 2.1. >> >>> >> >>> Thanks, >> >>> George >> >>> >> >>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote: >> >>>> >> >>>> Existing implementations are for the large part ok and do not need >> these mitigations. >> >>>> >> >>>> Only the new use cases we have been discussing (configure on the fly >> and multi-as, etc) really need mitigation. >> >>>> >> >>>> The updated by approach seems like a good way to address the new >> cases. >> >>>> >> >>>> Phil >> >>>> >> >>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig < >> hannes.tschofe...@gmx.net> wrote: >> >>>>> >> >>>>> Hi all, >> >>>>> >> >>>>> today we discussed the OAuth Authorization Server Mixup draft. We >> >>>>> were wondering what types of threats the document should find >> solutions for. >> >>>>> >> >>>>> We discussed various document handling approaches including >> >>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate >> >>>>> solution documents >> >>>>> * combined solution document covering the OAuth Mix-Up and the >> >>>>> Cut-and-Paste attacks. >> >>>>> >> >>>>> Barry pointed out that these documents could update the OAuth base >> >>>>> specification. >> >>>>> >> >>>>> As a more radical change it was also suggested to revise RFC 6749 >> >>>>> "OAuth >> >>>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model >> >>>>> and Security Considerations". >> >>>>> >> >>>>> Opening up the OAuth base specification obviously raises various >> >>>>> other questions about cleaning up parts that go far beyond the AS >> >>>>> mix-up and the cut-and-paste attacks. Other specifications, such >> >>>>> as the Open Redirector, could be folded into such a new >> specification. >> >>>>> >> >>>>> Derek and I would appreciate your input on this topic before we >> >>>>> make a decision since it has significant impact on our work. >> >>>>> >> >>>>> Ciao >> >>>>> Hannes & Derek >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> OAuth mailing list >> >>>>> OAuth@ietf.org >> >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw >> >>>>> w >> >>>>> w >> >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40mi >> >>>>> c >> >>>>> r >> >>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91a >> >>>>> b >> >>>>> 2 >> >>>>> d7cd011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI% >> >>>>> 3 >> >>>>> d >> >>>> _______________________________________________ >> >>>> OAuth mailing list >> >>>> OAuth@ietf.org >> >>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww >> . >> >>>> ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micr >> >>>> o >> >>>> s >> >>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d >> >>>> 7 c >> >>>> d011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >> >>> >> >>> _______________________________________________ >> >>> OAuth mailing list >> >>> OAuth@ietf.org >> >>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >> >>> i >> >>> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micros >> >>> o >> >>> f >> >>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd >> >>> 0 >> >>> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww. >> >> i >> >> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microso >> >> f >> >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0 >> >> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >> >> >> >> _______________________________________________ >> >> 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 >> > > > _______________________________________________ > 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
