I'd like opinions on whether including OAuth support in Firefox would
be of interest, and how folks would like to be able to access it.
I know that both Flock and MozLabs have each created JS OAuth
implementations, so there is at least a starting place, but I would
want input on interface design, need for XPCOM, as well as where it
should live, etc.
-lilmatt
Big +1.
I've seen a lot of interest lately around OAuth/OpenID in the browser
(yes they are separate). But making it easier and less costly for
folks to "do the right thing" in terms of managing access to user data
is a good thing for the open web and for Firefox.
And, I think that Weave is going to be using OAuth anyway?
Chris
Will that be before or after you re-enable IM usage, accept more
Jabber PubSub requests, achieve 99.9% uptime, remove deleted accounts
automatically from following/followed, and bring back Track?
Please don't hijack the thread.
Thanks
-lilmatt
> I've seen a lot of interest lately around OAuth/OpenID in the browser
> (yes they are separate). But making it easier and less costly for
And for the purposes of this conversation, I'd suggest we leave them
as separate so that we don't conflate this discussion (which is well
scoped to OAuth).
> And, I think that Weave is going to be using OAuth anyway?
Yeah, I think that's what lilmatt meant when he said that Mozilla Labs
had worked up a version.
What's involved in baking it into the product?
cheers,
mike
According to cbeard's and thunder's presentation at the Mozilla
Summit, Weave is already using OAuth. So we've already written this
in JS twice so far. :)
Flock's implementation is at:
http://lxr.flock.com/source/flock/mozilla/flock/modules/FlockOAuthLib.jsm
The implementation Flock wrote is a generalized .jsm, but it was
written for one service's authentication at this point, so it may not
be generalized enough. For example I believe there are other signing
algorithms in use at this point. I also seem to remember some crypto/
hash helpers recently landing that we're obviously not using.
I wanted to learn about other use cases such as extensions, and if
there was a need for XPCOM interfaces for it. I wonder also if there
is a need to expose it to the user at this point or not. If so
there's UI to design and debate.
-lilmatt
http://hg.mozilla.org/labs/weave/index.cgi/file/tip/modules/oauth.js
Which landed as part of this patch:
http://hg.mozilla.org/labs/weave/index.cgi/rev/d5e462bd195e
Some things to note:
* We have to do some crypto work after the user authorizes the data
sharing, so we intercept the redirect and do it there. That means the
user can only share on a Weave-enabled browser (Firefox 3 + Weave).
* We decided to just implement the auth locally in XUL (see oauth.xul).
* This is not production code.
Dan
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
I know you're mostly just throwing an idea out there to see if it
sticks, and I hope this doesn't sound like I'm stomping on it because
that's not at all my intent. It's just hard to assess whether it's a
good idea or not without a little more concrete sense of what the idea
*is*.
I wonder, as well, how amenable this kind of thing would be to
implementation in an add-on as a testing ground. I could see a way
forward that went:
- Talk with the OAuth folks about what the low-impact JS API would
be here
- Build out an add-on and get a couple of OAuth-using sites to use
it, when available (obviously this is an easier sell if it is at least
partially transparent)
- Iterate with an eye towards standardization and uplift
I don't think we'd need to gate our implementation on getting a
standard carved in stone, but it seems silly to not be thinking
standardization for something that is, at the end of the day, an
interop technology.
I'm sure you've already thought about all of this, but it's Monday, so
I need it spelled out a little more clearly. :)
Cheers,
Johnathan
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
---
Johnathan Nightingale
Human Shield
joh...@mozilla.com
Johnathan, have also a look at this: http://code.google.com/p/idib/
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
> Do both end-points have to be aware of the API, or can it be invisible to one of them?
Invisible to the remote endpoint.
> Do we know whether the OAuth gang are interested in this kind of integration?
They're interested in initiatives that help increase the penetration
of OAuth, so yes.
I could also envision a unified authz revocation panel where you can
prevent Myspace from talking to Flickr on your behalf, etc. That
would require more protocol work however, as there is no canonical
repository of all the authz you have or have not granted across the
entire internet. We could cache what we know about via your browsing
sessions, but that is not guaranteed to be unstale nor complete.
I'm more interested in the small gains for many folks approach first.
-lilmatt