On Fri, 24 Aug 2012 11:24:46 -0700, Chris Steipp <cste...@wikimedia.org>
wrote:
On Fri, Aug 24, 2012 at 10:33 AM, Nabil Maynard <nadr...@gmail.com>
wrote:
On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo <tylerro...@gmail.com>
wrote:
Not a good idea: http://xkcd.com/927/
While OAuth has its problems, it's not a terrible protocol (or at
least v1
isn't).
Randall is right in general about standards proliferation for standards
sake.
But that's primarily about just writing a standard for other people to use.
If there are issues with the old standard, there is no significant
advantage to use of the old spec (besides the case that it already exists,
etc...), and you are intending to actually use the standard rather than
just throw it out for people to use. Then that's really a valid situation
to write a new standard in.
- OAuth 1 had some important issues too. In particular the temporary
credentials and the limitations on the user experience caused by the
single flow.
- The flow limitations is probably a big one for us. And it is possible to
work around the issue by separating OAuth into two parts. But by doing
that you diverge from the spec and there isn't much more reason to stick
with that standard. And afaik the libraries for doing OAuth 1 don't
support these alternative types of flows.
Seconded -- I'd rather see contributions to making OAuth less painful
rather than invent Yet Another Standard.
I have to agree too. OAuth has problems, but it would allow several of
wmf's current integrations to be more secure overall, and that would
be a win for us. If Daniel is able to create a protocol that is as
secure, and easier for developers to use securely, then I will
definitely push to switch over. But until then, I'm still going to try
and get OAuth out.
Thanks. I already know what I have lying around in my head will keep OAuth
1 level security while making signatures easier to implement. Although the
fundamental idea in this area is auth should always be done by a
library/SDK anyways.
The stuff making my head spin actually isn't even any part of the basic
auth. It's not even discovery itself. The hardest thing to figure out is
what to do about making discovery and dynamic registration over HTTP
secure.
Which frankly is something that no protocol has anyways.
The only problem with writing out an actual standard for the rest of the
stuff is all my good hours are taken up by work. The leftovers wouldn't be
enough to get out a good enough quality standard and reference/testing
implementation.
Rather than jumping to "get OAuth out" what about first trying to get the
fundamental base pieces we need for all of these into core. ie: Abstract
authorizations and applications. Revocation pages. Attaching an
authorization/application to changes like revisions, logs, etc... and
tools to mass-revert by confidential application or multiple public
authorizations.
We'll need that stuff no matter what we implement. And it's going to take
awhile just to implement those things.
We can decide whether we want OAuth or something else when we finally get
to that point.
I'd also love to see MediaWiki support SAML too, for our .edu/.gov users.
Did these organizations need to use those SAML credentials directly for API
things or is this just another method we want to support for logging in?
My personal wishlist:
- Persona: Previously called BrowserID. It's come a LONG way in the
past
few months, and provides another fairly clean identity/authentication
system.
Mozilla is also interested in this. I don't think we can use it on wmf
sites, but if you're interested in working on it, I can probably get
you in touch with someone there. I think it would be a great feature.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
