Is shutting down Persona the best idea?

[a***@nsuchy.top]

I understand that on November 30th Persona will be gone and the data deleted. Is this the best idea? What will happen to unmaintained websites which have no other login system? Is it a good idea to say oh well and let them become non-functioning? Consider this...

[Ryan Kelly]

Post by a***@nsuchy.top
I understand that on November 30th Persona will be gone and the data deleted. Is this the best idea? What will happen to unmaintained websites which have no other login system? Is it a good idea to say oh well and let them become non-functioning? Consider this...

Thanks for the question, and sorry this got lost in my inbox for a while
due to travel. It's an important point and something we've definitely
thought about a lot. I said a few more words about it on the wiki [1]
but will quote them here as well:

"""
Hosting a service at the level of security and availability required for
an authentication system is no small undertaking, and Mozilla can no
longer justify dedicating limited resources to this project.
"""

For the small number of websites that may not be able to migrate away
from Persona, a hard shutdown does indeed mean that logins will no
longer work, which is not a great outcome.

But keeping the service online without adequate maintenance would be an
even worse outcome - logins that work intermittently and may have
unpatched security vulnerabilities.


Cheers,

Ryan


[1]
https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers#Why_is_persona.org_being_shut_down.3F

[Marcio Galli]

Would be an amazing contribution if Mozilla could actually disclose
the costs of engineering and give a hint on the actual bugs problems
per time. I just figure that a flipside of opensource/Mozilla/failures
is actually in being more open about the learnings and costs of
engineering - not sure if makes sense. I see that there is a section
for self-hosting that partially covers it. Do you think that the list
of open bugs is significant as a snapshot for someone willing to
understand engineering cost/key activities?

m

Post by Ryan Kelly

Post by a***@nsuchy.top
I understand that on November 30th Persona will be gone and the data deleted. Is this the best idea? What will happen to unmaintained websites which have no other login system? Is it a good idea to say oh well and let them become non-functioning? Consider this...

Thanks for the question, and sorry this got lost in my inbox for a while
due to travel. It's an important point and something we've definitely
thought about a lot. I said a few more words about it on the wiki [1]
"""
Hosting a service at the level of security and availability required for
an authentication system is no small undertaking, and Mozilla can no
longer justify dedicating limited resources to this project.
"""
For the small number of websites that may not be able to migrate away
from Persona, a hard shutdown does indeed mean that logins will no
longer work, which is not a great outcome.
But keeping the service online without adequate maintenance would be an
even worse outcome - logins that work intermittently and may have
unpatched security vulnerabilities.
Cheers,
Ryan
[1]
https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers#Why_is_persona.org_being_shut_down.3F
_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

[b***@gmail.com]

My 2 cents:

I've just finished migrating my service away from Persona to a
password-less authentication system.

I was not excited about doing this work, however, now that it is done and
Persona is gone, I am quite happy about it:
- site loads faster
- no popup windows
- no iOS issues related to popups
- no cross-domain requests
- no reliance on a 3rd party

For me, it was complacency keeping me on Persona, and the shutdown deadline
notice was the motivation I needed to improve my service by removing
passwords entirely.

I understand the Persona shutdown will break sites that are no longer being
maintained, and that is unfortunate, but for me this change was a Good
Thing.

Post by Marcio Galli
Would be an amazing contribution if Mozilla could actually disclose
the costs of engineering and give a hint on the actual bugs problems
per time. I just figure that a flipside of opensource/Mozilla/failures
is actually in being more open about the learnings and costs of
engineering - not sure if makes sense. I see that there is a section
for self-hosting that partially covers it. Do you think that the list
of open bugs is significant as a snapshot for someone willing to
understand engineering cost/key activities?
m

Post by Ryan Kelly

Post by a***@nsuchy.top
I understand that on November 30th Persona will be gone and the data

deleted. Is this the best idea? What will happen to unmaintained websites
which have no other login system? Is it a good idea to say oh well and let
them become non-functioning? Consider this...

Post by Ryan Kelly
Thanks for the question, and sorry this got lost in my inbox for a while
due to travel. It's an important point and something we've definitely
thought about a lot. I said a few more words about it on the wiki [1]
"""
Hosting a service at the level of security and availability required for
an authentication system is no small undertaking, and Mozilla can no
longer justify dedicating limited resources to this project.
"""
For the small number of websites that may not be able to migrate away
from Persona, a hard shutdown does indeed mean that logins will no
longer work, which is not a great outcome.
But keeping the service online without adequate maintenance would be an
even worse outcome - logins that work intermittently and may have
unpatched security vulnerabilities.
Cheers,
Ryan
[1]

https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers#Why_is_persona.org_being_shut_down.3F

