Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Vladimir Dzhuvinov <vladimir@connect2id.com> Thu, 25 February 2016 15:52 UTC

Return-Path: <vladimir@connect2id.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 61CFD1B2B3B for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 07:52:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 K7v_D5A7lvQf for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 07:52:11 -0800 (PST)
Received: from p3plsmtpa06-04.prod.phx3.secureserver.net (p3plsmtpa06-04.prod.phx3.secureserver.net [173.201.192.105]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 578581B2B07 for <oauth@ietf.org>; Thu, 25 Feb 2016 07:52:11 -0800 (PST)
Received: from [192.168.0.104] ([77.77.164.50]) by p3plsmtpa06-04.prod.phx3.secureserver.net with id Nfs91s00215ZTut01fsAhD; Thu, 25 Feb 2016 08:52:10 -0700
To: 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> <56CF1CEB.8030603@aol.com> <56CF1D79.1070507@aol.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <56CF2328.5030500@connect2id.com>
Date: Thu, 25 Feb 2016 17:52:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56CF1D79.1070507@aol.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050505000803010908040903"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Nt1gzq2RmMTQl0vDgn09c4dtoFY>
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:52:13 -0000

I made a mistake in my response (good to never rush things :)

My +1 was for moving the suggested metadata params from the "Link"
header to the JSON object that represents the token response. Because in
there we already have the token itself and associated metadata
(expiration and scope).

I still haven't made up my mind about the spec as a whole though.

On 25/02/16 17:27, George Fletcher wrote:
> 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>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
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>