This is pretty much what we do today as well. The additional goal is to
specifically bind tokes to a particular resource outside the context of
the scope value. Just like in SAML, the RS would not process any token
which was not specifically created for use with that RS. So it's an
additional layer of protection beyond scopes.
Thanks,
George
On 3/18/16 9:59 AM, Thomas Broyer wrote:
On Fri, Mar 18, 2016 at 1:50 PM George Fletcher <gffle...@aol.com
<mailto:gffle...@aol.com>> wrote:
I was thinking of goal #2 as addressing the issue of audience in
the token. If the RS "authenticates" itself when calling
introspection, then the AS could apply the audience restriction
for the RS. Is that what you were thinking?
Yes (or I think so).
Scopes are declared in relation to "applications" (which can be either
clients or RS), and our introspection endpoint returns
{"active":false} if there's no matching scopes between what the
"application" has declared and those of the token.
We actually do "scope restriction" (only returning the scopes related
to the requesting application), with the added rule that if there's no
scope left we return {"active":false} rather than an empty list of scopes.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