Post by Ryan Kelly
_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

--
www.telasocial.com
_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

[Andrew Ducker]

What system did you move to? I need to do this work at some point in the next month or two, and any advice is gratefully accepted.

[Dirkjan Ochtman]

Post by Andrew Ducker
What system did you move to? I need to do this work at some point in the next month or two, and any advice is gratefully accepted.

Note also that a small group of people is currently hacking on a new
BrowserID-like protocol, here:

https://github.com/letsauth/letsauth.github.io/wiki

You might want to see how they fare (the group includes some people
who also worked on Persona, including myself).

Cheers,

Dirkjan

[Melvin Carvalho]

Post by Andrew Ducker

Post by Andrew Ducker
What system did you move to? I need to do this work at some point in

the next month or two, and any advice is gratefully accepted.
Note also that a small group of people is currently hacking on a new
https://github.com/letsauth/letsauth.github.io/wiki
You might want to see how they fare (the group includes some people
who also worked on Persona, including myself).

Nice idea.

But it suffers from the same weaknesses as Persona.

Namely:

- Lacks slightly a clean separation of identity and and authentication
(verifying identity) -- I may be wrong there

- Is too tightly bound to email. Inevitably you'll go up against the big
webmail providers who will end up shutting you down. Or you'll introduce a
central point of failure a la Persona.

Do we really want to repeat the same mistakes again? A much better way
IMHO is to allow any type of identity (ie a URI) and offer the user that
freedom, which OAuth does a lot better. Then allow cryptographic proofs to
verify that identity, instead of having to remember a password for every
site -- or in the case of Persona two passwords per email address!

Post by Andrew Ducker
Cheers,
Dirkjan
_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

[b***@gmail.com]

Andrew,

I looked originally at https://passwordless.net/ , which I used as
inspiration for my own (non node-js) implementation.

The big weakness of Passwordless that I had to overcome was the
verification link getting clicked on a different user agent. e.g. you are
trying to log in on your desktop browser, but click the verification link
on your phone. This was easily solved using a websocket on the original
page to receive a pushed token as soon as the link is clicked. I guess you
could also use long polling. Not sure what Persona did, but they also
solved this same issue.

Melvin,

If your use case involves being able to communicate with the user via
email, as I suspect many use cases do, then identity being bound to email
is ideal.

Post by Melvin Carvalho

Post by Andrew Ducker

Post by Andrew Ducker
What system did you move to? I need to do this work at some point in

the next month or two, and any advice is gratefully accepted.
Note also that a small group of people is currently hacking on a new
https://github.com/letsauth/letsauth.github.io/wiki
You might want to see how they fare (the group includes some people
who also worked on Persona, including myself).

Nice idea.
But it suffers from the same weaknesses as Persona.
- Lacks slightly a clean separation of identity and and authentication
(verifying identity) -- I may be wrong there
- Is too tightly bound to email. Inevitably you'll go up against the big
webmail providers who will end up shutting you down. Or you'll introduce a
central point of failure a la Persona.
Do we really want to repeat the same mistakes again? A much better way
IMHO is to allow any type of identity (ie a URI) and offer the user that
freedom, which OAuth does a lot better. Then allow cryptographic proofs to
verify that identity, instead of having to remember a password for every
site -- or in the case of Persona two passwords per email address!

Post by Andrew Ducker
Cheers,
Dirkjan
_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

[Melvin Carvalho]

Post by b***@gmail.com
Andrew,
I looked originally at https://passwordless.net/ , which I used as
inspiration for my own (non node-js) implementation.
The big weakness of Passwordless that I had to overcome was the
verification link getting clicked on a different user agent. e.g. you are
trying to log in on your desktop browser, but click the verification link
on your phone. This was easily solved using a websocket on the original
page to receive a pushed token as soon as the link is clicked. I guess you
could also use long polling. Not sure what Persona did, but they also
solved this same issue.
Melvin,
If your use case involves being able to communicate with the user via
email, as I suspect many use cases do, then identity being bound to email
is ideal.

I dont think this is accurate. What you are saying is you'd like to
overload email (and only email) to do 3 quite different things:

1. Be a primary identifier for verification.
2. Be a memorable string you type into a form
3. Be a message delivery system.

This is from one perspective a neat hack, but from another perspective a
horrible architectural design decision.

Overloading is always a great sugar rush as it gets something working quite
fast (as happened with persona) ... the cracks appear down the line.

Typically in programming you tie key value pairs to entities (think JSON)
and can enrich identity with say your name, your avatar, your email address
... in fact it's open ended.

Post by b***@gmail.com

Post by Melvin Carvalho

Post by Andrew Ducker

