Transferable Identifiers

[Sean McArthur]

This was brought up by the tent.io guys, but it's relevant to everyone. I
may start using Persona by logging in with my Gmail account. But
eventually, say Gmail becomes (more) evil, or I simply want to move to my
own domain, there is no way to use Persona to login with my new identifier.
I can start using my new identifier, but that will give me brand new
accounts on all the sites I frequent.

Can we solve the desire to be able to change my e-mail address (or in the
future, some other kind of identifier) and have it be a decent experience
using Persona?

[Lloyd Hilaiel]

Approaching it from the technical side, all an RP would need is a pair of assertions. Here is the email address you know (vouched for with an assertion), here is the user's new email address (same).

From a UX perspective, what would be optimal for the site? Would the user find the "change email address" button on the site? Or would the user initiate the change inside the dialog at login time?

I can't imagine the latter can work well. How do you make a sane UX where the user can select the old email address and then indicate a desire to migrate and then select the new email address without muddling up the 99% case of just logging in using the last used email address on this site?

So building off that unqualified assumption, suppose we make a feature where the site can cause the prompt window to be opened to the user with a UI that is customized, showing the user's current email address they're logged in with on the left, and the other available email addresses the user has verified on the right with a title like 'Change your email address on "SiteName"?'.

Is there a different approach that could work better? Is this feature something that should be prioritized over all the other stuff we're working' on?

lloyd

[☮ elf Pavlik ☮]

Excerpts from Sean McArthur's message of 2012-10-29 18:36:24 +0000:

> This was brought up by the tent.io guys, but it's relevant to everyone. I
> may start using Persona by logging in with my Gmail account. But
> eventually, say Gmail becomes (more) evil, or I simply want to move to my
> own domain, there is no way to use Persona to login with my new identifier.
> I can start using my new identifier, but that will give me brand new
> accounts on all the sites I frequent.
>
> Can we solve the desire to be able to change my e-mail address (or in the
> future, some other kind of identifier) and have it be a decent experience
> using Persona?

it seams to me that it would require from your IdP option to set your new address + plus flow similar to HTTP 301 , otherwise one would need to have access to list of all services one used with persona and update this information in all of them...

[Dan Callahan]

On 10/29/12 1:50 PM, Lloyd Hilaiel wrote:
> Is there a different approach that could work better?

From what I understand, the Tent approach basically lets RPs set up a
webhook to be notified when a user changes or migrates their identifier.
This is evidently a central part of the Tent architecture. And I find it
really interesting.

In that model, it's less about changing your identity on a single site,
and more about being able to broadcast a replacement identity to sites
that you use. Unlike Tent, we don't have the advantage of a canonical
list of all the sites I use, since we only store those associations in
localStorage and don't persist them anywhere else.

But what if we did? (Firefox accounts?)

And what if we, say, added a property to `watch` like `webhook:
http://rp.example/api/browserid_updates`? Persona's conventional use of
email addresses gives RPs a way to communicate with their users, but
what if RPs could (optionally!) give Persona a way to communicate back?

(Or maybe this could be part of an RP-side .well-known workalike? It
could maybe be a conduit for Persona auth without JavaScript, too?)

> Is this feature something that should be prioritized over all the other stuff we're working' on?

This is low priority for us within the next few quarters, but I do think
we should start sewing the seeds of discussion now.

-Callahad

[Lloyd Hilaiel]

On Oct 29, 2012, at 1:19 PM, Dan Callahan <dcal...@mozilla.com> wrote:

> From what I understand, the Tent approach basically lets RPs set up a webhook to be notified when a user changes or migrates their identifier. This is evidently a central part of the Tent architecture. And I find it really interesting.
>
> In that model, it's less about changing your identity on a single site, and more about being able to broadcast a replacement identity to sites that you use. Unlike Tent, we don't have the advantage of a canonical list of all the sites I use, since we only store those associations in localStorage and don't persist them anywhere else.
>
> But what if we did? (Firefox accounts?)
>
> And what if we, say, added a property to `watch` like `webhook:http://rp.example/api/browserid_updates`? Persona's conventional use of email addresses gives RPs a way to communicate with their users, but what if RPs could (optionally!) give Persona a way to communicate back?

I can see various approaches along the spectrum that we can tackle this… but...

Anything that adds complexity to a website using persona makes me nervous. Is email (generally identity) change so pervasive that it makes sense to require all websites who use persona to consider it up front?

