Re: [OAUTH-WG] OAuth 2.0 Discovery Location

George Fletcher <> Thu, 25 February 2016 15:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 50A181B2A12 for <>; Thu, 25 Feb 2016 07:14:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q4cc2dxiiYEI for <>; Thu, 25 Feb 2016 07:14:07 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CC121B2A1A for <>; Thu, 25 Feb 2016 07:14:07 -0800 (PST)
Received: from ( []) by (Outbound Mail Relay) with ESMTP id 4BFA63800336; Thu, 25 Feb 2016 10:14:06 -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 2E15E3800008D; Thu, 25 Feb 2016 10:14:03 -0500 (EST)
To: "Manger, James" <>, "<>" <>
References: <> <> <> <> <> <>
From: George Fletcher <>
Organization: AOL LLC
Message-ID: <>
Date: Thu, 25 Feb 2016 10:14:13 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------030206080706040602040701"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; t=1456413246; bh=HdJRpY++Nmhhx8/T0j14Ef/fR78R7dfyh1ByQzBSJ4Q=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=IMf072lqd6enRJ+/9HRB/WTww77vS54c7Hbo2ICGsMEBaI3i4qzr/6KuhVZhdp6Nx 9xkY6cWWZ3gVIYOFkGUcqQqm/vUC6iBeJ0+0BpUgMmj71t7tIrHMeBCm6XisoSbfG+ H6RXeZXlJymx7Rs54RAj4rvnGOkPq6T2RUZlgNFk=
x-aol-sid: 3039ac1a7fe256cf1a3b047d
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
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: Thu, 25 Feb 2016 15:14:14 -0000

The AS knows the RS's that will consume it's tokens because it knows the 
scopes that it can allow the user to authorize. I don't think the AS 
MUST know the endpoints of the RS (which is what the current drafts 

It is not often that the entity/group responsible for the Authorization 
Service is also responsible for the actual resource server. Take for 
example a Mail API run by one team and the Authorization server managed 
by the Identity team.

Requiring the Mail Team to notify and coordinate the change of endpoints 
for a new deployment is brittle.

Also, I believe the main reason for wanting to bind a token to an 
endpoint is to protect the token from being sent to a malicious RS and 
then having that RS replay the token. If possible replay of a token is 
the main concern, then why not use PoP which ensures that only the 
appropriate client and present the token. This seems a much cleaner way 
to protect against this threat.


On 2/25/16 2:02 AM, Manger, James wrote:
> > I'm concerned that forcing the AS to know about all RS's endpoints 
> that will accept it's tokens creates a very brittle deployment 
> architecture
> The AS is issuing temporary credentials (access_tokens) to clients but 
> doesn’t know where those credentials will work? That’s broken.
> An AS should absolutely indicate where an access_token can be used. 
> draft-sakimura-oauth-meta suggests indicating this with 1 or more 
> “ruri” (resource URI) values in an HTTP Link header. A better approach 
> would be including a list of web origins in the token response beside 
> the access_token field.
> --
> James Manger
> *From:*OAuth [] *On Behalf Of *George 
> Fletcher
> *Sent:* Thursday, 25 February 2016 6:17 AM
> *To:* Phil Hunt <>; Nat Sakimura <>
> *Cc:* <> <>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
> I'm concerned that forcing the AS to know about all RS's endpoints 
> that will accept it's tokens creates a very brittle deployment 
> architecture. What if a RS moves to a new endpoint? All clients would 
> be required to get new tokens (if I understand correctly). And the RS 
> move would have to coordinate with the AS to make sure all the timing 
> is perfect in the switch over of endpoints.
> I suspect a common deployment architecture today is that each RS 
> requires one or more scopes to access it's resources. The client then 
> asks the user to authorize a token with a requested list of scopes. 
> The client can then send the token to the appropriate RS endpoint. The 
> RS will not authorize access unless the token has the required scopes.
> If the concern is that the client may accidentally send the token to a 
> "bad" RS which will then replay the token, then I'd rather use a PoP 
> mechanism because the point is that you want to ensure the correct 
> client is presenting the token. Trying to ensure the client doesn't 
> send the token to the wrong endpoint seems fraught with problems.
> Thanks,
> George