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

[Adam Roach <[e-mail]>]

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