Evan, > The key point is that this discovery covers a lot of the same grounds as the > sites parameter, and it's hard to define semantics around a sites parameter > without understanding the semantics of scopes and API endpoints.
I strongly disagree. The semantics are crystal clear: "Here is a token. It is INSECURE to send it anywhere not in this list." These semantics are useful regardless of what the API does, how the client is using it, or how much (or how little) the client knows about the API. > Clients need to [know] more about these links (at least the response format). That knowledge comes from other standards (HTML, Atom, wiki of rel values...) and is totally independent of whether a token should or should not be sent. > The mechanism they use to find out about these links - documentation, > discovery, data returned with token request - could also provide the > information about whether a token should be sent to a particular API. Could, but shouldn't and doesn't in practise. It is much much better to have the information about how to use a token securely delivered at the same time & place as receiving that token, and with minimal assumptions about how much the client apps knows about the service. > I should be more concrete about the use cases I see. Let's assume there's an > API where there are two endpoints, each with an associated permission > - contacts.list permission -> > http://contacts.serviceprovider.com/contacts/list > - calendar.get permission -> http://calendar.serviceprovider.com/calendar/get > > If the response to an authorization request includes the authorized scopes > (contacts.list, calendar.get), then the "sites" parameter is redundant. I'll admit that "sites" is redundant if a client has *perfect* knowledge about a service, but so is pretty much any standard at that point. Consider a generic search spider tool that you point at http://calendar.serviceprovider.com/calendar/get. It can do its job with no knowledge about what "calendar.get" means -- but it still needs to know (as it spiders along) when it is safe to expose the token. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
