There are various ways to indicate where a token can be used (when an authorization server issues a token to a client app).
A. List of URI prefixes B. List of scheme://host[:port] tuples C. List of domain names D. Any of the above lists with a wildcard to include all sub-domains, eg “sites”:[“https://*.example.com”] E. Regular expression I have been suggesting (B). HTTP Digest uses (A). (A) is a pretty good match to how Google uses scope values. (C) is a little simpler; but unacceptable because we should distinguish HTTP and HTTPS. A regular expression (E) could do the job. (D) can cover some virtual hosting situations where almost arbitrary numbers of sub-domains are continually created (eg per-user sub-domains). Eran asked for wildcards. If a wildcard is allowed I suggest only allowing a single “*.” prefix to the domain name. Its presence would mean all sub-domains (but not the parent domain, which can be specified separately if needed). Probably easiest to include sub-sub-domains etc. I could live with A, B, D, or E (just not C, and not nothing). Suggested text for B+D for the Access Token Response section: sites OPTIONAL. An array of strings indicating the sites where the token can be used. The optional “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 request that returned the token. site := scheme “://” [wildcard “.”] host [“:” port] 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. 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 host of the URI and string are equal, ignoring case, and (if the wildcard is present) ignoring one or more leading domain labels of the URI host. Example: “sites”: [“https://api.example.com”, “https://*.data.example.com”] The following URIs match (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 (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) -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
