Persona 2015 through 2016

[Dan Callahan]

Hey all,

Last week, Gene Wood (former Persona ops) and I met again with Mark Mayo
(VP of Services) to discuss Persona's longer-term future at Mozilla.

Over the past year, Firefox Accounts (FxA) has drifted toward a
traditional (OAuth) model, and away from possible synergies with
BrowserID or Persona. This puts Persona in a bind: work on FxA will not
benefit Persona, and vice versa. MoCo's organizational priorities remain
the same: developers are focusing on FxA, and that focus is unlikely to
shift to Persona in the foreseeable future.

This isn't sustainable for Persona, nor for Mozilla. If we, as a
community, want to see Persona succeed, then we must work together and
remove Persona's reliance on Mozilla for the centralized fallback.

Here's the deal:

1. Persona will continue to receive its current level of support
(operations, security, monitoring, etc.) from Mozilla through 2015.

2. We have until June 30th, 2015 to return to a trajectory of growth,
external contribution, sustainability, and independence from the
Mozilla-operated fallback IdP.

3. If we are not making meaningful progress or do not have a credible
plan on that date, then Mozilla will announce an intent to end-of-life
Persona, with a server turnoff date of June 30th, 2016.

Now, it's not all doom and gloom. Persona was designed to be
decentralized. The only thing at risk is a single, centralized fallback.
Which we needed to get rid of anyway.

1. If we make it easier to self-host Persona, we remove the dependency
on Mozilla's fallback and we're golden.

2. If a compatible custodian steps up and commits engineering and
operational resources to Persona, we remove the dependency on Mozilla's
fallback and we're golden.

Further, if we can articulate a specific set of engineering tasks that
need to be accomplished to make a transition to a specific custodian
feasible, then Mozilla is willing to temporarily commit engineers to
Persona in order to make that happen.

If you believe in Persona or if your organization relies on Persona, now
is the time to step up. Our combined effort over the next 8 months will
determine Persona's fate in 2016.

Our immediate goals remain the same: enable new contributions through
better documentation, and split up the repository into independent
modules for ease of maintenance. Look for another email regarding
specific bugs to tackle soon.

We're kicking Persona out of the nest.

It's time for it to fly.

Best,
-Callahad

[Melvin Carvalho]

Persona as a brand is I think still quite strong.

I think it's slightly too centralized.

Identity in the browser I think is the way forward, see this original
offering from Mozilla labs.

http://www.azarask.in/blog/post/identity-in-the-browser-firefox/

I'd love to see these concepts revived, because they were popular. It may
be easier come Jan 2015 when the W3C Crypto API reaches REC status.

Just my 2 cents.


>
> Best,
> -Callahad
>
> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-identity
>

[Sergio Oliveira]

Hi Dan,

Thanks for the updates! ;)

The only thing I'm not sure after reading your email is what if we do have
"meaningful progress" and/or have a "credible plan" by 2016? What happens
then?

Cheers,

--
Sergio Oliveira


On Thu, Oct 30, 2014 at 6:07 PM, Melvin Carvalho <melvinc...@gmail.com>
wrote:

[Michiel de Jong]

On Thursday, October 30, 2014 7:37:49 PM UTC, Dan Callahan wrote:
> make it easier to self-host Persona

Yes! Count IndieHosters in, for that part. Pierre and I just started this new full-time project, and we care about helping people to self-host niche products (including identity primaries for Persona and various protocols) on their own domain name.

This will also be part of the "personal Mozilla server" product which we discussed at the "Decentralize Hack Day", at Mozilla Paris:

> Decentralizing Mozilla Services:
>
> Mozilla offer a whole bunch of services: https://wiki.mozilla.org/Services/.
> It would be nice to have one package which you can deploy to your own server,
> and then have one place in Firefox settings where you can enter the domain
> name of your "personal Mozilla server", so that all your data will go there
> instead of to Mozilla.

