Hi Tony, I'm not saying we need to define scopes or scope values. These are certainly application/API specific.
Here are the issues I see: - Namespaces: there is no guidance on how to prevent clashes among scopes for different applications. Say we had used the scope value "email" for our email service before we implemented OIDC. How should we have solved the naming conflict with the respective claim-related scope value "email"? Resource servers: it's perfectly possible to represent resource server ids in scope values today. BUT: not in an interoperable way. That's why we have concepts like aud, audience, resource on the table in different recent specs. They all try to circumvent the same problem. - Is the scope supposed to describe the grant of the code, the refresh or the access token? We had an interresting side discussion about that topic and it seems everyone has another _opinion_ about it and implementations differ. I'm mostly interested in support for multi-application deployments and my conclusion is: The current scope concept only works in multi-application deyployments if: - there are ecosystem-specific rules of how to use scope values (good luck with standard applications and forget interop) - there is one AS per application (terrible UX) We can do better. best regards, Torsten. > Am 07.04.2016 um 09:46 schrieb Anthony Nadalin <tony...@microsoft.com>: > > 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
