Option A Phil
> On Feb 19, 2016, at 13:39, Hans Zandbelt <hzandb...@pingidentity.com> wrote: > > Option A: I agree with Mike that the complexity and implementation cost of > Option B will make adoption harder, which was also a concern with the first > iteration of Option A. > > To be honest, I'm not sure most people would even understand why the > complexity would be required and just forget about it. At least with the > simplicity of the most recent option A they don't have to care, just add some > simple parameters/checks. > > And for the record: I've also implemented option A in the mod_auth_openidc > [1] and lua-resty-openidc [2] clients for Apache and NGINX respectively. > > Hans. > > [1] https://github.com/pingidentity/mod_auth_openidc > [2] https://github.com/pingidentity/lua-resty-openidc > >> On 2/19/16 9:18 PM, Mike Jones wrote: >> Option A. I have higher confidence that this specification solves the >> problems because it was designed during a 4-day security meeting >> dedicated to this task by a group of over 20 OAuth security experts, >> *including both sets of researchers in Germany who originally identified >> the problem*. This solution has also been implemented and interop >> tested by Roland Hedberg, Brian Campbell, and I believe others. Note >> that the reason I am advocating this specification is **not** because >> I'm an editor of it; my role was to record in spec language what the >> OAuth security experts designed together over the 4-day period in Darmstadt. >> >> I’ll also note that even if Option B also solves the problem, it comes >> at significant adoption costs and complexity not found in A. In >> particular, it requires that developers understand support a new “Link >> Relation” syntax not used elsewhere in OAuth. As Nat writes about his >> own draft in >> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html - there >> is not a standard JSON syntax for link relations. He writes “we could >> easily create a parallel to it”. I’d rather we solve the problem using >> standard mechanisms already employed in OAuth, rather than risk >> bifurcating OAuth in the developer community by unnecessarily >> inventing/creating new syntax that is unfamiliar to developers and that >> many of them may reject using. >> >> -- Mike >> >> P.S. Information about the OAuth security meeting can be found at >> https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit >> and >> https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/edit >> . >> >> -----Original Message----- >> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig >> Sent: Friday, February 19, 2016 11:43 AM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for >> Adoption >> >> Early February I posted a mail to the list to make progress on the >> solution to the OAuth Authorization Server Mix-Up problem discovered >> late last year. >> >> Here is my mail about the Authorization Server Mix-Up: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html >> >> Here is my mail to the list that tries to summarize the discussion >> status and asked a few questions: >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html >> >> Unfortunately, my mail didn't lead to the intended success. While there >> was some feedback I wasn't getting the desired response. >> >> In order to move forward I believe we need a working group document that >> serves as a starting point for further work in the group*. We have two >> documents that provide similar functionality in an attempt to solve the >> Authorization Server Mix-Up problem. >> >> So, here is the question for the group. Which document do you want as a >> starting point for work on this topic: >> >> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John Bradley >> >> Link: >> >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 >> >> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and >> Sascha Preibisch >> >> Link: >> >> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 >> >> Deadline for feedback is March, 4th. >> >> Ciao >> >> Hannes & Derek >> >> PS: (*) Regardless of the selected solution we will provide proper >> acknowledgement for those who contributed to the work. >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > -- > Hans Zandbelt | Sr. Technical Architect > hzandb...@pingidentity.com | Ping Identity > > _______________________________________________ > 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
