Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Option A

Phil

> On Feb 19, 2016, at 13:39, Hans Zandbelt <hzandbelt@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-bounces@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
> hzandbelt@pingidentity.com | Ping Identity
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth