Användare:Skalman/BrowserID

Some thoughts on how BrowserID could be implemented on MediaWiki as an alternative way to sign in.

BrowserID is an authentication mechanism by Mozilla aiming to make it easier to sign in (just like OpenID and Facebook connect).

Key differences compared to OpenID:

• BrowserID uses email addresses as identity
• Privacy: The BrowserID identity provider (IP) doesn't know which websites you sign in to
• BrowserID requires only one button for all IPs, and if you are already signed in to the browser/BrowserID you can select from a list of identities
  • With OpenID, if you don't have a special button for Gmail users they have to enter "https://www.google.com/accounts/o8/id" to sign in
• BrowserID is intended to be integrated with the browser (Mozilla is working on getting it into Firefox, others can implement it as well)

A BrowserID MediaWiki extension would add another authentication alternative by adding a BrowserID button. When you click that button you can choose among pre-authenticated email addresses (when signed in to BrowserID), and you're done.

Providing a simple, quick way to sign in and create an account could lower the barrier for participation.

Having Wikimedia as an identity provider would enable Toolserver scripts to authenticate a Wikimedia user. While BrowserID is possible for this use case, OpenID would be a simpler alternative, since Wikimedia usernames aren't nicely convertible into email addresses ("Example\ user"@users.wikimedia.org).

• Bots: BrowserID requires JavaScript for now, so bots would continue signing in by password
• Adoption: Other than some Mozilla sites, not many people are using BrowserID as of March 2012
• Maturity: The developer-facing code is fairly stable while the protocol is still in development

Because of these issues, BrowserID shouldn't be used on Wikimedia sites yet.

1. The user clicks the BrowserID sign in button

2a. No account associated with the email address

Suggest that the user:

i. signs in with username+password (if successful, also ask if the user wants to change his/her email), or

ii. signs up

2b. One account associated

The user is signed in

2c. Multiple accounts associated

Give a list of associated accounts

The user chooses one account

The user is signed in

0. The user is already signed in

1. The user chooses an email address

Until the user has verified the email address s/he may sign in using either the old address or the new one.

If the user uses the old address s/he is reminded that s/he should verify the new address.

If the user uses the new address before it has been verified, the user may sign in, but is presented with a button "Change email to <new@email> and sign in"

2. The user may choose to verify the email address either by (1) sending verification code to the email, like we currently do, or (2) verify with BrowserID

1. The user enters username

2a. The user enters email address and password

The user is asked to verify the email address, but is given the option to do this at a later stage (verification code or BrowserID)

2b. The user enters only email address

The user is required to verify the email address using BrowserID or enter a password

2c. The user enters only password

No additional steps

With Wikimedia as an identity provider. This scenario is not better than the corresponding for OpenID.

1. The user enters Wikimedia username (because of weird email addresses)

2. A script on the Toolserver page generates the corresponding "email address", e.g. "Example\ User"@users.wikimedia.org

3. The user authenticates that email address

4. Now the Toolserver script knows that this is indeed the owner of that Wikimedia account

• It will co-exist with the current password based authentication (using AuthPlugin)
  • Possible option for new wikis: disable passwords
• While a simple version of this extension would verify the ASSERT by letting https://browserid.org/verify do the check, we should implement a local signature check for better scalability