Now if we don't make this a required feature of using persona, will a sufficient number of high value sites implement it that the feature is actually useful to users?

The spectrum seems to me at first thought to break down into:
1. not important: focus first on mainstream adoption
2. important but not worth making implementation more difficult: understand what we can do in persona to streamline the "change my identity" flow.
3. fundamental: implement client-side features to automatically migrate for websites who write code to handle the feature. (maybe after one changes an email on one site, we detect and automatically change email address upon visits to subsequent sites. I'm scared. Hold me.)
4. pervasive: make this a core part of the protocol to ensure 100% adoption and hence a meaningful user facing feature "update my identity on all the sites I visit"

I fall in at 1.5 on this one (pending data), and somewhere around 3 on the features afforded by .watch()…

It sounds like tent.io folks are placing a big bet on the user value of "change my identity everywhere" and fall in around 3.5?

lloyd

[Melvin Carvalho]

On 29 October 2012 19:36, Sean McArthur <smca...@mozilla.com> wrote:

> This was brought up by the tent.io guys, but it's relevant to everyone. I
> may start using Persona by logging in with my Gmail account. But
> eventually, say Gmail becomes (more) evil, or I simply want to move to my
> own domain, there is no way to use Persona to login with my new identifier.
> I can start using my new identifier, but that will give me brand new
> accounts on all the sites I frequent.
>
> Can we solve the desire to be able to change my e-mail address (or in the
> future, some other kind of identifier) and have it be a decent experience
> using Persona?
>

Just pick your email address carefully!


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

[Dan Mills]

Hey,

TL;DR: we will eventually need to support changing identifiers, but it's not clear when/how.

A problem with email addresses (and indeed, any decentralized identifiers) is that they change ownership over time. Domains change owners, people move and change ISPs (and their ISP address), students leave school (and lose/change their school address), etc. Sometimes the change is intentional and planned, sometimes not. Either way, there is definitely some pain when it happens--it's akin to having to change your physical address.

At the same time, I have also explicitly decided to punt on this problem thus far. I think that our current API is sufficient to cover a good range of use-cases and get adoption, and we can work on this problem later. Sites that really care about this issue can implement multi-email accounts, and email change processes without any help from our front.

That said, it's clear to me that a *good* agent would provide users with tools to minimize any pain that comes from this situation. I don't think that (in a decentralized world) either sites or identity providers are in a position to really help, other than by integrating with the UA. I have been supportive of e.g. the watch() API in part because I think it lays down some of the foundation required to eventually mitigate this problem: 2-way communication between the UA and the site, initiated by the UA.

So... let's discuss and evaluate whether RPs/users need this now, or whether we can punt further. I think we can punt for a couple of quarters, but it would be valuable to start talking about possible approaches now.

Note that without centralization, we can't actually *solve* 100% of this problem: some users will lose access to an identifier, and not be able to switch. This is akin to what happens today if a user forgets their password *and* loses access to their email account. This recovery path is hard, and out of scope for this discussion IMO.

Dan


On Monday, October 29, 2012 at 12:30 PM, Lloyd Hilaiel wrote:

> On Oct 29, 2012, at 1:19 PM, Dan Callahan <dcal...@mozilla.com (mailto:dcal...@mozilla.com)> wrote:
>
> > From what I understand, the Tent approach basically lets RPs set up a webhook to be notified when a user changes or migrates their identifier. This is evidently a central part of the Tent architecture. And I find it really interesting.
> >
> > In that model, it's less about changing your identity on a single site, and more about being able to broadcast a replacement identity to sites that you use. Unlike Tent, we don't have the advantage of a canonical list of all the sites I use, since we only store those associations in localStorage and don't persist them anywhere else.
> >
> > But what if we did? (Firefox accounts?)
> >
> > And what if we, say, added a property to `watch` like `webhook:http://rp.example/api/browserid_updates`? Persona's conventional use of email addresses gives RPs a way to communicate with their users, but what if RPs could (optionally!) give Persona a way to communicate back?
>
>

> I can see various approaches along the spectrum that we can tackle this… but...
>
> Anything that adds complexity to a website using persona makes me nervous. Is email (generally identity) change so pervasive that it makes sense to require all websites who use persona to consider it up front?
>
> Now if we don't make this a required feature of using persona, will a sufficient number of high value sites implement it that the feature is actually useful to users?
>
> The spectrum seems to me at first thought to break down into:
> 1. not important: focus first on mainstream adoption
> 2. important but not worth making implementation more difficult: understand what we can do in persona to streamline the "change my identity" flow.
> 3. fundamental: implement client-side features to automatically migrate for websites who write code to handle the feature. (maybe after one changes an email on one site, we detect and automatically change email address upon visits to subsequent sites. I'm scared. Hold me.)
> 4. pervasive: make this a core part of the protocol to ensure 100% adoption and hence a meaningful user facing feature "update my identity on all the sites I visit"
>
> I fall in at 1.5 on this one (pending data), and somewhere around 3 on the features afforded by .watch()…
>

> It sounds like tent.io (http://tent.io) folks are placing a big bet on the user value of "change my identity everywhere" and fall in around 3.5?
>
> lloyd
>
> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org (mailto:dev-id...@lists.mozilla.org)
> https://lists.mozilla.org/listinfo/dev-identity
>
>

[Dan Callahan]

On 10/29/12 4:20 PM, Dan Mills wrote:
> Note that without centralization, we can't actually *solve* 100% of this problem: some users will lose access to an identifier, and not be able to switch. This is akin to what happens today if a user forgets their password *and* loses access to their email account. This recovery path is hard, and out of scope for this discussion IMO.

+1. Perhaps a good limit would be looking at the case of a user
proactively moving accounts? E.g., the "I'm exa...@gmail.com, but now I
migrating to m...@example.com" use case.

The RP would also need a way to signal rejection of the change back to
the UA. ("Sorry, your account's address can't be changed; it's part of
example.org's site license.")

-Callahad

[Sean McArthur]

Like its mentioned earlier, Tent requires this to become an IdP. I think
that could be pretty big, since it would mean that as Tent grows, anyone
with a Tent account automatically has a primary IdP-backed identity. I can
see it now being a priority yet, but definitely agree about having
discussion now, and I'd like to possibly focus on this for my Fun Fridays.

[Ben Adida]

On Monday, October 29, 2012 at 2:35 PM, Sean McArthur wrote:
> Like its mentioned earlier, Tent requires this to become an IdP.
>
>

Can you describe this a little bit more? Maybe a specific detailed use case where this feature is required and cannot be fulfilled by current API?

I'm having trouble seeing how this comes together.

-Ben

[Sean McArthur]

Certainly. Tent expects that most people would use it on a tent-provider
(such as tent.is), and a tiny minority would bother to setup their own
hosting (say seanmonstar.com). I can start of using seanmonstar.tent.is. If
they also provide me IdP support for Persona, then I can log in to some
sites elsewhere using it. However, at some point, I feel tent.is is being
mean, and decide to move to seanmonstar.com. The Tent protocol will update
itself because of my move, letting all my followers and such know, and I
don't have to do a thing. However, if I then try to login to sites I've
logged into before with my Tent account, it now has a different identifier.
That's not what I wanted.

[Dan Mills]

I agree - the responsibilities are (IMO):

Sites: to facilitate identifier changes, either by implementing specific UX flows (as they would need to do today), or integrating with a UA-provided API for that purpose.

IdPs: probably nothing. At most, to notify/inform the UA if there is a connection between identifiers (e.g., f...@example.com == foo...@example.com).

UA: help user change identifiers if/when the user wishes to. Automate when possible, but respect user intent and recognize that user might not want new identity to be broadcast to everyone currently in knowledge of the old identity.

I understand some IdPs might want this problem to be solved, because they recognize their users will come and go and they want to do the right thing for them. But ultimately I think their role in a change of identifier flow will be fairly limited.

Dan

[Ozten]

Are there "change email address" cowpaths to be paved?

[Daniel Mills]

Although many sites do have this functionality, I am not aware of any real convergence upon a standard flow we could provide.

Dan

On Oct 29, 2012, at 4:10 PM, Ozten <aust...@gmail.com> wrote:

> Are there "change email address" cowpaths to be paved?

> _______________________________________________
> dev-identity mailing list
> dev-id...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-identity

[Forbes Lindesay]

My concern with automating this too much is that one of the nice things about the browserID protocol as it stands is that it's easy to login with addresses like:

sale...@mycompany.com

which then follows the role, rather than the user. I suspect that the majority of people still only go through about 4 e-mails (not counting work e-mails or e-mails intended to catch spam) in their lifetime. So I'd say this can probably be punted later.

[Jan Wrobel]

On Fri, Nov 9, 2012 at 12:49 PM, Forbes Lindesay <for...@lindesay.co.uk> wrote:
> My concern with automating this too much is that one of the nice things about the browserID protocol as it stands is that it's easy to login with addresses like:
>
> sale...@mycompany.com
>
> which then follows the role, rather than the user.

Actually it is not that easy. I wanted to create a guest Persona
account for a demo of a Persona authenticated service (something like:
visit example.com and sign-in as 'gu...@example.com', pasword
'guest'). But there are few problems with something like this:

1. Everyone can change password of the guest user or delete the guest
account (Persona does not verify email on such actions).
2. If you are already using Persona, you can't add gu...@example.com
to a list of known emails, because Persona won't ask you for the guest
password, but for a verification of an email sent to
gu...@example.com. You need to sign out from your Persona account and
sign in to the guest account.
3. If someone by mistake adds one of his own email addresses to
gu...@example.com account (probably an easy mistake to make), everyone
is able to authenticate with this email.

As I understand it, Persona currently does not seem to be suitable for
assigning roles to a group of users, it seem to follow single email
belongs to a single user paradigm.

Cheers,
Jan

[Forbes Lindesay]

True, at the moment this still needs some work. It is great, however, for situations where the IDP is properly supporting persona. You could have a guest account not require any password at all, and have ad...@example.com delegate to asking the user to sign into example.com with my-...@example.com because example.com knows that the position admin is held by the person my-name.

The fall-back provider could perhaps use more work on this front. Perhaps it should verify e-mail when changing the password (which would solve one of the problems you faced). And perhaps it should do more to ask you whether you want to link the accounts or keep them separate. tbh I'm not sure I see the merit to linking accounts at all (e-mails are easy to remember).

[brandy...@gmail.com]

On Monday, October 29, 2012 12:30:41 PM UTC-7, Lloyd Hilaiel wrote:
> Anything that adds complexity to a website using persona makes me nervous. Is email (generally identity) change so pervasive that it makes sense to require all websites who use persona to consider it up front?

Personally (as a website developer of sites with long-term users) I would never use an email address as a user's identity. As a login, it's fine, but under the hood every user has a unique ID which persists for all of time as their email, passwords, and even username might change from time to time.

Rather than adding complexity with email-changing messages, why not just create a unique ID for each user and pass that instead of an email? (Or, since you already pass an email, for backward compatibility, pass a unique ID in addition to the email. Then sites can choose to anchor on either one; and sites that anchor on the unique ID can now easily notice that the user's email has been changed, which is just kind of a side bonus for them since the ID takes care of Identity and authentication.)

You already have a unique ID -- whatever the back-end at persona.org uses. (Or use a long-enough hash of their public key, or whatever.) Just give me that when a user logs in, and I don't care about email addys. No added complexity.

-Brandyn

[brandy...@gmail.com]

(Though from there it would only be a small change to the UI--and none to the API--to allow people to maintain multiple identities. Essentially what you have now, just shifting the selection to a unique ID independent of the email, and let people assign whatever email they want to each one [reuse ok] or none at all [for consistent but fully anonymous ID, for sites that allow it]. With an API change, for each Persona, you could allow people to fill in a list of optional attributes such as name, email, username, etc, and just pass this dictionary along with the Persona ID when someone logs in. Now you've covered essentially all use cases with a very simple API [Persona ID, attribute dictionary (which covers email)], and sites can decide on their own how to handle it when the attributes change [most should just update their own fields to reflect the change]. As a user this allows me to have a Persona for the real me, one for my pen name, and a Dohn Joe account when I prefer to be anonymous. Down the road it would be nice if you could designate one of your personas the "real" you--perhaps verified by other stricter means [credit card, etc]--provided ultimately the login interface is given a distinct look and placement that javascript cannot emulate so that Persona becomes *more* secure than existing web login strategies. Yeah, I realize some of these ideas may be at odds with your goals... I'm just voicing as a developer and potential user what I personally think would be both simple and robust/enduring.)

[Sean McArthur]

I've thought about that some, as well. Unfortunately, it gets in the way of
hoping this system could be truly de-centralized. Where does this unique id
get stored? The goal is that persona.org fades out of existence, so we
can't log people in with Persona's userid.

It really seems like the only player in the system that knows who your IdP
is and what other places you've used as an IdP, and where you've logged
into with various assertions, is the browser. It seems like something the
User Agent could figure out, and try to make easier.