Re: [OAUTH-WG] OAuth 2.0 Discovery Location

George Fletcher <gffletch@aol.com> Thu, 25 February 2016 15:25 UTC

Return-Path: <gffletch@aol.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 053F61B2A47 for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 07:25:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp1L_Bgo48d2 for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 07:25:28 -0800 (PST)
Received: from omr-a002e.mx.aol.com (omr-a002e.mx.aol.com [204.29.186.56]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB361B2A48 for <oauth@ietf.org>; Thu, 25 Feb 2016 07:25:24 -0800 (PST)
Received: from mtaout-aaj02.mx.aol.com (mtaout-aaj02.mx.aol.com [172.27.3.206]) by omr-a002e.mx.aol.com (Outbound Mail Relay) with ESMTP id 710C238000A3; Thu, 25 Feb 2016 10:25:23 -0500 (EST)
Received: from [10.172.228.63] (unknown [10.172.228.63]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aaj02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2403738000095; Thu, 25 Feb 2016 10:25:21 -0500 (EST)
To: 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>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <56CF1CEB.8030603@aol.com>
Date: Thu, 25 Feb 2016 10:25:31 -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: <56CEABBD.1040602@connect2id.com>
Content-Type: multipart/alternative; boundary="------------020209010607070507080606"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1456413923; bh=0C7LGN4e+OmKwWO4ZqNJSBL77xXmyOYNZhbCdBniQ2c=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=W+W82pKpCzmbhTgqUh0impRhwxwHJL7rFZ7IKBWKX1tXBs2RhEHny18uqXNwuKrRl bidZYlqqvSWuj/Ws5uh27Wo4iAyg3/J0lLn0vbrExNKU5z1DsqfMgrFaZ8x+oo84uS GQ5d9wcBVQcPXN/juJHTLR98HEoYHXjkF5PQGDxo=
x-aol-sid: 3039ac1b03ce56cf1ce1088e
X-AOL-IP: 10.172.228.63
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/K1d1BeDUs4L9WrN2oma9uDL0asI>
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 15:25:31 -0000

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>om>; Nat Sakimura<sakimura@gmail.com>
>> Cc:<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
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth