> 1. Should we specify some token type as mandatory to implement? Why > or why not (*briefly*)?
No, since I do not believe that the force of compliance with this one point of the spec will be enough to persuade those who don't want to use whatever the MTI token type ends up being to use it. Let's say that we were to pick Bearer, but Example.com decides to only support MAC for their API. Is it correct to say that Example.com is not really doing OAuth2? I would argue no, since they're doing everything within spec to issue tokens, and the tokens that they're issuing are well defined and within spec as well. So then let's say, hypothetically, that in order comply with the letter of the law, they implement a Bearer token as well as MAC. But which type do they issue to clients? Clients have no way of choosing or discovering which what kind of token comes back (yet). If Bearer is MTI, how do you even use another token type? Which brings us to MTI in clients, which makes even less sense. Let's say that I'm writing a client to talk to Example.com, which hands back MAC tokens. I want to comply with the spec, so I implement Bearer support in my client, code paths which will never see the light of day. Then there's the argument that a generic library is what's really meant by "client" here, and that those MUST follow the MTI guidelines. I also find this to be ludicrous, since client libraries will implement whatever servers support. A good client library will support *both* MAC and Bearer together, along with whatever magical tokens that haven't been dreamed up yet that are getting traction. Ultimately, I think that our declaring something MTI is a position of hubris that won't affect how people really use this thing. -- Justin _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
