The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated by returning an identifier for the AS in the authorization response. It is something that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access tokens tokens don't help.
Maybe that's obvious but there seems to be a lot of confusion on all this so I wanted to reiterate it. On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher <[email protected]> wrote: > 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] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