(from https://groups.google.com/forum/#!topic/unhosted/oFRaXUWzA-s)

We only just started https://indiehosters.net/ this month, but we're definitely interested in helping to make it easier to self-host Persona.


Cheers!
Michiel

[Jesus Cea]

On 30/10/14 21:07, Melvin Carvalho wrote:

> I think it's slightly too centralized.

+1.

I have been working with Persona/BrowserID since the very beginning. I
understand the vision and I know that being easy and providing a
fallback for IdP is a need.

But a major selling point of Persona is the privacy advantages and
self-hosting IdP. We are falling *VERY* short on this.

I trust Mozilla a lot, but:

1. I need to link Javascript code from Mozilla in my webpage. Any user
access will hit mozilla servers. Not nice for privacy. You lose a
privacy advocate there.

Moreover, any malicious alteration of that remotely hosted JS can be
disastrous.

I know that the protocol and the API are evolving and that is the point
of importing external code, but we have been out there for years. Time
to write V1.0 on stone.

2. To me, failing to integrate persona JS on regular Firefox codebase
was really disappointing. That means that we will rely on foreign JS
code not able to keep some data really secure on the local browser.

I realize that even if Firefox were Persona-native, we would need that
Javascript to support all other browsers anyway. Disappointing,
nonetheless.

3. 99.99% percent of libraries out there just delegate verification to
Mozilla. Even work I consider "official", like "mod_authnz_persona",
relies in Mozilla verifier. Persona SHOULD push for local verifiers.
This is critical. Current standard Persona deploy is worse for privacy,
security and user-factor than deploying regular FB, Google, even GitHub
logins.

We are alienating privacy advocated because Persona long term vision is
cute but currently the incentives are on the side of just delegating
EVERYTHING in the IdP fallback and the Mozilla verifier. Anybody trying
to do better will be hit hard by reality of current codebases and
"implicit" deploy culture.

The situation is this:

1. If I am a privacy/self reliance advocate, all my users are hitting
mozilla servers in each access. I can't find libraries doing local
verification. The work on most of them looks like stopped, I don't know
if because they are dead or because they are feature complete.

2. If I am not an advocate, just doing OAUTH 2.0 thru Google, FB, etc.,
is easy enough, there are plenty of libraries and my users are happy.

3. Hosting an IdP is pointless if Persona support is marginal and, for
the very few websites out there using it, I can count on the IdP fallback.

Briefly, Persona vision is nice but currently it doesn't provide any
real advantage over OAUTH 2.0 and massive identify providers like
Facebook. In fact the experience is WORSE. Only advocates are using it,
and they are being very badly served by libraries not up to the task.

I insist: I understand the need of the IdP fallback and the convenience
of the remote verifier. They provide bootstrapping and trivial
deployment effort. But people is lazy and libraries are lazy too. The
lazy approach will be the default and currently the lazy approach is
working against Persona long term goals.

If libraries like "mod_authnz_persona" could: a) host the Persona
Javascript, maybe by just doing a lazy fetch per hour to the Mozilla
canonical copy and then serving to local users like a cache and b) doing
local verifications, a privacy advocate would only need the IdP fallback
from Mozilla.

If the IdP fallback could be replaced/augmented with some distributed
verification capabilities with, lets say, X.509 client certificates
would be AMAZING.

We need champions too. Success examples: An university using Persona,
Goverments (doing local verifications and pushing IdP deployments).
Detailed examples of IdP deployments doing trivial username/password to
client X.509 certificates to 2-factors.

We need blog posts, twitters, REFERENCES! :-)

A big complexity of Persona is the reliance on Javascript.
"mod_authnz_persona" is very interesting because it is a drop-in module
for Apache that just provide "REMOTE_USER" variable to the backend. I
don't need to touch ANYTHING in my application, just replace an
autentication engine by other. I don't need to care about how to
integrate the Persona Observer API, or Goldilocks or whatever.

I only need a way to provide "mod_authnz_persona" with:

a) A way to logout (an URL you visit and the autentication cookie is
deleted). This is already available.

b) A way to notify that a resource requests authentication. For
instance, because the backend is providing a 401 status code. This is
useful because the same URL could show different content depending of
authentication status. This feature could be optional just protecting a
single URL ("/login"), if the authentication cookie is available in the
rest of the website.

c) An expiration policy for the authentication cookies.

d) A way to request verification of a given email. It should do a full
local verification, relying only on the IdP fallback if needed.

With these changes I can deploy a Persona RP with no reliance at all on
Mozilla if my users have a primary IdP... my next fight :-).

But being an IdP is far simpler than doing local verifications!.

Yes, I know that many/most sites can't install an Apache module in the
system. Different options like an authentication WSGI module would be
need. That has been my preferred solution so far.

