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

Hans Zandbelt <> Fri, 19 February 2016 20:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4EE301B341E for <>; Fri, 19 Feb 2016 12:39:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8e4km9go0jAm for <>; Fri, 19 Feb 2016 12:39:50 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2A3F1B31F3 for <>; Fri, 19 Feb 2016 12:39:49 -0800 (PST)
Received: by with SMTP id b205so83492601wmb.1 for <>; Fri, 19 Feb 2016 12:39:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=X+hEEUCe76WrkgE2/N3aeFfUD18Nzxc+Ve+o2hjyiyw=; b=jcZGyETwPADAg9/ltW/mNpv1CPNfLdhEc9gyDUx46lmDkkPPa0h0GJNqH40jsUWTxv X15r8ixkBANpAcw2I/8Th/wbmlZebkSSP/FEf9nxlZDwfZxa/NxSsB+/AAb2fdsZANOM jIJHv73rNHLAPRZqR++j3pvuzD4c57Q5DzuGA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=X+hEEUCe76WrkgE2/N3aeFfUD18Nzxc+Ve+o2hjyiyw=; b=D12ua8cEUlT3NwXkuUZhCZ+lg6bT8BgkgDN0TfQW5/IJqmHy6ZzW95mHihcc+7aoF3 AMYGH9I8in3SeNWcqJWLX9Z9zAyLV8AxsyUYMsNwHqG7jaBMU2tu1Kc1MZYe8XwGHqg0 4m4121U7e+51PkJwQDy0IwKDI/verHiNr/N/hNyyhutkY4JoOr6ODWsG8piZPklM06pU JxSKn82Ywm3be+h1G4F1Nc7bBrPm6Sfkr47naOXz+3blX8rPWgvwFgDYdaDr+8Lmyeu4 hqQmjo6YGCYl2biVPjzkgOHtfHzy6UuQ7dDIT9+bd1bVR4XdEkZ+oE93WONMRj35pzkU dsUw==
X-Gm-Message-State: AG10YOQOlZcj9RQ3XwB4nFxyNvH4faLfRo6Fc29EXYJc5ya78quD0I+5HOwYb3w7D+K5xqVU
X-Received: by with SMTP id 68mr10974844wmj.33.1455914388318; Fri, 19 Feb 2016 12:39:48 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id 8sm9159580wmk.13.2016. (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Feb 2016 12:39:47 -0800 (PST)
To: Mike Jones <>, Hannes Tschofenig <>, "" <>
References: <> <>
From: Hans Zandbelt <>
Message-ID: <>
Date: Fri, 19 Feb 2016 21:39:46 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Feb 2016 20:39:52 -0000

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.



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
> - 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
> and
> .
> -----Original Message-----
> From: OAuth [] On Behalf Of Hannes Tschofenig
> Sent: Friday, February 19, 2016 11:43 AM
> To:
> 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:
> Here is my mail to the list that tries to summarize the discussion
> status and asked a few questions:
> 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:
> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and
> Sascha Preibisch
> Link:
> 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

Hans Zandbelt              | Sr. Technical Architect | Ping Identity