Post by Andrew Ducker
What system did you move to? I need to do this work at some point in

the next month or two, and any advice is gratefully accepted.
Note also that a small group of people is currently hacking on a new
https://github.com/letsauth/letsauth.github.io/wiki
You might want to see how they fare (the group includes some people
who also worked on Persona, including myself).

Nice idea.
But it suffers from the same weaknesses as Persona.
- Lacks slightly a clean separation of identity and and authentication
(verifying identity) -- I may be wrong there
- Is too tightly bound to email. Inevitably you'll go up against the big
webmail providers who will end up shutting you down. Or you'll introduce a
central point of failure a la Persona.
Do we really want to repeat the same mistakes again? A much better way
IMHO is to allow any type of identity (ie a URI) and offer the user that
freedom, which OAuth does a lot better. Then allow cryptographic proofs to
verify that identity, instead of having to remember a password for every
site -- or in the case of Persona two passwords per email address!

Post by Andrew Ducker
Cheers,
Dirkjan
_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

[Adrian Gropper]

email is a convenient way to specify a persona. WebFinger can transform the
email into any other URI such as one pointing to a personal authorization
server with OAuth as the framework. The authentication and reputation
issues then need to build upon that.

Adrian

Post by Melvin Carvalho

Post by b***@gmail.com
Andrew,
I looked originally at https://passwordless.net/ , which I used as
inspiration for my own (non node-js) implementation.
The big weakness of Passwordless that I had to overcome was the
verification link getting clicked on a different user agent. e.g. you

are

Post by b***@gmail.com
trying to log in on your desktop browser, but click the verification link
on your phone. This was easily solved using a websocket on the original
page to receive a pushed token as soon as the link is clicked. I guess

you

Post by b***@gmail.com
could also use long polling. Not sure what Persona did, but they also
solved this same issue.
Melvin,
If your use case involves being able to communicate with the user via
email, as I suspect many use cases do, then identity being bound to email
is ideal.

I dont think this is accurate. What you are saying is you'd like to
1. Be a primary identifier for verification.
2. Be a memorable string you type into a form
3. Be a message delivery system.
This is from one perspective a neat hack, but from another perspective a
horrible architectural design decision.
Overloading is always a great sugar rush as it gets something working quite
fast (as happened with persona) ... the cracks appear down the line.
Typically in programming you tie key value pairs to entities (think JSON)
and can enrich identity with say your name, your avatar, your email address
... in fact it's open ended.

Post by b***@gmail.com
On Mon, Jan 25, 2016 at 9:53 AM, Melvin Carvalho <

Post by Melvin Carvalho

Post by Andrew Ducker

Post by Andrew Ducker
What system did you move to? I need to do this work at some point

in

Post by b***@gmail.com

Post by Melvin Carvalho

Post by Andrew Ducker
the next month or two, and any advice is gratefully accepted.
Note also that a small group of people is currently hacking on a new
https://github.com/letsauth/letsauth.github.io/wiki
You might want to see how they fare (the group includes some people
who also worked on Persona, including myself).

Nice idea.
But it suffers from the same weaknesses as Persona.
- Lacks slightly a clean separation of identity and and authentication
(verifying identity) -- I may be wrong there
- Is too tightly bound to email. Inevitably you'll go up against the

big

Post by b***@gmail.com

Post by Melvin Carvalho
webmail providers who will end up shutting you down. Or you'll

introduce

Post by b***@gmail.com

Post by Melvin Carvalho
a
central point of failure a la Persona.
Do we really want to repeat the same mistakes again? A much better way
IMHO is to allow any type of identity (ie a URI) and offer the user that
freedom, which OAuth does a lot better. Then allow cryptographic proofs to
verify that identity, instead of having to remember a password for every
site -- or in the case of Persona two passwords per email address!

Post by Andrew Ducker
Cheers,
Dirkjan
_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

[Melvin Carvalho]

Post by Adrian Gropper
email is a convenient way to specify a persona.

I think this is a reasonable statement. Bear in mind some will strongly
agree, some will strongly disagree. But let's so for now this is perfectly
reasonable (I think it is)

However that's not the formulation of persona etc. The formulation in
persona is slightly different

- email is the *only* way to specify a persona

This is problematic, and contrasts with widely adopted systems such as
OAuth.

There's a general principle in a lot of standards that says dont restrict
unless you have to. This also plays into the hands of webmail providers.
If I were one I'd pay people to spread the message that email was the one
identifier to rule them all, and nothing else counts. If facebook didnt
exist, you could easily think that way (not that Im saying we should all
use facebook).

Post by Adrian Gropper
WebFinger can transform the email into any other URI such as one pointing
to a personal authorization server with OAuth as the framework.