Ideally Mozilla should invest in a few high quality RP implementations
in key projects like Django, Flask, Pyramid (sorry, I am a Python guy),
Wordpress, whatever. Maybe 50 key projects, serving millions of
websites. People is lazy, lets do defaults appropriate and aligned with
Persona long term goals!.

A final comment: public communication is key. Persona mindshare is
marginal. Even me, involved with it, don't know what is going on with
Persona, immediate goals, work in progress, how to help... 99.9999% of
the webmasters out there are not subscribed to the mailing list.

I hope the best for Persona. I like the technology and the long term
potential. I have a deep investment on it. I feel Mozilla made a mistake
when moved it to "community support" because there is no community
building, a plan, a strategy to improve adoption.

I wonder if somebody has surveyed application servers out there, choose
the top 50 and worked to champion Persona there providing good quality
code (local verifiers!), document how to use it, provide detailed
examples from trivial to sophisticated... :-). I guess Persona has
champions out there, in those projects, that would love to be nurtured
by Mozilla and maybe even get a bit of money of it. With good base
libraries in a handful of languages, how long would take to write an
authentication plugin? A week?. I know I would love doing it far below
my standard pay rates :), because I want it to SUCCEED.

--
Jesús Cea Avión _/_/ _/_/_/ _/_/_/
jc...@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
Twitter: @jcea _/_/ _/_/ _/_/_/_/_/
jabber / xmpp:jc...@jabber.org _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz

[Jonas Schneider]

I think I agree with Jesús here.

In the ideal world, Persona is easy-to-use enough for sites to use and
secure enough for security advocates to recommend to people and foster
further community interest and popularity.

Reality shows it's currently neither -- the popularity momentum just
isn't there, and https://github.com/mozilla/persona/issues/1501 seems
to have shown virtually no progress towards self-hosted verifiers
(without which the entire thing is, crypto-wise, a joke).

Let's kick this up a notch. As a freelance developer, how can I
volunteer to help out?

- Jonas

[Dirkjan Ochtman]

On Sun, Nov 2, 2014 at 3:47 PM, Jonas Schneider <ma...@jonasschneider.com> wrote:
> I think I agree with Jesús here.
>
> In the ideal world, Persona is easy-to-use enough for sites to use and
> secure enough for security advocates to recommend to people and foster
> further community interest and popularity.
>
> Reality shows it's currently neither -- the popularity momentum just
> isn't there, and https://github.com/mozilla/persona/issues/1501 seems
> to have shown virtually no progress towards self-hosted verifiers
> (without which the entire thing is, crypto-wise, a joke).
>
> Let's kick this up a notch. As a freelance developer, how can I
> volunteer to help out?

I don't think self-hosted verifiers are the long pole here, a number
of libraries in different languages should already support it. Still,
you could take a look here at
https://developer.mozilla.org/en-US/Persona/Libraries_and_plugins to
see what's available for the language/framework of your choice and
find out if verifying locally is already supported.

If you have some experience with node.js, picking apart the Persona
code base could be even more valuable. We really need to separate the
shim from the fallback and drastically simplify them to enable
separate deployment.

Cheers,

Dirkjan

[Randall Leeds]

On Sun, Nov 2, 2014 at 12:00 PM, Dirkjan Ochtman <dir...@ochtman.nl> wrote:

> If you have some experience with node.js, picking apart the Persona
> code base could be even more valuable. We really need to separate the
> shim from the fallback and drastically simplify them to enable
> separate deployment.
>

+1

In particular, as I think I've said before, I would like to help separate
the shim and also refine the build process.

I've now built, twice, a flow involving something like Persona's pop-up
window and communication iframe. There are loads of stumbling blocks here
around code portability and good user experience. I would have used the
Persona code if I could have rolled my own shim and deployed my own
communication iframe from the Persona code. Instead, I found it too
difficult to extract what I needed and ended up rolling my own, admittedly
worse, implementation. If I had been ready for full-on Persona IdP status I
could have just used the official shim, but I really wanted to evolve
toward that in steps.

Some more modularity would be very helpful.

[Andrew Ducker]

On Thursday, 30 October 2014 19:37:49 UTC, Dan Callahan wrote:
> If you believe in Persona or if your organization relies on Persona, now
> is the time to step up. Our combined effort over the next 8 months will
> determine Persona's fate in 2016.

