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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
