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