Assuming that we can get the code into a state where everything other than the fallback is decentralised - what are the anticipated costs of running the fallback?

Because if we can get a few organisations onboard with the idea of decentralised login and willing to pay for a small team to maintain the back end then that would hopefully be enough to keep that going.

The question is - how much would we need?

Andy

[Dirkjan Ochtman]

On Mon, Nov 3, 2014 at 10:11 AM, Andrew Ducker <and...@ducker.org.uk> wrote:
> Assuming that we can get the code into a state where everything other than the fallback is decentralised - what are the anticipated costs of running the fallback?
>
> Because if we can get a few organisations onboard with the idea of decentralised login and willing to pay for a small team to maintain the back end then that would hopefully be enough to keep that going.
>
> The question is - how much would we need?

That seems pretty hard to estimate with any kind of accuracy.

I wouldn't mind doing maintenance on the back end (if we manage to
extract a reasonable backend code base), but I don't think I'd want to
pay for the server resources required.

Cheers,

Dirkjan

[Andrew Ducker]

On Monday, 3 November 2014 09:27:24 UTC, Dirkjan Ochtman wrote:
> I wouldn't mind doing maintenance on the back end (if we manage to
> extract a reasonable backend code base), but I don't think I'd want to
> pay for the server resources required.

I was thinking that some other organisation might also be prepared to pick it up from an infrastructure point of view. There are a few organisations out there that are interested in doing things for the good of the web.

(Of course, step 1 is getting it into a maintanable state.)

[Nick Jennings]

On Sun, Nov 2, 2014 at 3:09 AM, Jesus Cea <jc...@jcea.es> wrote:

> On 30/10/14 21:07, Melvin Carvalho wrote:
>
> > I think it's slightly too centralized.
>
> +1.
>
> I have been working with Persona/BrowserID since the very beginning. I
> understand the vision and I know that being easy and providing a
> fallback for IdP is a need.
>
> But a major selling point of Persona is the privacy advantages and
> self-hosting IdP. We are falling *VERY* short on this.
>
> I trust Mozilla a lot, but:
>
> 1. I need to link Javascript code from Mozilla in my webpage. Any user
> access will hit mozilla servers. Not nice for privacy. You lose a
> privacy advocate there.
>
>

Why do you have to link to the JS from Mozillas servers? What is preventing
you from hosting a copy of the client-side library?

> Moreover, any malicious alteration of that remotely hosted JS can be
> disastrous.
>
> I know that the protocol and the API are evolving and that is the point
> of importing external code, but we have been out there for years. Time
> to write V1.0 on stone.
>
> 2. To me, failing to integrate persona JS on regular Firefox codebase
> was really disappointing. That means that we will rely on foreign JS
> code not able to keep some data really secure on the local browser.
>
> I realize that even if Firefox were Persona-native, we would need that
> Javascript to support all other browsers anyway. Disappointing,
> nonetheless.
>

That's quite a tall order IMHO, Persona is addressing the "login with
google/facebook/twitter" and compared to those it offers an immensely more
autonomous authentication process. As of yet, no major browser vendor has
taken the plunge to start including (ie. choosing winners) JS libraries to
include in their browser, as it could have unintended consequences and
create more problems than it solves.

>
> 3. 99.99% percent of libraries out there just delegate verification to
> Mozilla. Even work I consider "official", like "mod_authnz_persona",
> relies in Mozilla verifier. Persona SHOULD push for local verifiers.
> This is critical. Current standard Persona deploy is worse for privacy,
> security and user-factor than deploying regular FB, Google, even GitHub
> logins.
>
> We are alienating privacy advocated because Persona long term vision is
> cute but currently the incentives are on the side of just delegating
> EVERYTHING in the IdP fallback and the Mozilla verifier. Anybody trying
> to do better will be hit hard by reality of current codebases and
> "implicit" deploy culture.
>
> The situation is this:
>
> 1. If I am a privacy/self reliance advocate, all my users are hitting
> mozilla servers in each access. I can't find libraries doing local
> verification. The work on most of them looks like stopped, I don't know
> if because they are dead or because they are feature complete.
>

Doesn't the protocol dictate an initial attempt to discover the persona
auth on the domain of the email address? With Mozillas servers as the
fallback?

