Re: [OAUTH-WG] OAuth 2.0 Discovery Location

"Donald F. Coffin" <> Thu, 25 February 2016 14:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6DE2D1ACD97 for <>; Thu, 25 Feb 2016 06:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8iemSVgRtmF3 for <>; Thu, 25 Feb 2016 06:05:13 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id DCAB51ACD8D for <>; Thu, 25 Feb 2016 06:05:12 -0800 (PST)
Received: (qmail 21390 invoked by uid 0); 25 Feb 2016 14:05:10 -0000
Received: from unknown (HELO cmgw4) ( by with SMTP; 25 Feb 2016 14:05:10 -0000
Received: from ([]) by cmgw4 with id Ne501s00L2is6CS01e531a; Thu, 25 Feb 2016 07:05:10 -0700
X-Authority-Analysis: v=2.1 cv=FouWoQbq c=1 sm=1 tr=0 a=Ux/kOkFFYyRqKxKNbwCgLQ==:117 a=Ux/kOkFFYyRqKxKNbwCgLQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=rE68L1KyjUoA:10 a=zwqKzj3qmOAA:10 a=jFJIQSaiL_oA:10 a=DAwyPP_o2Byb1YXLmDAA:9 a=UGkfVyPCAAAA:8 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=yPCof4ZbAAAA:8 a=pGLkceISAAAA:8 a=NFueVOWuk3jI_zvwBjoA:9 a=nH-AxX8ehqZ9UqIl:21 a=q-ZBoqf_T34So_gV:21 a=CjuIK1q_8ugA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=wNReZwrxAf8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=bWs5RZA5M6ZyPJ5mhQkA:9 a=CX4EYopR1YCGR3Df:21 a=AE06R1NIepf5Sbba:21 a=hkzjEweyeugLRY_W:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=rBlN2L6iEtDBreCVHp3lRj25zKjdVrBsd+xSDRijvQU=; b=izQOvKU3L148ZaAowwsgI7+bGK59sfVjM5hUPmGshOsu3iXY1yvjn29YOsPcA6jVumwtDahc9iwU1PGflrIT8BalhndjBKjx2W9wfdlNGMwuaNoL4NmK7qy+s2S7pNcv;
Received: from [] (port=2072 helo=HPPavilionElite) by with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <>) id 1aYwXL-0003P9-Ub; Thu, 25 Feb 2016 07:05:00 -0700
From: "Donald F. Coffin" <>
To: 'Vladimir Dzhuvinov' <>,
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Thu, 25 Feb 2016 09:02:48 -0500
Organization: REMI Networks
Message-ID: <005801d16fd5$37557680$a6006380$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01D16FAB.4E807FF0"
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AQErEGUxIthpCNQAgVnbL+9JTvjuPAKQYZUXAMzfEkkBvAxTnwHmAZgaAtiXPCUBaONgB6AvgYbg
X-Identified-User: {} {sentby:smtp auth authed with}
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 14:05:16 -0000

In fact, this is the method being used by utilities implementing the Green
Button Connect My Data interface (North American Energy Standards Boards'
(NAESB) Retail Energy Quadrant 21 (REQ.21) Standard (Energy Service Provider
Interface - ESPI).  The Green Button Alliance is in the processing of
updating the specification to use OAuth 2.0.  The industry OpenADE Task
Force, which is the technical WG of the UCAIug, defined additional
information be returned with the OAuth 2.0  Token Response that includes the
URI of the resource to which the AT can be used.


Best regards,


Donald F. Coffin



REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221


Phone:      (949) 636-8571

Email:        <>


From: Vladimir Dzhuvinov [] 
Sent: Thursday, February 25, 2016 2:23 AM
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location



On 25/02/16 09:02, 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.


This will appear more consistent with the current experience, and OAuth does
allow the token response JSON object to be extended with additional members
(as it's done in OpenID Connect already).


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
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.

OAuth mailing list <>