Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Nat Sakimura <sakimura@gmail.com> Fri, 26 February 2016 04:08 UTC

Return-Path: <sakimura@gmail.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 362F81A212A for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 20:08:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 nN-JVp3Wnjwk for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 20:08:43 -0800 (PST)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F4B1A1A02 for <oauth@ietf.org>; Thu, 25 Feb 2016 20:08:43 -0800 (PST)
Received: by mail-qg0-x231.google.com with SMTP id y89so57151314qge.2 for <oauth@ietf.org>; Thu, 25 Feb 2016 20:08:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=1fcdZG86367iRC5UHBUKypvMaUpSR/nrKJ3muMwZZFs=; b=0P7TIFcPzivZ6iPiblVz/idpaJyDVi//G0MmNdhRo7oLMn1fLgmtvSGhtt1z938LL1 sXPanN48eZ6K4hBhghkO/SOSEcTeqEbTmVyoyONTUSpw6FD2ccdHMxrhpzcL2yXhHyeq FBjB5jSNNXd9xjdKBkver2pADr29Ad6zkCpBnlJ5yIqJ3wIwMNy7kyNFWFOvHb7QAD+J m9jsgMbgU7kzXU9eAlWTDB6v9wg+w53L1OLToTAtHl+g2BQueSnLPuiy2Pu0y6u4L5lK Ha3faQDBDkRLmy4SG7/mROHen4vW3G1wZhnyGbfF4+Anb6sBqvitFzy5xgjkAive9Nxv 8s6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=1fcdZG86367iRC5UHBUKypvMaUpSR/nrKJ3muMwZZFs=; b=S0Y7vit10xvG6pD2wYqT/H35cviF1uUcbICaxx5MxWZNx5PBNymhlqHtA0pU8HCDRB zePReKdrlevI8Bz0OFUr9MxJ48ELS2cjRc3aa5CBNRk2KYIEr9m52GmiT1pEZQjLWw9W 7AGAkKjxcPZ8NoZ2Llms4DjxVDq2OUJKSB9EFgsj2BWqwfHFkmzwKxbQ6bL1SG2JqURe 1avlMLNzHcwIfeau1lKpw/ehVW7pSoWHGjE62qo4iR4CNOIhw9QaCe9DNnGyp9p1CdTT 0h817SYZ5kVLLidyiXwgZl18qZULA4vuO5ydV4O4RxJYbahK7zl/IlonB70s3CCbOCSQ rzKg==
X-Gm-Message-State: AG10YOQ+lAyafuwuQQc3srl4m3A/U2qtd4g+NbmhbwTIQSPA4kQFt/pDJKltL33NINe4y7Q0TvL7velNZifDlw==
X-Received: by 10.140.165.205 with SMTP id l196mr65529783qhl.58.1456459717403; Thu, 25 Feb 2016 20:08:37 -0800 (PST)
MIME-Version: 1.0
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> <255B9BB34FB7D647A506DC292726F6E13BBB019D97@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BBB019D97@WSMSG3153V.srv.dir.telstra.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Fri, 26 Feb 2016 04:08:28 +0000
Message-ID: <CABzCy2CaCM_rS7eU2-WO+kUKXQC6ctYwrAHfytNmHh1C3GpQxQ@mail.gmail.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>, George Fletcher <gffletch@aol.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary=001a1134f04c15e9f6052ca474cd
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/QcZErhO76eaSMwnD4pQu3cJOXZQ>
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:08:46 -0000

I will include the origin in the next rev.

For http header v.s JSON, shall I bring the JSON back in?
2016年2月26日(金) 13:05 Manger, James <James.H.Manger@team.telstra.com>om>:

> 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>om>; 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 <oauth-bounces@ietf.org>] On Behalf Of George Fletcher
>
> Sent: Thursday, 25 February 2016 6:17 AM
>
> To: Phil Hunt <phil.hunt@oracle.com> <phil.hunt@oracle.com>om>; Nat Sakimura <sakimura@gmail.com> <sakimura@gmail.com>
>
> Cc: <oauth@ietf.org> <oauth@ietf.org> <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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>