>
> 2. If I am not an advocate, just doing OAUTH 2.0 thru Google, FB, etc.,
> is easy enough, there are plenty of libraries and my users are happy.
>

There are plenty that implement Google, FB, and so on, plus Persona as well.

>
> 3. Hosting an IdP is pointless if Persona support is marginal and, for
> the very few websites out there using it, I can count on the IdP fallback.
>

Again, my comment to #1.

I think we agree the main problem is that Mozilla went big, but then did
not follow-through on community development and education, and then bailed
on it way too soon. I know there were some people who did not even
understand that Persona was not just another Google/FB OAuth system, and
also that it was designed so that you could completely host your own
identity authentication. The gmail integration further was used as FUD by
people who just didn't particularly like Mozilla, even though it was
misconstrued. I ran into a lot of this and most of it was knocking Persona
for reasons which were not factual. This is a sign Mozilla didn't do a good
enough job at education.

Then, with Firefox Accounts, I think people of casual interest got even
more confused - especially when coupled with the announcement that Mozilla
wouldn't be focusing on Persona anymore.

I'm a huge fan of what Persona has been trying to achieve, and although I
don't have the time to volunteer to help run a public fallback service I do
plan to have a look at the node.js codebase and see where I can help there.

Cheers
Nick

[Nick Jennings]

On Mon, Nov 3, 2014 at 10:55 AM, Andrew Ducker <and...@ducker.org.uk> wrote:

> On Monday, 3 November 2014 09:27:24 UTC, Dirkjan Ochtman wrote:
> > I wouldn't mind doing maintenance on the back end (if we manage to
> > extract a reasonable backend code base), but I don't think I'd want to
> > pay for the server resources required.
>
> I was thinking that some other organisation might also be prepared to pick
> it up from an infrastructure point of view. There are a few organisations
> out there that are interested in doing things for the good of the web.
>

Maybe indie email hosters like riseup?

>
> (Of course, step 1 is getting it into a maintanable state.)

[Douglas Schepers]

Hey, folks-

W3C sees identity as an important missing component of the Web, though it's been difficult to get right, and difficult to convince the right stakeholders to look at standardization.

I was personally very interested in Persona/BrowserID as a potential solution, though I was also concerned (like others on this list) that the early implementation was too centralized and wasn't yet baked in the browser itself. I was disappointed when Mozilla set it aside.

We're currently moving to use FxA for WebPlatform.org, our community and documentation site (we'll deploy in a month or 2), and I'd hoped to also include Persona support. We would probably be willing to host the project on our servers and provide a discussion channel, if the community is interested (though I'd have to get approval from our stewards committee on this).

Wherever Persona ends up, I think it might be useful to consider standardization as part of the long-term roadmap. I realize that may sound odd -suggesting standardizing a tech that hasn't been successful- but I think that lack of standardization was one of the failure points... that is, lack of multi-stakeholder collaboration, discussion, specification, testing, multiple implementations, and developer deployment. Identity has to be decentralized and interoperable for it to take a major leap forward. Obviously, it doesn't make sense to standardize Persona itself as it stands, but it could be used as the starting point for more serious discussion. I think Persona has a lot going for it, and it would be a shame to see it die.

Regards-
-Doug Schepers (W3C)

[Melvin Carvalho]

I think there are slight differences between "login with
google/facebook/twitter", compared to Persona. Or at least, there were in
the version I was working with.

With persona you need to memorize your email address, whereas, with
twitter/facebook you can just click a button. In fact, most users will not
have a twitter/facebook email address, they'll be logged in already and
just have permissions dialogue. I think websites felt that this lead to a
better UX, or higher conversion rate than the Persona UX (I dont have stats
to back this up, maybe someone does). I did think the Persona UX was
really good given the flow it had to operate. Architecturally I think the
main difference here is that OAuth allows both email identifers and http
identifiers, whereas persona is only verified email. Google/gmail is kind
of a special case here in that respect too.

One other thing that I'm not sure all that many people realized was that
when you used the Mozilla fallback server, which was probably a large
number of users. You needed to have a different password from your email
provider. So say now I have al...@email.com and I have to remember two
passwords. As someone that's terrible at remembering passwords, this was a
demerit for me personally.

