Justin, > The important thing is the logical distinction between > "place where the client goes" and "place where the client sends an end > user", and that those don't get folded into each other.
I certainly don't want to fold those two together. The issue is whether the spec should fold together all the reasons different clients can call an authorization server into a single place. > As you say below, there's nothing stopping a provider from defining > several concrete endpoints to handle different configuration sets. Yes & no. If there is truly nothing stopping a server from using several token endpoints then what is the point of the spec bother defining just part of that endpoint: the grant_type parameter & its extensibility? The only reason I can guess is so a future discovery spec can assume there is a single "place where the client goes", eg specify a Link relation that points to THE token endpoint (which won't work with providers using several concrete endpoints). > I think that in practice we'll see people writing a dispatch point to > process their different supported configurations. So people write extra code (the dispatch point) for what benefit? > I don't think further abstraction at the specification level will help things. I want less abstraction, not more. I am suggesting the spec can ditch the artificial "grant_type" abstraction. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
