On 11/17/2011 07:24 AM, Justin Richer wrote:
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.
I think this is really the key problem. To date, there isn't a
unified library that clients and servers are using that could
force this issue: every server/site is rolling their own oauth
sdk, and they don't have much reason *now* to change that.
If/when something emerged as being the oauth equivalent of
openssl, then it would make sense to tighten requirements on
such a library to achieve better interoperability. It would also
coincide with actual real world _knowledge_ of what the
appropriate MUST-IMPLEMENT's are instead of guessing.
All a mandatory requirement will do now is alienate a lot
implementations who are otherwise striving to be compliant.
So my bottom line to Stephen: defer this to a later recycle of the
rfc.
Mike
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