I also agree with Jesus, that I'd love to see the browser doing more in
terms of identity management, and taking the strain of the user. It's
ironic that the most trusted browser vendor in the world chose a server
side solution to identity! I think small steps like allowing your browser
to remember who you are I think are would be a valuable feature in terms of
identity, maybe it can be done already, but I've not yet found a way ..

[Melvin Carvalho]

Hi Doug

The issue of W3C standardization has come up on this list before. Harry
Halpin suggested it to Ben Adida, who, at the time was the Persona lead.

Excerpt below:

[[
> I will point out W3C still maintains interest in standardization of at
> least some parts of Persona in this design space, in particular if folks
> from the Chrome team are interested. We're just waiting for a signal from
> Mozilla :)


You're waiting for a signal from us? I didn't realize that. Consider the
signal sent: we'd love to discuss standardizing Persona! Where would you
like to start?
]]

However, this was never really taken any further, to my knowledge. In
truth, I am unsure what parts would be appropriate for standardization.

[Michael Kelly]

On 11/2/14 12:00 PM, Dirkjan Ochtman wrote:
> If you have some experience with node.js, picking apart the Persona
> code base could be even more valuable. We really need to separate the
> shim from the fallback and drastically simplify them to enable
> separate deployment.

Not that I think it's a great idea to actually go with, but out of
curiosity, would it be easier to attempt a simplified reimplementation
vs working with the existing code? I forget if I've already asked this.

- Mike Kelly

[Randall Leeds]

On Mon, Nov 3, 2014 at 10:08 AM, Melvin Carvalho <melvinc...@gmail.com>
wrote:

> On 3 November 2014 18:47, Douglas Schepers <doug.s...@gmail.com>
> wrote:
>

> Hi Doug
>
> The issue of W3C standardization has come up on this list before. Harry
> Halpin suggested it to Ben Adida, who, at the time was the Persona lead.
>
> Excerpt below:
>
> [[
> > I will point out W3C still maintains interest in standardization of at
> > least some parts of Persona in this design space, in particular if folks
> > from the Chrome team are interested. We're just waiting for a signal from
> > Mozilla :)
>
>
> You're waiting for a signal from us? I didn't realize that. Consider the
> signal sent: we'd love to discuss standardizing Persona! Where would you
> like to start?
> ]]
>
> However, this was never really taken any further, to my knowledge. In
> truth, I am unsure what parts would be appropriate for standardization.
>

> Having played around quite a bit with Persona and OAuth over the last year
I actually think Persona is not far from alignment with the JWT Profile for
OAuth 2.0 [1].

If, instead of a concatenation of certificates, Persona used a nesting of
certificates, I think it might actually be almost entirely aligned. That
spec leaves validating and discovery unspecified, which means validating
through public keys retrieved from .well-known is totally legit. All that
remains is to treat the next certificate in the chain as the subject of the
one before it, and we may actually have something that *is* OAuth 2.0.

Or am I crazy and missing something fundamental?


[1] http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-05

[Ben Werdmuller]

On Thursday, October 30, 2014 12:37:49 PM UTC-7, Dan Callahan wrote:

> 1. If we make it easier to self-host Persona, we remove the dependency
> on Mozilla's fallback and we're golden.

