If every client and every server needs to implement "/all the popular
mechanisms/" then that's not such a big deal when you're shipping the
client code for your own server as part of a website, but it's a big
deal if you're trying to create a general client and don't want to
have to hard-code the specific magic for each server provider.
So the reason to encode the authentication mechanism into JMAP was
precisely to reduce the number of possibilities.
I want to echo this as a something I also feel OAuth2 has failed at
(thusfar). We used to be able to point our user-agent at an endpoint,
get a WWW-Authenticate & 401, and the agent would be able to figure out
how to log the user in. I can't point my browser to an OAuth2 protected
endpoint and discover what an API offers.
With OAuth2 we need a ton of out-of-band information. I think this is
partially contributing to people not building generic HTTP clients, but
SDKs for each service. To some extent I think it's breaking the web.
I hope a future version of OAuth prioritizes server-driven oauth2
configuration.
Evert
P.S.: I do appreciate all the work that has gone in OAuth2, and this
specific criticism is not intended as an overall sentiment.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
