+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%2fwww >>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micr >>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2 >>>> d7cd011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d >>> _______________________________________________ >>> 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%40micros >>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7c >>> 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%40microsof >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd01 >> 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d > > _______________________________________________ > 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%40microsoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd011db47%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
