>> Client simplicity (code and mental model). > > I think the difference in simplicity between one parameter and two is not > such that it requires munging the two together. > > The token_string and the token_format are two different parts of the token.
If you look through my emails, I provided code samples to illustrate that two parameters is in fact more complex than one. Much of the simplicity of OAuth 2.0 is achieved by unifying myriad parameters into a single access token. Much of that is lost by splitting it apart again. We can't even agree what we want or how to split it - some want origin, some want format, still others probably want something else. No, the whole point is it's up to the provider and the resource to unify them and it's opaque to the client. Again: can you provide a specific, real-world example where this is necessary? I'd rather not deal in hypotheticals. I've already answered the case of a hypothetical endpoint that accepts both SAML and JSON-encoded tokens. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