Only if your email provider supports this. Many are moving away from it,
or didnt use it in the first place. I think it's been turned off in a lot
of instances. Also it means, say in the case of gmail, that google control
your record, not the user. This is the downside of the convenience gained
by overloading email for 2 or 3 purposes ... and one big reason that
centralization was introduced to persona, which I think was a contributory
factor to its failure. The big webmail companies have no incentive to give
up control of email profiles.

My main point here is that, such overloading is unnecessary in a well
designed system, and not particularly hard to implement, it amounts to
tying a key value pair to an entity. This is what pretty much all
programming data structures do anyway. As I say the hack of overloading an
identifier

Post by Adrian Gropper
The authentication and reputation issues then need to build upon that.

Yes! Authentication and reputation are modular concerns in themselves
built on top of the first layer. It took us a few years to work this out
in the WebID community, but this insight is a valuable one IMHO

Post by Adrian Gropper
Adrian

Post by Melvin Carvalho

Post by b***@gmail.com
Andrew,
I looked originally at https://passwordless.net/ , which I used as
inspiration for my own (non node-js) implementation.
The big weakness of Passwordless that I had to overcome was the
verification link getting clicked on a different user agent. e.g. you

are

Post by b***@gmail.com
trying to log in on your desktop browser, but click the verification

link

Post by b***@gmail.com
on your phone. This was easily solved using a websocket on the original
page to receive a pushed token as soon as the link is clicked. I guess

you

Post by b***@gmail.com
could also use long polling. Not sure what Persona did, but they also
solved this same issue.
Melvin,
If your use case involves being able to communicate with the user via
email, as I suspect many use cases do, then identity being bound to

email

Post by b***@gmail.com
is ideal.

I dont think this is accurate. What you are saying is you'd like to
1. Be a primary identifier for verification.
2. Be a memorable string you type into a form
3. Be a message delivery system.
This is from one perspective a neat hack, but from another perspective a
horrible architectural design decision.
Overloading is always a great sugar rush as it gets something working quite
fast (as happened with persona) ... the cracks appear down the line.
Typically in programming you tie key value pairs to entities (think JSON)
and can enrich identity with say your name, your avatar, your email address
... in fact it's open ended.

Post by b***@gmail.com
On Mon, Jan 25, 2016 at 9:53 AM, Melvin Carvalho <

Post by Melvin Carvalho

Post by Andrew Ducker

Post by Andrew Ducker
What system did you move to? I need to do this work at some point

in

Post by b***@gmail.com

Post by Melvin Carvalho

Post by Andrew Ducker
the next month or two, and any advice is gratefully accepted.
Note also that a small group of people is currently hacking on a new
https://github.com/letsauth/letsauth.github.io/wiki
You might want to see how they fare (the group includes some people
who also worked on Persona, including myself).

Nice idea.
But it suffers from the same weaknesses as Persona.
- Lacks slightly a clean separation of identity and and authentication
(verifying identity) -- I may be wrong there
- Is too tightly bound to email. Inevitably you'll go up against the

big

Post by b***@gmail.com

Post by Melvin Carvalho
webmail providers who will end up shutting you down. Or you'll

introduce

Post by b***@gmail.com

Post by Melvin Carvalho
a
central point of failure a la Persona.
Do we really want to repeat the same mistakes again? A much better way
IMHO is to allow any type of identity (ie a URI) and offer the user

that

Post by b***@gmail.com

Post by Melvin Carvalho
freedom, which OAuth does a lot better. Then allow cryptographic

proofs

Post by b***@gmail.com

Post by Melvin Carvalho
to
verify that identity, instead of having to remember a password for

every

Post by b***@gmail.com

Post by Melvin Carvalho
site -- or in the case of Persona two passwords per email address!

Post by Andrew Ducker
Cheers,
Dirkjan
_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

_______________________________________________
dev-identity mailing list
https://lists.mozilla.org/listinfo/dev-identity

--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/

[i***@gmail.com]

Post by a***@nsuchy.top
I understand that on November 30th Persona will be gone and the data deleted. Is this the best idea? What will happen to unmaintained websites which have no other login system? Is it a good idea to say oh well and let them become non-functioning? Consider this...

[i***@gmail.com]

Post by a***@nsuchy.top
I understand that on November 30th Persona will be gone and the data deleted. Is this the best idea? What will happen to unmaintained websites which have no other login system? Is it a good idea to say oh well and let them become non-functioning? Consider this...

[i***@gmail.com]

Post by a***@nsuchy.top
I understand that on November 30th Persona will be gone and the data deleted. Is this the best idea? What will happen to unmaintained websites which have no other login system? Is it a good idea to say oh well and let them become non-functioning? Consider this...

My messages