Trade GUID for information

[migurski]

With a GUID in hand, a site or service provider should be able to ask the identity provider for additional information, e.g. an email address, avatar, or other information.

[junosuarez]

The identity provider doesn't know about the WebLogin token; similarly, the site or service does not know about the identity provider. As currently proposed, the browser doesn't necessarily remember the identity provider that was used to generate a given token, either.

It sounds like the best way to do this would be to have the site ask for that additional information ahead of time, eg

navigator.login({userDetails: ['email','username','zipcode']}) => Promise<token: String>

Not all identity providers will necessarily support the same set of meta data, and you run into the issue of semantic representation of these various fields. I'd like to avoid specifying this as part of WebLogin if possible. Identity providers might be able to make their best effort. Users should always be aware - and in control - of what information is requested / disclosed.

[junosuarez]

It's worth pointing out that this issue corresponds closely with the OAuth2/ OpenID Connect concept of claims as outlined in http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims

[ForbesLindesay]

This is the reverse of what I read from persona's lessons learnt. I think the e-mail should always be provided up-front, since pretty much all websites will ask for that. I actually think we should use that instead of any other token.

I then think any other information can be requested as an entirely separate step using an entirely separate protocol. There's no need for these protocols to be related (although both should definitely exist).

[darobin]

Ideally, the browser should remember which identity provider it used. Otherwise, the next time you need to log in it'll be up to you to remember (otherwise you'll get a different token), and that won't be fun.

I really think that any identity information should be kept completely separate from the login problem. It has been the doom of other attempts, it can readily doom this one.

Providing email means that the identity provider has to be trusted by the site because otherwise this could be used for spamming purposes (and is therefore no better than accepting email addresses without verifying them). But in turn requiring verification not just adds complexity, but also easily breaks down a key design aspect which is that your identity provider (or verifier) does not get to know what sites you visit. Or it involves complex schemes of indirection like Web Finger.

It also makes it easier to trick users into revealing their email addresses. That should not be easy.

In fact, ideally, Web Login should be implementable without a third party. It can work with just two components:

1. Your browser generates a new unique cryptoken for any site on which you do not have an account (with your agreement of course).
2. A safe wallet of sorts, that you can share across your devices/browsers with a master password, gets to store all the tokens. The wallet can be implement in such a way that whoever hosts it does not have access to its content (Mozilla Weave provides precedent).

That ought to be all you need to solve the login problem. Solving the "getting information from the user" problem, while related, IMHO needs to be kept orthogonal for sanity's sake.

[ForbesLindesay]

I really think that any identity information should be kept completely separate from the login problem. It has been the doom of other attempts, it can readily doom this one.

Identify and login are the same problem. Login is the problem of getting a verified identify for the user. It is true that the identify for that user doesn't necessarily need to be the same one used on other websites, or usable as a way of contacting the user.

User Experience

We need to think more about what makes sense from a user's perspective. "Pick an identity provider" is an impossible problem for most users. Either we have a predetermined, short list (e.g. facebook, google, twitter, in which case we would be better off with just classical social login buttons) or we ask the user for the URL of the service they wish to use as an identify provider (this is great for software developers, but hopeless for most non-techies).

We have to make sure that we only ever ask the user to answer questions they can easily answer:

1. Do you want to login/register - user clicks button
2. What is your e-mail address - user types in e-mail address
3. You will have recieved an e-mail with the subject "Sign Up To My Crazy Website", please click the link entitled: "Complete my registration" - user clicks the link in the email

or in the case that the e-mail provider supports login (e.g. if they enter me@googlemail.com)

1. Do you want to login/register? - user clicks button
2. What is your e-mail address? - user types in e-mail address
3. [user is redirected to the google OpenID/Oauth page]
4. Do you want "My Crazy Website" at "example.com" to have your e-mail address? - user clicks yes

The reason OpenID hasn't solved this problem is largely the fact that the user experience isn't good enough. It asks for a URL, which isn't how most users think of their own identify online.

Most users have two concepts of what identifies them online:

• username (we can't use this as it doesn't tell us what IDP to use)
• email address (this we can use, because it has the domain name of an IDP in it)

It's important to learn from Persona's mistakes (e.g. we shouldn't handle sessions, leave that to the application). But it's just as important to learn from what they got right.

Privacy - IDP tracking the user

There are two potential privacy issues you raised. I'll try and address the two concerns separately.

The first problem, as I understand it, is that the IDP should not be able to track which websites a user visits. Persona already has a protocol designed with this consideration in mind. One option is to simply steal that. A simple way such a thing can be done looks like:

1. The website generates a unique random number for the visitor (call this x)
2. The IDP is given x and asked to authenticate the user.
3. The IDP signs x along with the user's email address using it's private key, and publishes a public key at a well known location.
4. The website checks that x is the same random number it generated, and that the signature is valid.

In this way, the website knows the IDP (it already knew that from the e-mail) but the IDP does not know about the website, it just knows that the user logged into a website.

Privacy - website getting the user's email

The second problem you identified is that the website gets an e-mail address. It would be great if not all services asked for an e-mail address as the identifier, but the reality is that they do.

Our competitor is primarily websites who implement login themselves. We need to be a better option for all parties involved. For the user, that means being more convenient/easier to use. For the IDP that means making it easier to revoke a user id (in a corporate world, e.g. if I leave my current job I no longer get an e-mail address with them) and more convenient (in a consumer world). For websites, being better means that we must be more convenient/secure for users, while still providing everything they currently get. What websites currently get is an e-mail address. If they don't still get that, they aren't going to use it.

Consider also, the key selling point of persona: if persona disappears, at least you still have an e-mail address for each of your users, so you can choose another way to authenticate them. If all you have is a guid, you can't do this.

User's care about privacy, but they don't care enough about not revealing their email address for any service that offers hiding their email address as a core value to succeed. Website owners are the most important people for this to appeal to if it is to succeed.