Over at Known (http://withknown.com), we're very interested in Persona, and have had a lot of people in our open source community express interest in us supporting it as a core feature of the platform.

Our main customers are universities, and it would be interesting to make self-hosting a Persona provider very easy for them, potentially in tandem with Known or WordPress profiles. In an ideal world, self-hosting providers should be as accessible as possible, of course.

(I would also love to see identity in the browser.)

Ben

[Dirkjan Ochtman]

You asked this on IRC a few days ago. I think my answer still stands:
I'm worried about the subtle security-sensitive nuances in the case of
the fallback, and the subtle browser-compatibility nuances in the case
of the shim.

I do think maybe the server-side part of the shim wouldn't be so hard
(and it might make sense there). For the fallback, it might still be
sensible, since it seems like a less-complex thing, and maybe the
security stuff in there is quite manageable.

Cheers,

Dirkjan

[Dan Callahan]

On 10/31/14 07:04, Sergio Oliveira wrote:
> The only thing I'm not sure after reading your email is what if we do have
> "meaningful progress" and/or have a "credible plan" by 2016? What happens
> then?

If we have meaningful progress and / or a plan, then we can likely tweak
Mozilla's timeline for ongoing support to meet that. E.g., if we can say
"we need X more months or Y resources to remove the hard dependency on
Mozilla, and here's specifically how we'll accomplish that," then
there's a good chance that things can flex a bit to make that possible.

Mozilla significantly reinvesting in Persona infrastructure is unlikely,
but I actually think that may be beneficial. Or at least, I think our
easy reliance on the centralized fallback may have lulled us into
complacence on actually getting the decentralized parts into a good place.

A centralized fallback is convenient, but it's also pretty damn
antithetical to Persona's vision.

Ultimately, we need to remove the hard dependency on Mozilla, and we
need to be pretty far down that path in 8 months.

This is still a nights / weekends thing for me, but we are moving. The
responses to this thread, and to the mass bug closing, are super helpful
in re-surfacing what we need to do, and what resources we have at our
disposal. Look for more emails tomorrow on that front.

For now, if you're looking to help, a good first step is trying to
figure out why the heck our MySQL backend tests are failing on Travis. I
can't reproduce this locally at all, on OS X or Debian GNU/Linux.

https://github.com/mozilla/persona/issues/4179

Solving this would dramatically ease the burden of reviewing pull
requests, and you'd get experience running the Persona test suite on a
local development instance. Seems like a good place to start. :)

Let me know if you need help or pointers, and let me know if you can (or
can't!) reproduce the bug locally.

Best,
-Callahad

[Mark W. Oosterveld]

I am able to make these tests fail in my dev environment. If I can
solve them, I will submit a pull request with my solutions.

Mark

[Mark W. Oosterveld]

Ok, I found the problem. In stalled-mysql-tests.js,
STALL_MYSQL_WHEN_PRESENT is set to point to a non-existent directory,
and so addStallDriverBatch fails to create the .stall file. When I
created the expected directory, the tests passed.

There are a couple ways to fix this. 1: Have the travis build script
create the directory, or 2: figure out why the temp module failed. I
will attempt the latter, and update you on my progress.

Mark

[Dan Callahan]

On 11/8/14 21:02, Mark W. Oosterveld wrote:
> There are a couple ways to fix this. 1: Have the travis build script
> create the directory, or 2: figure out why the temp module failed. I
> will attempt the latter, and update you on my progress.

Turns out, bumping the temp module to 0.8.1 solved it -- thanks, Mark!

-Callahad

[Jesus Cea]

On 03/11/14 14:12, Nick Jennings wrote:
> Why do you have to link to the JS from Mozillas servers? What is
> preventing you from hosting a copy of the client-side library?

https://developer.mozilla.org/en/Persona/FAQ

"""
Can I self-host include.js, or must I include it from
https://login.persona.org?

The code in include.js is still subject to change. It's not yet
recommended that you host it yourself.
"""

This is a still evolving technology. See goldilocks, for instance.

> Doesn't the protocol dictate an initial attempt to discover the
> persona auth on the domain of the email address? With Mozillas
> servers as the fallback?

A local verifier should do that. The fact is that 99.9999% of people out
there is lazy and just delegate everything to Mozilla. Most libraries
don't even have the option to do local verifications, they throw the
problem to mozilla.

For instance, "mod_authnz_persona":

<https://github.com/mozilla/mod_authnz_persona/blob/master/src/verify.c#L74>

There is no "local verification" in that code.

The point of my email is that yes, you con implement Persona properly,
but 99.9% systems out there are simply delegating in Mozilla fallback
and verifier. And people trying to do the right thing will not be able
to find appropiate libraries.

> I know there were some people who did
> not even understand that Persona was not just another Google/FB OAuth
> system, and also that it was designed so that you could completely
> host your own identity authentication.

That is the point!!!. If you are interested and check around, you see
99.9% RPs will delegate to Mozilla. So it is another centralized
solution. You don't easily see decentralized verifiers. They are a rarity.

[lloh...@gmail.com]

เมื่อ วันศุกร์ที่ 31 ตุลาคม ค.ศ. 2014 2 นาฬิกา 37 นาที 49 วินาที UTC+7, Dan Callahan เขียนว่า:

[numd...@gmail.com]

https://accounts.firefox.com/confirm?entrypoint=preferences&email=supannnnn30%40gmail.com&service=sync&context=fx_fennec_v1#