>> So an MTI token type + no client preference is equivalent to there >> only existing one token type. > > Maybe. > > However, no MTI token type + no client preference = no interop.
I think this exchange, coupled with what you Stephen said in Taipei (noting that "mandatory to implement" doesn't mean "mandatory to use"), points out a basic difference between how Stephen is thinking about this and how at least some of the WG participants are. Let me see if calling this out helps: Stephen is thinking that code will be reused. Perhaps there'll be a limited number of coded toolkits, and their code will be used to implement various authorization servers, etc. That's the way a lot of Internet code is done today. In that case, Stephen posits, if we tell the toolkit writers that they MUST implement X, then at least when X is being used, implementations based on the different toolkits can always interoperate. Lacking that directive, a toolkit that only implements X will be unable to interoperate with a toolkit that only implements Y. Others are thinking that deployed code will be specific to a particular environment, and it doesn't help at all for that code to support X if the environment demands Y. There's no interop benefit from the "MUST implement X" directive if the code has been written specifically for that environment, and, as Mike T says, it only results in untested code and wasted development time. I see both sides of this, but in the end I think what Mike says is spot on, here. I think it would be very nice to strongly encourage toolkit writers to support all the available options, but there's absolutely no reason to require, and no benefit in requiring, purpose-built code to do anything of the sort. Maybe what would work best is some text that suggests what I say above: that toolkits intended for use in implementing OAuth services in general... implement [X and/or Y], and that code written for a specific environment implement what makes sense for that environment. It seems to me that to require any particular implementation in the latter case is arbitrary and counter-productive, and doesn't help anything interoperate. Whereas general-purpose toolkits that implement everything DO help interop. Barry, as participant _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
