Looking over the previous threads, I don't think an important capability was pointed out that we want to preserve:
The AS may NOT need or want to know where an access token is used. In other words, the access token could be viewed as a claim that can presented to an arbitrary resource to gain access. This enables new resources to be deployed without having to *register* them at the AS. One way to deal with the security issues of a bearer token is to signing with a private key belonging to the client which prevents reuse of the access token by an unscrupulous PR as the signed request will be bound to that PR. The proposal below does not preclude this capability as written as the sites parameter is optional, so I am not suggesting a change, but am pointing out the capability. -- Dick On Sun, May 16, 2010 at 7:09 AM, Manger, James H < [email protected]> wrote: > 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 >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
