Re: [OAUTH-WG] OAuth 2.0 Discovery Location
"Manger, James" <James.H.Manger@team.telstra.com> Fri, 26 February 2016 04:05 UTC
Return-Path: <James.H.Manger@team.telstra.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 D1A521A0470 for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 20:05:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] 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 HfYreYSGh339 for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 20:05:19 -0800 (PST)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 588D81A0430 for <oauth@ietf.org>; Thu, 25 Feb 2016 20:05:16 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.22,498,1449493200"; d="scan'208,217"; a="60288856"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 26 Feb 2016 15:05:10 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8086"; a="83808666"
Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcavi.tcif.telstra.com.au with ESMTP; 26 Feb 2016 15:05:08 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3707.srv.dir.telstra.com ([fe80::ccc:aa8f:d2a6:740%28]) with mapi; Fri, 26 Feb 2016 15:04:59 +1100
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: George Fletcher <gffletch@aol.com>, "oauth@ietf.org" <oauth@ietf.org>
Date: Fri, 26 Feb 2016 15:04:57 +1100
Thread-Topic: [OAUTH-WG] OAuth 2.0 Discovery Location
Thread-Index: AdFv4RoBLzOniVFDSG+U6fXZhZuMagAZ7/Sw
Message-ID: <255B9BB34FB7D647A506DC292726F6E13BBB019D97@WSMSG3153V.srv.dir.telstra.com>
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> <56CF1CEB.8030603@aol.com> <56CF1D79.1070507@aol.com>
In-Reply-To: <56CF1D79.1070507@aol.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BBB019D97WSMSG3153Vsrv_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/KShRzQ-5vaMJv304hsNRThTPB48>
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: Fri, 26 Feb 2016 04:05:22 -0000
You are right, George, that making the AS track /v2/… or /v3/… in RS paths is likely to be brittle — but tracking RS web origins is not too onerous. PoP has some nice security advantages over bearer tokens or passwords. However, it should still be possible to use the latter fairly safely — but it does require the issuer of credentials to indicate where they can be used. -- James Manger From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher Sent: Friday, 26 February 2016 2:28 AM To: Vladimir Dzhuvinov <vladimir@connect2id.com>; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location That said, I'm not against the AS informing the client that the token can be used at the MailResource, ContactResource and MessagingResource to help the client know not to send the token to a BlogResource. However, identifying the actual endpoint seems overly complex when what is really trying to be protected is a token from being used where it shouldn't be (which is solved by Pop) Thanks, George On 2/25/16 10:25 AM, George Fletcher wrote: Interesting... this is not at all my current experience:) If a RS goes from v2 of it's API to v3 and that RS uses the current standard of putting a "v2" or"v3" in it's API path... then a token issued for v2 of the API can not be sent to v3 of the API, because v3 wasn't wasn't registered/deployed when the token was issued. The constant management of scopes to URI endpoints seems like a complexity that will quickly get out of hand. Thanks, George On 2/25/16 2:22 AM, Vladimir Dzhuvinov wrote: 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 <phil.hunt@oracle.com><mailto:phil.hunt@oracle.com>; Nat Sakimura <sakimura@gmail.com><mailto:sakimura@gmail.com> Cc: <oauth@ietf.org><mailto:oauth@ietf.org> <oauth@ietf.org><mailto: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 _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] OAuth 2.0 Discovery Location Justin Richer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Vladimir Dzhuvinov
- [OAUTH-WG] OAuth 2.0 Discovery Location Samuel Erdtman
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Samuel Erdtman
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Thomas Broyer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Justin Richer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Nat Sakimura
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Thomas Broyer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Nat Sakimura
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Nat Sakimura
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Anthony Nadalin
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Anthony Nadalin
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Manger, James
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Vladimir Dzhuvinov
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Vladimir Dzhuvinov
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Donald F. Coffin
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Nat Sakimura
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Vladimir Dzhuvinov
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Donald F. Coffin
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Thomas Broyer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Donald F. Coffin
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location John Bradley
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Manger, James
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Nat Sakimura
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location nov matake
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location John Bradley
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Justin Richer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location torsten@lodderstedt.net
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Samuel Erdtman
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Vladimir Dzhuvinov
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Brian Campbell
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Brian Campbell
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Roland Hedberg
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Vladimir Dzhuvinov
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Thomas Broyer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher