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

Reply via email to