Below is text about the "sites" field in spec-ready detail to make it easier
for the editor.
There hasn't been unanimous support for this field amongst the long
discussions. However, my feeling is that most have recognised that it is needed.
[for 3.3.2.1. Access Token Response]
[add to the list of common parameters]
sites
OPTIONAL. Indicates the sites where the token can be used.
[add below the list of common parameters]
The "sites" field indicates where the issued token can be used. Its value is an
array of strings, where each string obeys the <site> production. If the "sites"
field is absent it MUST be treated as though the field was present with a
single string consisting of the scheme, host, and port of the site that issued
the token.
site = scheme "://" [wildcard] host [":" port]
; scheme, host, and port are defined in [RFC3986]
wildcard = "*."
The token MUST NOT be used with a request to a URI unless the URI matches at
least one string in the “sites” value. A token SHOULD be used pre-emptively
when the URI does match. Any string in the "sites" value that does not obey the
<site> production MUST be ignored. A URI matches a string if the following
conditions are all met:
1. The scheme of the URI and string are equal, ignoring case.
2. The port number of the URI and string are numerically equal, using the
default port number for a scheme if no port is specified (eg 443 for https).
3. The wildcard is absent and the host of the URI and string are equal,
ignoring case; or the wildcard is present and a "." followed by the host of the
string is a suffix of the host of the URI, ignoring case.
The following URIs match the example below (so the token should be used):
https://api.example.com:443/xyz?q=1
HTTPS://WWW.IMG.DATA.EXAMPLE.COM/786856.jpg
The following URIs do NOT match the example below (so the token must not be
used):
http://api.example.com/index.html (wrong scheme)
https://data.example.com/4254.json (host not a sub-domain)
[add the following line to the example HTTP response]
"sites": ["https://api.example.com";, "https://*.data.example.com";],
[may need to reference the ABNF RFC (instead of httpbis for ABNF?)]
[RFC5234] "Augmented BNF for Syntax Specifications: ABNF"
[end of spec text]
Potential issues:
* Internationalized domain names: the text above implies toASCII domain names
appear in "sites" (by using <host> from RFC3986 URI, not <ihost> from RFC3987
IRI)
* <wildcard> doesn't make much sense if <host> is an IP addresses, but isn't
harmful
* draft-abarth-origin offers more rigorous rules for scheme/host/port origins
* ignoring strings that don't match <site> provides some room for
extensibility, while being fail-safe for earlier client apps
--
James Manger
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
