Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-discovery-08: (with DISCUSS and COMMENT)
Adam Roach <adam@nostrum.com> Wed, 24 January 2018 21:14 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9235C129C6B; Wed, 24 Jan 2018 13:14:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 gIY5I8B7d-e5; Wed, 24 Jan 2018 13:14:09 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 49C32129966; Wed, 24 Jan 2018 13:14:09 -0800 (PST)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0OLE4Pw025327 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 Jan 2018 15:14:05 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>, Michael Jones <Michael.Jones@microsoft.com>, "draft-ietf-oauth-discovery@ietf.org" <draft-ietf-oauth-discovery@ietf.org>, IESG <iesg@ietf.org>, "Hannes.Tschofenig@gmx.net" <Hannes.Tschofenig@gmx.net>, "oauth@ietf.org" <oauth@ietf.org>
References: <151667531481.29516.15285531314696206411.idtracker@ietfa.amsl.com> <SN6PR2101MB0943BC380296B9DBD12E4EF1F5E20@SN6PR2101MB0943.namprd21.prod.outlook.com> <c0295c9d-2606-1fca-d22c-52eed94fba1e@nostrum.com> <CAANoGhKCTvtdDNZk5Y1+E+U557k+GbYa1_TP=p5aJQEDk2NKdQ@mail.gmail.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <ee9f70b6-b68d-a07d-1afd-d9282655fb76@nostrum.com>
Date: Wed, 24 Jan 2018 15:13:59 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <CAANoGhKCTvtdDNZk5Y1+E+U557k+GbYa1_TP=p5aJQEDk2NKdQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/9hC3_A_ZyQ7608Twt7gWvlWYRE0>
Subject: Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-discovery-08: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 24 Jan 2018 21:14:11 -0000
On 1/24/18 2:07 PM, John Bradley wrote: > Mike and I are discussing with the other authors how we can address > this while minimising developer confusion, given that a large number > of implementations use the existing construction. Thanks. I'm not unsympathetic to the deployment issues here, and I think there's room for defining a migration path for both servers and clients. From the perspective of OAuth service operators, I'll point out that putting in place a programmatic "301 Moved Permanently" redirect to handle older clients is pretty trivial; e.g. Apache's mod_rewrite can accomplish this like so: RewriteRule "^/(.+)/\.well-known/(.+)" "/.well-known/$2/$1" [R=301] Ideally, the document would have a short non-normative discussion of the operational issues related to migration from pre-standard to standard deployments that covers this topic. (If the multi-tenancy arrangement on the server only gives tenants access to URL subtrees, it is certainly within the operator's purview to reverse the sense of this redirection so that tenants have the ability to modify their own discovery documents -- so long as it's not the *specification* requiring such a naming scheme, doing so is completely in the spirit of the web architecture). For the clients -- as long as the document makes it clear that the old format is deprecated, I'm not opposed to text that requires clients to first check the correct location (under the top-level /.well-known directory), and if (and only if) it receives a 404 (and only a 404) response, says that the client MAY then check the /.../.well-known location for compatibility with pre-standard servers. This would need to include language that the body of the response from the /.../.well-known query might contain something completely unexpected and unrelated to OAuth (as site administrators choose the meaning of URLs in general), and that they need to be prepared to deal with that. This client behavior should be configurable by administrators and/or end-users, and ideally default to off. In both cases, I would also expect a forward-looking statement saying that clients and servers are expected to discontinue this behavior at some point in the future. /a
- [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oau… Adam Roach
- Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf… Mike Jones
- Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf… Adam Roach
- Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf… John Bradley
- Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf… Adam Roach