Dick, > 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.
This is no longer a bearer token. It is a token bound to a public key (eg like an X.509 certificate, or (more likely) a SAML assertion with <SubjectConfirmation>...holder-of-key</..>). I can see that such non-bearer tokens don't necessarily need a "sites" field to ensure their security. "sites" is required to keep bearer tokens secure. Hence, the token response needs to tell the client a bit more about the nature of the token. > 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. The "sites" parameter DOES preclude this capability. It says "OPTIONAL", but this actually means "a default value is defined". The default is that the token can only be used at the site that issued it, which is not what you want. Suggested solution: define a special string "*" that, when present in the "sites" array, means the token can be used anywhere without compromising its security (eg "sites":["*"]). Alternative 2: set "sites":null when a token can be used anywhere. Alternative 3: don't define a default; absence of "sites" means the token can be used anywhere; "sites" is required even if the token can only be used at the site that issued it (eg Facebook needs to add "sites":["https://graph.facebook.com";]). This alternative is not quite so fail-safe (forgetting "sites" is insecure). -- James Manger From: Dick Hardt [mailto:dick.ha...@gmail.com] Sent: Monday, 17 May 2010 4:58 AM To: Manger, James H Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Spec text for "sites" field 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
