On Thu, Dec 1, 2011 at 5:44 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > On 12/02/2011 01:38 AM, Michael D Adams wrote: >> 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. > > So I don't get your argument. (When thinking of interop.)
I think it's me that doesn't understand your argument. Suppose an authorization server implements OAuth2 and has some requirement that the MTI token type doesn't provide (as William Mills suggested), so the server implements token type AWESOME in addition to token type MTI. Whenever a token is requested, the authorization server issues one of type AWESOME. Type MTI is never issued. Why bother implementing type MTI if it's never used? Additionally, the authorization server could not implement type MTI but claim it did. There's no way for a third party to verify the claim since the authorization server never issues a token of type MTI. If tokens of type MTI are never used by this server, how does the MTI token type help interop? Is your argument that this server would say "No, we do not support OAuth2. We do, however, support OAuth2+AWESOME."? That semantic argument I understand, but I am ignorant as to how/if it fits into the RFC. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
