Re: [OAUTH-WG] OAuth 2.0 Discovery Location

"Donald F. Coffin" <donald.coffin@reminetworks.com> Thu, 25 February 2016 16:00 UTC

Return-Path: <donald.coffin@reminetworks.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37871B2BD1 for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 08:00:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.656
X-Spam-Level:
X-Spam-Status: No, score=-1.656 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, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WG3M-gtbFgaW for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 08:00:25 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id D6FE21B2B8B for <oauth@ietf.org>; Thu, 25 Feb 2016 08:00:17 -0800 (PST)
Received: (qmail 8323 invoked by uid 0); 25 Feb 2016 16:00:17 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 25 Feb 2016 16:00:17 -0000
Received: from host125.hostmonster.com ([74.220.207.125]) by cmgw2 with id Ng081s01A2is6CS01g0Bdd; Thu, 25 Feb 2016 09:00:15 -0700
X-Authority-Analysis: v=2.1 cv=PPOcp5aC 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=ltxWCLULAAAA:8 a=lMGwIrbWAAAA:8 a=ZeOuHos7AAAA:8 a=UGkfVyPCAAAA:8 a=pGLkceISAAAA:8 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=yPCof4ZbAAAA:8 a=zDRtsbTxj6EWpDovZnQA:9 a=VXlICBlxRRo6oTjr:21 a=cxPuIWkRSe62yl-k:21 a=QEXdDO2ut3YA:10 a=3uZdkJafswoA:10 a=VQchPmBwTIUA:10 a=0y4QJ6oqqkIA:10 a=wNReZwrxAf8A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=Kk4do6bY5ODKTUgZ8doA:9 a=wBXmA1PrY2QCadme:21 a=zvOkkUvulv5JAng0:21 a=bgFutV5mEhZ3lm_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; d=reminetworks.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=gtB9T/7LNlMsMr7K/eatLUDoOx7UiJL0ZHfycTP1Jio=; b=bM3M9YyuMWsioNeNTScBHOM0DsfWqHkqoH5ivHNhspAklEmyOmJQchybvG22evSgpHmMp3hc+SdZ2dcEdeuC22vzgT2sRryOTE0pQh4f2jhAOcfrZE/BV7VNQlvEwZig;
Received: from [162.206.229.38] (port=3634 helo=HPPavilionElite) by host125.hostmonster.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <donald.coffin@reminetworks.com>) id 1aYyKo-00020J-23; Thu, 25 Feb 2016 09:00:10 -0700
From: "Donald F. Coffin" <donald.coffin@reminetworks.com>
To: "'Nat Sakimura'" <sakimura@gmail.com>, "'Vladimir Dzhuvinov'" <vladimir@connect2id.com>, <oauth@ietf.org>
References: <E3BDAD5F-6DE2-4FB9-AEC0-4EE2D2BF8AC8@mit.edu> <CAEayHEMspPw3pu9+ZudkMp9pBPy2YYkiXfPvFpSwqZDVyixWxQ@mail.gmail.com> <CABzCy2CpSB2Nrs-QoaEwpqtG4J8UNeAYNy1rion=mp5PQD2dmg@mail.gmail.com> <FE60D9CC-0457-4BDB-BCF1-461B30BF0CDE@oracle.com> <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com> <56CEABBD.1040602@connect2id.com> <005801d16fd5$37557680$a6006380$@reminetworks.com> <CABzCy2AVqjgH4=Fdia7AzM1DwmWXXXY4kvp8sxy+OR_drN033Q@mail.gmail.com>
In-Reply-To: <CABzCy2AVqjgH4=Fdia7AzM1DwmWXXXY4kvp8sxy+OR_drN033Q@mail.gmail.com>
Date: Thu, 25 Feb 2016 10:57:58 -0500
Organization: REMI Networks
Message-ID: <00ac01d16fe5$4e1555b0$ea400110$@reminetworks.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01D16FBB.65412270"
X-Mailer: Microsoft Outlook 15.0
Content-Language: en-us
Thread-Index: AQErEGUxIthpCNQAgVnbL+9JTvjuPAKQYZUXAMzfEkkBvAxTnwHmAZgaAtiXPCUBaONgBwGrEpF8AmD4XBKgD0EfIA==
X-Identified-User: {1395:host125.hostmonster.com:reminetw:reminetworks.com} {sentby:smtp auth 162.206.229.38 authed with donald.coffin@reminetworks.com}
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/sGOjo3KnzR8Ot1m-y30KV8fYPvs>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Feb 2016 16:00:28 -0000

