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%2fww >>>>> w >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40mic >>>>> r >>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab >>>>> 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%40micro >>>> s >>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7 >>>> 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%40microso >>> f >>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0 >>> 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%40microsof >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd01 >> 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
