Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Nat Sakimura <sakimura@gmail.com> Thu, 25 February 2016 15:16 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 A02E81B2A2C for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 07:16:56 -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 pNHhvIXD9NoX for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 07:16:49 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 0403C1B2A2A for <oauth@ietf.org>; Thu, 25 Feb 2016 07:16:49 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id s5so20511503qkd.0 for <oauth@ietf.org>; Thu, 25 Feb 2016 07:16:48 -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=x1CWDjwAi95I/8OO3Qy4ouCZ8mYlMBDyonTazf6CgKg=; b=aAS47PnzJid8fV5WpGoIPzb3Fg/p00VFbhXHjpZbU2YKrlKmQmNkQITRm9ITaD3Xdu a370KVMBdMYG5lbnXOnf1BvdeNNPi8Zvl1wVmUvRiJVH41svGMbAjjaYFDH2CS6DPBnA 9wkyvVugWU5T6eEv1HMYipFf92KQcgJlUouraOfSYEnDNZt9SFdlW23P0PN2g5xOglcl QzZNpBqnZd+2gRGzjTSrI+704MeUYUjpGcQwl2ufnpQCOJ0g38NrYgsehzTzwptUZPs3 8uHDWcgQPP5Dwmhk9CjNGaIIRCf1iMAS/Jso1cn5BWVgZbrXIDqpYJS6CvZ0PPR7qoSu Nmtw==
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=x1CWDjwAi95I/8OO3Qy4ouCZ8mYlMBDyonTazf6CgKg=; b=Bd+rCd9OqdkNKKei2cCAn6vkRfuUa2oO8pLbtTJ9+Z/iOYBer/f4/gBbkhaVPC/jXb Rw+Ka5gV6bJ1oDCGxYa9cxfNNzFyyG+1ZvR+ZHSfHkWGY+Xi0BXt7/L7gPrMhx0efKnF fMd5QuHLpOAhNOxfskMziPVkklNKLtz8UX5toS3ERfZazCB/AEe0D3+OTKAk5fo2iqIC bNRh5ET4ZDQaRRFh0HG0XeUWw2qZAS5y5aHKx7b8dUrKPTq3EupRLgH1QmzZBriEdfuw U0sqm1Q0kOPAep5KReIpkqiNNjEMEm3hTECuqemKqn3fqGmaHvE6nz+DD886uD5csvJp zpjA==
X-Gm-Message-State: AG10YOTeywmlS3AHgFoInw38EPhN3LWEiey5V3uTE/hZMX+mBwNvYr5uQ0T/N9nWfZaxjVSOKBOieNMV+AMufw==
X-Received: by 10.55.200.215 with SMTP id t84mr41463558qkl.55.1456413407997; Thu, 25 Feb 2016 07:16:47 -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> <005801d16fd5$37557680$a6006380$@reminetworks.com>
In-Reply-To: <005801d16fd5$37557680$a6006380$@reminetworks.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Thu, 25 Feb 2016 15:16:37 +0000
Message-ID: <CABzCy2AVqjgH4=Fdia7AzM1DwmWXXXY4kvp8sxy+OR_drN033Q@mail.gmail.com>
To: "Donald F. Coffin" <donald.coffin@reminetworks.com>, Vladimir Dzhuvinov <vladimir@connect2id.com>, oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a113c259ad476dd052c99ab3c
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/KYh4tev8EjS-RRf96VRne9jtisA>
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:16:56 -0000

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>om>:

> 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:       donald.coffin@reminetworks.com
>
>
>
> *From:* Vladimir Dzhuvinov [mailto:vladimir@connect2id.com]
> *Sent:* Thursday, February 25, 2016 2:23 AM
> *To:* 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 <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
>