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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
