+1 On Thu, Apr 7, 2016 at 12:25 PM, Mike Jones <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
