David, > I think a strong argument should be presented from a security perspective as > to why it ["sites"] must be in the core spec itself versus documented as a > security consideration.
1. Using redirects and links to points across the web is core behaviour for many web clients and servers. 2. Bearer tokens are a core feature of OAuth2. 3. Combining 1 & 2 is only safe when a client can recognize when a link goes beyond an API (beyond the security context a bearer token was intended for). 4a. Redirects and links themselves don't include metadata about whether or not they leave an API. 4b. Relying on per-service per-response per-link documentation to determine the boundaries of an API is really limiting (and is not provided in practise). It cripples interop between clients and servers. 4c. A "sites" value provides the necessary details about where it is unsafe to use a bearer token. The web (it seems to me) is substantially built on clients being able to interop with servers even when the client has limited server-specific knowledge (eg web browsers are the ultimate client, browsing the web with almost no pre-configured knowledge about specific sites). Such clients are core to the web; should be core to OAuth2; and require "sites". -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