Nat,

 

The information that will be used to update the NAESB REQ.21 Standard can be found at http://greenbuttondata.org.  The document that defines the Authorization requirements is referenced as the “GreenButton Implementation Agreement <http://osgug.ucaiug.org/sgsystems/OpenADE/Shared%20Documents/Testing%20and%20Certification/GreenButtonTestPlan/referenceMaterial/GreenButtonAuthorization.docx> ”.   The current NAESB REQ.21 Standard is available on the NAESB Website, but is a copyrighted standard and cost $250.00.  However, NAESB does provide the standard for evaluation purposes, by contacting the NAESB office at naesb@naesb.org <mailto:naesb@naesb.org> .

 

The Green Button website is the technical repository for the Green Button initiative.  Therefore, there are several technical documents and videos available.  Let me know if you need help finding anything.

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

 

Phone:      (949) 636-8571

Email:        <mailto:donald.coffin@reminetworks.com> donald.coffin@reminetworks.com

 

From: Nat Sakimura [mailto:sakimura@gmail.com] 
Sent: Thursday, February 25, 2016 10:17 AM
To: Donald F. Coffin <donald.coffin@reminetworks.com>om>; Vladimir Dzhuvinov <vladimir@connect2id.com>om>; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location

 

Interesting. Is there a link that I can download your spec etc. ? 

 

I have not much preference over the actual endpoint link or the web origin. As long as the semantics is clear, either is fine. 

I was even considering using URI template. It will be extremely flexible, but I am not sure about the current status of the library availability and its qualities. 

 

Re: RFC5988 header or JSON - If you go back to earlier drafts, I was using JSON. This will make it independent of HTTPS. 

Also, developers can just process the JSON and store it in JSON. This is a overall win. 

Downside is that there is no standard for doing JSON metadata. Since Swagger is using JSON Schema way of expressing it, perhaps that's the way we should go, though, HAL seems to be a bit more efficient and nice. 

 

In either way, though, IMHO, it is important to define the link relation in the RFC5988 IANA registry. 

Converting RFC5988 link header to either JSON schema metadata or HAL is trivial. 

 

Nat

 

 

2016年2月25日(木) 23:05 Donald F. Coffin <donald.coffin@reminetworks.com <mailto:donald.coffin@reminetworks.com> >:

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,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

 

Phone:      (949) 636-8571

Email:        <mailto:donald.coffin@reminetworks.com> donald.coffin@reminetworks.com

 

From: Vladimir Dzhuvinov [mailto:vladimir@connect2id.com <mailto:vladimir@connect2id.com> ] 
Sent: Thursday, February 25, 2016 2:23 AM
To: oauth@ietf.org <mailto:oauth@ietf.org> 


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.

+1 

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

Cheers,
Vladimir



--
James Manger
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
Sent: Thursday, 25 February 2016 6:17 AM
To: Phil Hunt  <mailto:phil.hunt@oracle.com> <phil.hunt@oracle.com>om>; Nat Sakimura  <mailto:sakimura@gmail.com> <sakimura@gmail.com>
Cc:  <mailto:oauth@ietf.org> <oauth@ietf.org>  <mailto:oauth@ietf.org> <oauth@ietf.org>
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





_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org> 
https://www.ietf.org/mailman/listinfo/oauth

 

_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org> 
https://www.ietf.org/mailman/listinfo/oauth