Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-discovery-08: (with DISCUSS and COMMENT)

Adam Roach <> Wed, 24 January 2018 21:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9235C129C6B; Wed, 24 Jan 2018 13:14:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.89
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gIY5I8B7d-e5; Wed, 24 Jan 2018 13:14:09 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 49C32129966; Wed, 24 Jan 2018 13:14:09 -0800 (PST)
Received: from Svantevit.local ( []) (authenticated bits=0) by (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
X-Authentication-Warning: Host [] claimed to be Svantevit.local
To: John Bradley <>
Cc: "" <>, Michael Jones <>, "" <>, IESG <>, "" <>, "" <>
References: <> <> <> <>
From: Adam Roach <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-discovery-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.