I'm with George. You can do introspection with no audience restriction.
We implemented introspection with only scope restriction from the RS.
-- Justin
On 3/18/2016 8:50 AM, George Fletcher 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?
On 3/18/16 3:09 AM, Thomas Broyer wrote:
Note that goal #2 is already taken care of by introspection (endpoint
varying response depending on authenticated client/RS), so maybe
should be refined here.
Le jeu. 17 mars 2016 18:44, George Fletcher <gffle...@aol.com> a écrit :
Goals:
1. Help the client not send a token to the "wrong" endpoint
a. wrong AS /token endpoint
b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was
intended
for that RS
Other high-level goals?
Use cases:
1. RS that supports multiple AS (we've had this in production
since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that
supports
the jabber API)
4. Client that dynamically supports new AS
Feel free to add to the list :)
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
