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

Torsten Lodderstedt <> Sun, 28 February 2016 15:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6316C1A1A3B for <>; Sun, 28 Feb 2016 07:35:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KbXIG-o0CN9F for <>; Sun, 28 Feb 2016 07:35:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9BC301A1A32 for <>; Sun, 28 Feb 2016 07:35:44 -0800 (PST)
Received: from [] (helo=[]) by with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <>) id 1aa3Nn-0004Md-VB; Sun, 28 Feb 2016 16:35:44 +0100
To: Hannes Tschofenig <>, "" <>
References: <>
From: Torsten Lodderstedt <>
Message-ID: <>
Date: Sun, 28 Feb 2016 16:35:43 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090307010102010004050106"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
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: Sun, 28 Feb 2016 15:35:48 -0000

Hi all,

I prefer to use draft-jones-oauth-mix-up-mitigation-01 as starting point 
simply because it gives some description of the threats we need to cope 
with. This does not preclude to eventually use 
draft-sakimura-oauth-meta-07 as solution or any other suitable 
mechanisms we find consensus on.

In my opinion, both proposals (iss and meta data) are very similar on a 
conceptual level as they inform the client about the sender of the 
redirect. iss could nicely fit with the upcoming OAuth AS discovery, 
whereas meta is appealing if we want a mechanism, which always keeps the 
client informed where it is considered secure to obtain/use credentials 
(tokens, codes, ...).

Beside this, I would like to emphasize again that code injection/copy 
and paste is not related to idp mix up (even if we discussed both in the 
same workshop). Even traditional OAuth deployments (single AS) are 
potentially affected by the attack. I suggest to split the draft into 
separat documents per threat/mitigation and move forward mitigation 
against code injection as quickly as possible. The current proposal to 
tie the authz code to the client state seems a pretty simple and 
straightforward solution to me.

kind regards,

Am 19.02.2016 um 20:42 schrieb Hannes Tschofenig:
> 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