Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

George Fletcher <> Mon, 25 January 2016 18:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7FA251B381D for <>; Mon, 25 Jan 2016 10:10:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Csr4t0OVyP9f for <>; Mon, 25 Jan 2016 10:10:44 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87E7C1B383D for <>; Mon, 25 Jan 2016 10:10:44 -0800 (PST)
Received: from ( []) by (Outbound Mail Relay) with ESMTP id 6E9F33800127; Mon, 25 Jan 2016 13:10:43 -0500 (EST)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (MUA/Third Party Client Interface) with ESMTPSA id CED5F38000081; Mon, 25 Jan 2016 13:10:42 -0500 (EST)
To: John Bradley <>
References: <> <> <> <> <> <> <> <> <>
From: George Fletcher <>
Organization: AOL LLC
Message-ID: <>
Date: Mon, 25 Jan 2016 13:10:42 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------040801030900020809060906"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; t=1453745443; bh=bsUROEeqCslZSszJMBBjiBZ9X5nc8aRZ2d0kwlF8bw8=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=jNZJjjBvY7LDESHQVBJ0Kk4pDtC4rDc0XJUmZdwClozDdK8RGqBW1vblLIUlEv3fD jlbIXePTDbDGF/9VifdSgN8Fei8/EaB/piL16t7+Zm6zuPUmoy6I2YUS3tWiTXCXz1 uqY1s5G3tQC//uGAjYdnA3XJt3fpFENw8Rf6OIac=
x-aol-sid: 3039ac1d1bcd56a665223f47
Archived-At: <>
Cc: " WG" <>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
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: Mon, 25 Jan 2016 18:10:46 -0000

Comments inline

On 1/25/16 12:32 PM, John Bradley wrote:
> No, client id_are scoped by issuer.
This makes sense, but I'm not sure it's a current assumption by OAuth2 
implementations :)
> There is no need for AS to make the client_id globally unique.
>  The client needs to not allow two AS to provide it with the same 
> issuer client_id pair.
> That would probably be imposable for many clients anyway.
I would rather say that the results of two client_ids being the same 
from two different issuers is undefined.
> For Connect clients typically manage configurations using issuer as 
> the primary key.  I doubt may would support even two client_id from 
> the same issuer.
If scoped by issuer this makes sense, though the concept of "issuer" as 
a comparable entity wasn't really talked about with OAuth2.
> For OAuth what clients do is slightly less clear.  In general they 
> don’t have more than one AS per API do might try and organize things 
> by RS or AS.
I agree that not many clients support dynamic client registration. 
However, I would say there a number that support multiple AS that are 
"fixed" within the code (including fixed endpoint URIs). So I would say 
that the associations would be fixed in code. There wouldn't necessarily 
be an association outside of the code which maps button A to AS1 and 
button B to AS2.
> In principal a OAuth client might have two different AS each with a 
> different client ID and that will be OK as long as the client_id in 
> the request is the same as the one in the response.
> So going to a new AS and getting back the same iss and client_id that 
> you registered someplace else would be an error for the client.
> I don’t think that is unreasonable.
I agree that this is reasonable with the assumption that client_id's are 
scoped by "issuer". It's just likely that most clients in the field do 
not have this sort of explicit association. The OAuth2 Dynamic Client 
Registration spec does not define an "issuer" in the response. For the 
OAuth2 use cases, what is the proposed "issuer" equivalent URI that is 
being used to scope the client_id?
> John B.
>> On Jan 25, 2016, at 12:30 PM, George Fletcher < 
>> <>> wrote:
>> I'm still catching up... but to this point specifically...
>> Doesn't this require that the same client_id NOT be used 
>> simultaneously at two (or more) Authorization Servers? If so, I don't 
>> believe that is a viable option. It's a little late in the game to be 
>> putting requirements on the AS as to how it generates it's client_id.
>> Thanks,
>> George
>> On 1/25/16 9:11 AM, John Bradley wrote:
>>> Returning the iss and client_id from the authorization endpoint per 
>>> Mike’s draft allows the client to reject the authorization response 
>>> and not leak the code.

Chief Architect
Identity Services Engineering     Work:
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter:
Office: +1-703-265-2544           Photos: