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

John Bradley <> Mon, 25 January 2016 18:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 15BF21B3888 for <>; Mon, 25 Jan 2016 10:22:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1RSNMom0JtZt for <>; Mon, 25 Jan 2016 10:22:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 29F991B3885 for <>; Mon, 25 Jan 2016 10:22:33 -0800 (PST)
Received: by with SMTP id s68so57643364qkh.3 for <>; Mon, 25 Jan 2016 10:22:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=qmckDpVinYYpg7umiwWS6uMj/Dpl/NYtHE2DcorIXbA=; b=vuXdEptg5Fu+QXQG5tUuLQcsG2e1A91WU/Bd9pOQpGvvWw8BCoJy9c1l3jGlngjHBw Lyc37+4XWptU0EQ+RvqrThmT13su9NeejmeOvbEwXF7PZb2/CSfnF/AaMbYeAso/viXz EiSKWLFFm8gZzE0jVLQzkWng0uZCw2cwvDbr6U1YHkZwOirAq5WA/z/ZWlGBEq93pdJE A+Jdn16ZVYef1C3UmTWvuBc54rmkiOK0UKm1KxgkPfszDrnp5yPI1FCqYpFOTOFEdBbr YwlJjWJyomX1CC513Er2iowA2HzP5LSaLTSSxOXfK7lRigVzBH9dqPqzgxWnBJ/6MrgS 7zkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=qmckDpVinYYpg7umiwWS6uMj/Dpl/NYtHE2DcorIXbA=; b=TJNI7u5BccWhcrik1OA7XMzPZmNV519/kStvRTi554tGvxGqJjfL/Rj2gaytqkexs0 vrVZY+VvZ7xVe0O7LtFTaEjrl4P9miaNBGGbxbRloSt/wlz9fkSSXygsSw5czeS+w3Xb ZZnbxR7ID3uIsTDgTsZoVpcV4vVrFbT0YhmHUa3DEcVXsO9qCRJnVKrQ/kOmNSGogN6k ygkiTruiGYg7nhcMRS3L272zrlh3mo1n3f3+nz1YildgMLWetQisWIjDFZlkDkFNCI+2 ZhpVbgimC3r2tPWhCVptF7NqB61143Z9efJ/IpOvWU0Odd2Jyuz1ZFsY1r2Vk8hPPjYO pn1w==
X-Gm-Message-State: AG10YOQphS10rXWTN49I8Ce3N344vkSKLKfCXzhoWYWg7yJfnl3n0vUYqhTVUhFykpMTSg==
X-Received: by with SMTP id c198mr22804784qka.24.1453746152965; Mon, 25 Jan 2016 10:22:32 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id f34sm9166824qgf.42.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 10:22:32 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_7713E2B2-5CF1-4B7A-ABFD-76AAF5ECEA01"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <>
In-Reply-To: <>
Date: Mon, 25 Jan 2016 15:22:21 -0300
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: George Fletcher <>
X-Mailer: Apple Mail (2.3112)
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:22:37 -0000

The presumption is that registration would need to add a issuer, as an identifier of the AS, and that would be optionally be used in discovery.

OAuth as is supports the single AS model.

To support multiple AS for a single client something needs to change.    Adding issuer and client_id to the response with optional discovery was seen as the least disruptive at the Germany meeting.

 The other way to do it is to return discovery info from the the authorization and token endpoints, however the request probably also need to be modified so that the AS knows what the resource is, otherwise 
other things will break.    

It is possible now to have one authorization endpoint provide code for per Tennent token endpoints.(No I don’t know of any one doing it).

Anything we add to tighten up the trust model will have impacts on what can be done with OAuth.  

John B.
> On Jan 25, 2016, at 3:10 PM, George Fletcher <> wrote:
> 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: <>