 Okay, thank you everybody for coming. I don't know how many of you were at Drupalcon Denver, but one of the keynotes from Drupalcon Denver was Mitchell Baker. So she's the chairperson of the Mozilla Foundation. And one of the things she spoke about was a new sign-in technology called Persona. And one of the main advantages of this is that when you sign in with Persona, the website you're signing in to never gets to see your password. So there's a lot of advantages to that. So I wanted to use this myself, so I'm a Drupal developer, so I wanted to see what Drupal modules there were. So I found one module, first of all, called Bruiser ID, which is the old name for Persona, and it also implemented the older protocol. And then I found another module called Persona that used the new name, it used the new protocol. So that was great, but I had a look at the module, and I basically wanted to rearrange a lot of things. So I started submitting patches, and I think the maintainer got so fed up with me submitting so many patches that he gave me commit access to the module. And then I just ran with that and made a huge number of changes. And I think the module is now very stable. So I joined the mailing list for Mozilla Identity and told them about the module, got talking to them. And Dan, he is the project lead for the Persona project. He sent me the t-shirt for Persona. And then I suggested that he should come to DrupalCon and tell us all about Mozilla Persona. So if we can all give a very warm Drupal welcome to Dan Callahan. Thank you. It was great. I get this email from Johnny saying, oh, I've got this talk submission in for DrupalCon. You should totally come by. Oh, yeah, sure. He's like, well, you'll give the first half of the talk. So here I am. That's clearly the way to do it. So I'm here to talk about how we as a community, we the Drupal community, are going to kill the password on the internet. And the way we're going to do that, I hope, is with Mozilla Persona. Persona is a login system. It replaces emails and password forms. It replaces social auth on your own website. And it works on the basis of verifying email addresses. So I'm here to talk about how we as a community, we the Drupal community are going to kill the password on the internet. So let me show you what it looks like. So I've recorded a screencast of me logging into a few websites using Persona. I'm going to start with raygun.io, which is an error production application, error tracking app. I'm given an option of logging in with an email and password or a number of different protocols or other methods. I'm going to click on Persona. When I click there, my browser prompts me to enter an email address. I can enter any email address I want. And in this case, I'm going to use my work address, decalahanatmozilla.com. And when I click next, you'll see very briefly the dialogue says, checking with your email provider. So it's going and looking at mozilla.com and it finds that mozilla.com understands the Persona protocol because we eat our own dog food. And I get forwarded on to a login page, specifically for me to log into my corporate account. It's hosted by Mozilla. I type in my normal LDAP password just as if I was logging into webmail at work. I hit sign in, my email address has been verified, and I'm logged into raygun. Now that I've logged into the site once, now that my browser knows who I am, when I go to other websites and click sign in, if they use Persona, notice that my email address is already pre-filled. My browser now knows who I am, so it only takes me two clicks to log into additional websites. One, to open the email picker. And two, to confirm that I actually want to sign into that website. After I've used Persona once, I'm never more than two clicks away from logging into another website, even if I've never visited that site before. Of course, we understand that people have different identities online. Me at work is not the same as me at home. And so if I want to use my Gmail address to log into my open badges backpack, I can simply click the add another address button. Type in Dan Callahan at gmail.com. And when I click add, just like my Mozilla address sent me to Mozilla to authenticate, a Gmail address sends me to Google to authenticate. One additional click. And I'm signed in. So I've signed into three sites with a total of seven clicks. It's very, very simple, very, very easy, very low friction. And none of these sites are receiving a password. None of these sites receive any sort of secret that they have to worry about storing and securing. So now I want to go to another website, Ting, which is a mobile phone service provider in the U.S. The question is, was Gmail running a special service? Sorry, pause the screencast. Mid-load. To support persona? I'll answer that in just a minute. But now my browser's seen two identities of mine, my Gmail address and my work address. And so I'm giving this picker where I can very simply choose, what a third address I wanted to or a fourth. If I can choose one, click sign in, even if I've never previously used that site. So that's the way persona works. It's very, very simple, very, very easy to use. Of course, I demoed that in Firefox. Mozilla understands that the web is bigger than anyone browser. It's bigger than anyone email provider. And it's bigger than anyone social network. So persona today works with any email address on any major browser. Everything from mobile Safari or Chrome on iOS out to pretty much any browser on Android, Internet Explorer 8 and up, work great with persona. And what you effectively get is a button that lets you sign users into your site with their email address, but without you having to worry about storing, receiving, touching passwords at all. Because when you put persona behind that button, persona intelligently routes your users to an appropriate login endpoint. For Mozilla users, for Mozilla employees, we go login against our corporate LDAP server. For Gmail users, we login against Google, Yahoo against Yahoo. And it only gets better. So you implement persona once, and you already have a strict super set of all of these social providers. And any domain at any time can advertise support for persona and immediately start receiving users and having people directed to it. Of course, if you use an address, say your own corporate address that doesn't support persona, persona's configured to fall back to a normal email challenge, so we send you a link, you click on it, you've proven your address, done. So the same sort of thing that you would have to implement yourself if you wanted to support any email address, persona does by default. But for domains that support it, users have an enhanced smoother flow that works with their existing authentication endpoints. Of course, like everything Mozilla does, persona is open source, and like the web itself, it's decentralized. We're not trying to get between you and your users, we're trying to define a protocol that the browser itself can use to figure out how and where to authenticate you. So today, persona exists as a web service. Today, persona is a reference implementation of a protocol, but our ambitions are much more audacious. We want persona to become the next standard for authentication on the web. We want persona to be baked into browsers and we're going to start leading in that direction early next year when we start building persona into Firefox directly. Firefox. Why does a browser vendor, why does Mozilla care about passwords, why are we trying to address login? So though Mozilla is best known for building Firefox, we're a nonprofit. We're a global community, just like the Drupal community, representing tens of thousands of volunteer contributors all over the world. We exist to make sure that the web remains an open and accessible and interoperable place that's built on standards, not solely controlled by advertising firms. The Mozilla Foundation, the nonprofit that shepherds the direction of the Mozilla projects, codifies its work in the Mozilla Manifesto, a 10-point manifesto of the open web. This was developed at the height of the browser wars when the Internet Explorer Netscape Divide threatened to split the internet into mutually incompatible realms. But some of these points, number two, that the internet is a global public resource that must remain open and accessible, apply much more broadly than just to browsers. Number four, individual security on the internet is fundamental and cannot be taken for granted or cannot be treated as optional. Number five, individuals must have the ability to shape their own experiences on the internet. Each one of these points, each one of these bullets in our manifesto apply equally to the browser wars as they do to identity. Each one of these is facing a grave threat. Social authentication threatens to split the internet and close it off, completely eliminate the ability for certain classes of people to access entire classes of websites. If you live in a country that blocks Facebook, you cannot log into a site that uses Facebook Connect. Furthermore, social auth robs users of the ability to choose who they trust, who they are, and how they represent themselves on the internet. And passwords, security, it is extremely difficult, extremely difficult to do security correctly. Is there a question in the back? So what about countries blocking Mozilla? Part of that comes into the idea of persona being decentralized, so there is no necessary point that flows through Mozilla. I'll discuss the protocol at the end of the talk. So yeah, if you have further questions, please feel free to raise your hand or bring those up whenever. So let's look at where we've come. Authentication is hard. Authentication is really hard. This is what a login screen looked like 25 years ago. And you can recognize it as a login screen because it has an email address and a password field. What's my user ID at Prodigy? What's my password and a sign in button? Here's the login screen today. You can recognize it as a login screen because it has those same two fields. So the way that we've logged into websites, the way that we authenticate on the internet has not changed meaningfully in a quarter century. But what has changed is the frequency and the quantity of sites that we log into. Passwords are a pain. Passwords are fatiguing. They're difficult to use. There are alternatives. Some sites like Strava have started offering something like a Facebook Connect button or a Google button. This is nice from a user experience standpoint. If I'm willing to use Facebook, I don't have to worry about passwords. But it changes the authentication question into one of not do I want to log into Strava, but it turns into a trust question. Do I trust Strava to act responsibly with the information that I am forced to disclose as part of logging in with Facebook? Do I trust them with my social graph? Do I trust them with my name, my photo, my list of friends? And I'm only given the option of Facebook. If I wanted to log in with my Gmail address, I would have to, again, shoulder the burden of managing a password. And I'd have to hope that Strava does the right thing and stores that password using an appropriate hashing function, using appropriate salting, using appropriate work factors. And I can't be sure of that, just like they can't be sure that I choose a strong password. So what do you do? I don't have choice here. I don't have multiple choice. Stack Overflow just adds more buttons. So I can choose Google, I can choose Yahoo, I can choose Facebook. There are literally a dozen buttons on this page. When I started giving this talk, there were 13. The button on the kind of far bottom left, the little green circle with an eye in it, that's my open ID. That's shutting down, I believe, in February of next year. So soon this will be 11 buttons, which is a problem. But how do I even pick a button? I have an account literally with every single one of these providers. How do I pick the right one? How do I pick the same one when I come back two weeks later, two months later, two years later? But it's more than a user experience problem. Social Law, you're only providing users options that you yourself select. There's only a white list that each site will select. So if I wanted to log in to Stack Overflow using my GitHub account or using my Twitter account, I don't have that option. I have to choose between one of those pre-selected services. And when you suggest that your users, when you force your users to log in with something like Google Plus or Facebook, you're saying that you as a site owner, as a site builder, accept the fact that you're going to be phoning home to a for-profit corporation half a world away and asking for permission to talk to your own users. It means that you're fine with things like a real name policy that Google Plus and Facebook have, if your real name is insufficiently Western that you have to provide paperwork to prove that it is your name or they will kick you out. It appears that your name does not comply with Google Plus real name policy or Google Plus names policy. It will be suspended until you edit your name to comply or appeal with additional information. Social Law means you're accepting, imposing the whims of third-party terms of service on your users and accepting the fact that if your users get banned from Google Plus or banned from Facebook, that you're fine with them unable to access your own site. But maybe it's worth it to get rid of passwords. Social Law does get rid of passwords quite well, but it shouldn't have to mean giving up privacy. Who remembers getting this email? Oh, at least one hand. Yeah, yeah. That was unfortunate. For those of you that are not familiar with the issue, on page 42 of the Drupal Watchdog Magazine that you got in your swag bag, Holly Ross discusses Drupal.org's response, the Drupal Association's response to Drupal.org compromise. Under the heading, the immediate aftermath, she writes, we were very fortunate that members of the Drupal Security team were on hand, along with the Drupal.org infrastructure team and Oregon State University's open source lab to diagnose the severity of the problem, mitigate the issues technically, and work with Drupal Association staff to formulate and implement a public response. The team went to work immediately to determine the scope and severity of the issue. They took down non-essential sites. They combed logs for more information, put up loads for anything suspicious. Checked the integrity of project downloads. The infrastructure team started rebuilding servers that had been affected. The team also deployed PHPAS password hashing, removed admin access for non-active users, and then with all of that done, the scope and the breach identified, the next step was to execute the password reset. Do you have a question? So that is an absolutely exemplary response. The Drupal Association brought to bear an amazing team quickly, competently, and effectively to mitigate the loss of the Drupal.org account database. Unfortunately, I don't know about you, but I don't think this generalizes. I don't think most people have time or resources or money or even the awareness to properly respond to an event like that, to a compromise like that. And so not only is it challenging to do that, if you're managing a couple dozen sites, how do you do this for each one? How do you even know when a site gets compromised? It's also a problem because about the best password policy you can hope your users have is that book right there. If your users are writing down their passwords, they are well beyond, well better than most people on the internet today. Most people on the internet memorize three, maybe four passwords and maybe have slight variations from site to site. Which means that when Drupal.org was compromised, sure, that database leaked, but it leaked in a way that allowed most or at least many of the passwords to be reversed out of their hash, which put users at risk at every other site where they had reused that same password. And so even though Drupal.org did the right thing in resetting passwords and making people come up with new ones, it still leaves countless people at risk on countless other websites and there is nothing that you as a site owner or there is nothing that you as a user can do to mitigate this. You have to know that a site got breached. A lot of sites aren't as forthcoming about what happens. And what about you as a site owner? Even if you're doing everything right, you're using sCrypt, using per user salts, you have an appropriate work factor, you're storing an additional salt outside of the database that the application uses. None of that matters if someone is able to learn the plain text of your user's passwords through another source. There is no way to win with passwords. So what can you do? I hope that using Mozilla Persona is one of the things that you consider on the next site you build. If Drupal.org had been using Persona, there would have never been anything derived from a password to steal in the first place. That breach could not have resulted in the collateral damage that it did. So how does it work? I've told you that Persona gets rid of passwords, I've told you that Mozilla doesn't want to be a part of this, Mozilla doesn't want to be in the middle of you and your users, but what's actually going on? In any login transaction, there are three parties. Your browser, your email provider, and the site that you want to log into. The first thing your browser does, we're using completely standard public key crypto, your browser generates a public-private key pair and presents the public key to the email provider and asks them to sign a proof of identity. It says, hey Gmail, can you please certify that I really am who I say I am? And if so, you get a sign certificate back, and it stores it, and it can then present that certificate to websites as a proof of identity. Of course, that website has to verify that the certificate is legitimate. So much like if someone showed you a driver's license, you have to check to make sure it has the right holograms to make sure that it's not some cheap forgery. So the website requests the public key from the email provider, verifies the cryptographic signatures, and if it all checks out, they can sign the user in. They never have to store a secret, never have to store a password. The nice thing is, once the browser has a valid certificate, until that certificate expires, that user can log into as many sites as they want without having to go and talk to their email provider again. What's more, the email providers can cache the public keys that they get, which means that sometimes, the email provider doesn't have to be contacted at all during the login transaction. Even when the email provider is contacted, Persona never reveals, the protocol never reveals who you are, who's trying to sign in. All that the email provider learns is that one of my users has tried to sign into this site, but they don't have a way to figure out who. So it's much more privacy-protecting than social auth, than open ID, and it's actually extremely easy to implement. But it relies on all three parties understanding and implementing the Persona protocol. If the browser doesn't support Persona, no problem. We have a polyfill, we have a JavaScript shim, you include it in your page, it works on any browser. If the email provider doesn't support Persona, and this is how we're able to claim that Persona supports any email address today, the browser will still do the first same step. It'll say, hey, email provider, can you please vouch for me? But that'll fail because the email provider doesn't understand the protocol. As a convention, Mozilla can step in and verify people for you. So the browser will try that same request, but it'll go to Mozilla and say, hey Mozilla, can you vouch for me until my email provider can do it themselves? And then Mozilla sends an email to that user. They click on the link proving to Mozilla their identity and then Mozilla signs the certificate. Same flow repeats, user presents the certificate to the site. The site tries to request the public key from the actual email provider, so we try the decentralized path first. We try to keep Mozilla out of the loop. And if that fails, then the site can opt to fall back and check Mozilla's key. And if everything checks out then, if the site trusts and believes in Mozilla, then the user can be logged in. If at any point a domain stands up and says I can vouch for my own users now and that's as simple as publishing a JSON document on the root of your domain, Mozilla immediately drops out of the picture automatically. We have carefully designed this protocol not to be something that puts us in the middle of your login transactions, but to be something that any individual part of it can immediately and automatically be replaced by a decentralized alternative as soon as that becomes available without any additional configuration, without any additional work on behalf of site owners or browsers. Four steps. Can you please certify my identity? Thank you. Here's the proof. Site verifies it. What we've built is we've built truly friendly public key cryptography. It's dead simple both for users and developers. You saw what it looked like for users. Jonathan can tell you about the Drupal module. Looks like there's a question in the back. So yeah, the question is the logic of the pop-up window is that on Mozilla site. It is right now. Persona is implemented as a JavaScript API. And so the plan is in the future browsers will have a native implementation of that API in the same way that you have a geolocation API. And for now we provide a JavaScript shim that uses persona.org to provide the UI. But if you're using a browser that has built-in support all of that interface will be hosted directly by your local browser. So that's one of the other things that you built so that you can just very, very automatically and easily does navigator.id exist? Yes? Okay. Ignore everything at persona.org. Use the native browsers parts. We're trying to write ourselves out of the protocol. And so we can work without browser support. We can work without support from email providers. We have polyfills. We have a fallback. What we cannot do, and this is where the Drupal community comes in, this is why it's so important that the Drupal community support persona is that we can't force websites to accept this credential. We can't force websites to leave passwords behind. And so it's incumbent on everyone in this room. If you believe the open web deserves better, then start with yourself. Use persona on your own site. Spread the word. Let Mozilla know. Let me know what we can do better. Persona is still in beta? We're responsive. We're very interested in building what is right for the web and we can't do that alone. We can only do that with the feedback and the input from communities like this one. So that's persona at a high level. I'm going to pass things off to Johnny so we can demo how the Drupal module works. I'll take one question real quick. So the question is how do you invalidate once you've signed into a website once? Using persona, how do you invalidate your browser's knowledge of your identity? When you sign into the website, you receive an identity certificate that is time limited. It never lasts for more than a day. It usually lasts for closer to one hour, the first time you use persona extending and so if nothing else, even if you walk away from the computer several hours later the certificate expires and if someone wanted to use that machine they would then be prompted to log into your email again. So as long as you're signed out of your email it takes care of itself based on just expiration. Right, so if you're logged into Google and your persona certificate expires but you still have an active session with Google, the browser can automatically go and get a new one without any user interaction. So it's designed to automatically extend and unlike many public key-based identity solutions or crypto solutions like PGP where the root of your identity is within this key pair that you have to guard and keep secret and synchronize, with persona the root of your identity is with your email provider. So with any domain that you choose that's where your identity is and by logging in there you can automatically receive additional certificates, additional proofs of identity. Any other quick questions before we bounce over to the Drupal demo? So the question is, does persona actually generate the key pair for the user or how does that work? So persona depends on a pretty decent javascript implementation because we actually do generate a public private key pair locally in the browser using javascript. And so as a user the key pair you're using never leaves your local machine. You present the pub key to the email provider they sign that and then again locally your browser stores the certificate. The core difference between persona and something like OpenID is that we presume that the browser is an active participant in the login process and is able to actually do computation which allows us to build some really interesting privacy preserving features into persona. The question is, do we see this being implemented in the operating system level or just an environment outside of the browser at any point? Not necessarily we're very narrowly scoped in trying to solve authentication on the web when humans are in the loop so persona is also not great if you're doing something that's API centric but you could take something like the route that Amazon does where you sign into a website as a human using something like persona and then receive an API key for that sort of access but as far as building into the browser or into the operating system, not necessarily we have built it into Firefox OS so if you have a Firefox OS phone that has a native implementation of persona right on board it's kind of blurring the lines because Firefox OS is itself effectively just a browser. Cool. We'll have a full question and answer section at the end. Yeah, so Drupal demo and then happy to take more questions. Also, I have stickers up front so at the end of the talk please come by and grab some. Thank you. Okay, so now for the live demo. Okay, so this is the project page for the module so that's just drupal.org slash project slash persona and I've created a demo site so this is just a very simple drupal installation and it has persona installed so I'm just going to sign in just to show you how it works so we can sign in. It already knows my email address and I'm going to add another one so it's going to check yahoo.com Mozilla have implemented a connection with yahoo so if I want to sign in I can just type in my yahoo password so that quickly I was able to sign in to the website. So I have a couple of other example sites so this is my personal blog and of course if you've got a blog you don't necessarily want to enable anonymous commenting because then you can get a lot of spam but if you require people to sign in to your blog in order to post that's quite a high barrier to entry so on my blog I've enabled persona so again I can sign in and as easy as that I can start commenting. So in the Drupal community we have a lot of really great e-commerce solutions so one of those is the commerce module and there is a distribution called commerce kickstart so this is a stock install of commerce kickstarts and then I've added the persona module so I'm going to show you how easy it is to use persona in an e-commerce setting. So let's find a product that I want to buy I'm going to buy this water bottle out to cart go to checkout and then before I complete the transaction I just want to sign in just so they have my email address so I click sign in and select my email and that quickly I'm signed in and Drupal commerce is hard enough so it's transferred my cart into the new session and then I can go to checkout so I think you can really optimize your funnel if you use persona. Okay so this is a stock Drupal 7 installation so I'm just going to install the module and then show you what it's capable of so you download the module in the regular fashion enable the module is set up so by default it puts the sign in button into the header region in your theme so if I sign out we now have a persona sign in button so I'm going to sign in my admin account on this website uses my jbrown at bluedroplet.com email so I can just sign in and it's that simple so the persona module it actually it looks at your Drupal user account settings so Drupal can be configured to only allow administrators to create accounts or you can allow visitors to create accounts on your website so the persona module just looks at this setting so if you allow visitors to sign in then if a new user comes to your website with persona to sign in then their site on the Drupal website is just created transparently this is the settings page for the module so the first setting is set persona as the only sign in method so by default the module allows you to use Drupal's standard sign in methods or persona and you can switch between those and that's fine if you enable this option then it disables the sign in blocks disables the menu routes and all that sort of thing so if I sign out having enabled that option the sign in dialogue is gone you can if you just go to the user URL you can also sign in there or you should be able to hmm I don't know ah invalid background color okay I can fix this in a moment okay so I've re-enabled the module I will explain so there is a setting where you can configure the background color so I think it's just a problem with this form it just wasn't storing the value correctly but I think if I actually specify the color then that should work fine so there's number of options that control the appearance of the sign in dialogue so you can specify a logo the only requirement is that the logo has to be served over each TDPS because the sign in dialogue itself is served over each TDPS you can configure the background color and then you can provide links to terms of service and privacy policy so hopefully now that I've defined the background color we should get a background color yep so it's working so again the beautiful thing about open source is that this is an opportunity for anyone in this room to fix the bug with the background color not being initialized in the module by default so there's a few other options in the module so what happens if someone signs into your website for the first time what is their username so because the account is created automatically the username is automatically generated so by default it just takes the start of your email address as your username but it may be you just want to use email addresses for usernames in which case you can just enable this option you can specify it so whenever a user signs in for the first time they are redirected to the account edit page so they can fill out their profile and in a moment I'll show you some advanced workflows for that so you can actually enforce that when someone signs in for the first time they have to complete their profile before they can do anything else you can change the styling of the button so if you just set it to button this is just a regular button HTML element you can theme that however you like persona gives you the persona style button if you select form then the button is just rendered in the same way as any button on a form on your website and it was very easy to implement that just a couple of lines in the form it is translated so there is a module I think it's called string overrides so you can change it there so there is an advanced workflow using the rules module so I just created a couple of rules so it may be when someone signs in for the first time you don't want them to be able to do anything until they have completed their profile so just by creating a couple of rules I was able to do that so whenever they complete their profile they get given a new user role so you can have a role called registered so instead of giving all of the permissions to the authenticated user role you might want to have the same permissions for authenticated user as anonymous user but then have a registered role and then give all the additional permissions to that role so the rule then it gives you the registered role it gives you a message thanks for registering and then redirects you to the front page of the website this role just checks so whenever Drupal is initializing if you have the authenticated user role but you don't have the registered role then it just redirects you to your user at a page so I'll just show you a demo of that so let's sign out and sign in as a new user so there is no user on this website with this email address so we've been redirected to the edit page so we have to complete our profile so all being well if I try to go anywhere else on the website I am redirected to the edit profile page and this date of birth field is actually a required field so if I try to save the form I can't do that until I've entered all of the information so if I enable the takeover option those form items actually disappear so the question is will person eventually support transferring profile attributes like a full name or a photo for the users right now we are very very directly focused solely on proving email addresses and letting sites collect whatever additional information they need so we suggest a two phase if you need some of that information if you absolutely require two phase auth process where the user signs in with persona and then you present them with a minimal sign up form that just asks for that additional information the nice thing about that is that you can kind of you have an intermediate point in your funnel bringing users into your site so people hit that form and then bail out you still captured their email address and are able to ask them what was up and maybe retain some of those users but right now just for user experience reasons persona is really concerned with replacing passwords and not much else so just coming back to your previous point I'm just going to enable the takeover sign in option and show you what happens to the form ok so if I enable set persona as the only sign in method and then I switch to the other user if I try to edit my account there's no password field so one other thing I'm just going to demo is what happens if you have an account on a Drupal website and then you want to change your email address for that account so I've added some functionality to the module for that so I'll just delete this user perhaps I created it by accident I actually want this email address to be the administrator email address so I can go to my account just on my user page there's a change button so I can just click on that select my other email address and all being well that should become my email address for this account on this Drupal website and the username is only populated whenever you create the account actually and it's now insisting that I create my profile yeah yeah so the changing email that didn't actually work but we can fix that okay so that's the end of the demo so I just wanted to give you some takeaways so whenever you create a new Drupal website maybe a persona should be the first module that you install after you've installed Drupal in the Drupal community we also have a lot of distributions so every time there's a Drupal con or a Drupal camp there's a distribution called Cod which is used so it would be really wonderful if the persona module was in Cod and then any time you're signing up for a Drupal event you could just sign in very easily there's also Drupal commerce there's Drupal commons and also commerce kickstart so if you're interested in using persona maybe you should talk to the people who are responsible for these distributions and kindly ask that they enable persona by default and also if you're building a website for a client maybe you should tell them about persona and just ask if they want to use persona for their website so I think we're going to have a question and answer session yes I think we have about 10 minutes to do Q&A one thing to note before we go into that is don't forget to go and fill out the survey about what you thought about this presentation so we get some feedback on what the right message is for the Drupal community but I'm happy to take questions because of the social logins that we're used to we're also used as both website users and also website creators as relying on some of this profile information the fact that it fills out people's avatars it fills out all sorts of things how can we persuade clients or the people we work for or users themselves that maybe or even the companies like Facebook or Google that we should have this two-step process where login should be like a key to the front door and then maybe afterwards you fill in your profile information which should be separate but I think that's going to be a really tough argument to make when all the websites we've been making for the past few years have always relied on taking that Facebook information taking all the other stuff out of it so what do we do to make sure this is actually taken up as a standard for that so you're still presuming that you're actually receiving that you're actually getting users through your funnel that people aren't seeing the Facebook and seeing the fact that it makes it a trust question and backing away and there's nothing wrong with having authentication with persona and then asking users to authorize a social account to pull in additional profile data Airbnb does effectively that you log in with an email and password but then you can connect your LinkedIn your Facebook, your Twitter account something you can do is obviously you can use something like gravatar to pull images for user email addresses because you get an email address there's no lock-in with persona you can use your existing user database you can move two persona very easily you can move away from persona easily so this is portable sloblog.io is a blogging platform by this guy out in Germany and if I sign into that with something that they've never seen before have you ever signed into sloblog? okay cool so I'll use one of Jonathan's addresses Drupal Nomad at Yahoo when I sign in it goes and verifies that I still have an active session so if Jonathan was signed out of Yahoo this goes back to the earlier question about sessions if he had signed out of Yahoo in the interim that would have failed and it would have asked him to type in his password again sloblog is like well wait a second I've never seen you before it looks like you haven't used this address yet please pick a username and it's pre-filled a suggested username based on the email address a lot of email addresses take the form of firstname.lastname the discourse platform it's Jeff Atwood's new startup does the same sort of thing where it tries to intelligently guess one dot in the email address split that, capitalize the two words and suggest that as the full name so there are things you can do to provide sane defaults and then just give your users a chance to confirm and continue but if you really rely on deep profile data if that's crucial to your business and capturing it at sign up is crucial persona may not be the right solution other questions we checked in earlier but with the sort of questions in the middle you are logged into various sites using persona and then you want to give someone else immediately how can you make sure they don't have access to your user accounts on those sites so if you want to hand your computer over to someone immediately you mentioned signing out being a timeout automatically but if you know that the timeout is not going to be enough is there a central logout function? there is, you can so when this is built into the browser you will have a sign out button in the browser that will immediately invalidate everything if you in a persona dialogue click this is not me that will also immediately trash all of your certificates and force a revalidation we have data from google about shared devices and effectively computers people like the internet cafe scenario something that people also are concerned about and we start by issuing very very short duration certificates for that reason but we have evidence that when computers are shared or used by multiple people they are almost always shared amongst known individuals and trusted individuals if you're in an internet cafe then quite often the computer will actually reboot between users I'm thinking also people posting funny things on facebook walls on the wrong account lock your machine physical security yes so there are bad machines out there that don't reboot between users from a study of logins happening to gmail which is a very large in study the shared computer use case the bad shared computer use case is practically non-existent which is highly counterintuitive but it's apparently very very rare on the user interface so currently in the current implementation reference implementation it comes out as a pop-up is that the is that how you see this being implemented going forward regardless or could it also be say form fields on the site itself if it wasn't hosted by Mozilla so can we remove an extra step in terms of the flow and I'll ask my second question sure so we're not entirely certain what the user experience will be when it's baked into the browser the kind of default that people reach for drop-down panels little door hangers kind of like the security dialogue but given that we have to host the login page so persona doesn't specify at all how you authenticate so a mozilla user will login using our ldat password a mozilla employee a gmail user will login using Google's OAuth kind of authorization screen including a two-factor prompt we don't dictate how the email providers do authentication it has to be pretty flexible and so it's likely that it will be a door hanger and overlay or something in that vein as far as capturing things on the site we are about to extend the API to allow the site to pass into the dialogue the user's chosen email address so you could prompt the user for an email address on your site and when they click sign in it would already be pre-filled in the persona dialogue and you just have to authorize it because the login page have to be hosted at mozilla always is that part of the protocol? the entire protocol is designed to be decentralized the entire thing is completely you can complete today as it exists today you can complete a login transaction without mozilla ever being a party to any part of the transaction and my second question is where do you see the major attack vectors there's always I guess the chance of phishing which OAuth doesn't fix or tackle but where do you see the attack vectors I mean what happens for example if my email address changes like what's happening with yahoo it gets recycled or I lose my domain at some point and I had my email there etc we believe that the attack vectors the security model is roughly equivalent to existing email password systems just without the entire password compromise case in the picture so if someone owns your email address in terms of domain hijacking you let something expire you lose access to that domain in some way then the new controller of that domain is able to masquerade as you just as they could by going and clicking a forgot email link or forgot password link and getting that email I can make a point there where at the moment even if people aren't using persona if someone gets into your email account then basically it's over they can do anything so I think with persona it's the same situation you have to protect your email account because that's basically your identity is there any possibility to actually say kind of like the sign out but not a sign out to say well this email address has been compromised so there's no way to on a per address basis no way to do like a revocation list we're trying to manage that by issuing rather short duration certificates and letting those just expire and require regularly checking in with the email provider the email provider can if they are ever compromised simply start publishing a new public key and start signing with a new key pair which will immediately invalidate all of the existing certificates so we have mitigations available for site compromises one of the other things speaking to the interface real quick is that right now this is all implemented as a web form so if you load persona on a phone you get a mobile optimized experience whereas the desktop looks like that so we're really trying to be as webby as we can about this yeah a short question if you could move to the mic please with persona idea how you would implement forgot password scenario which scenario forgot password so the way you do it with persona is that the user uses their existing email account their existing account credentials so it would be the same way that you would handle forgetting your gmail password or your yahoo password because that is the password that you have to recover it's not the concern of the site anymore at that point take one more question if you have two separated drip installations and you use them usually together is there a way that you lock in one installation and you are locked in to installation and lock it out somewhere and you are locked out on both installations so the question is is there ability to do cross domain single sign on so if you run several dribble installations can I sign into one and be signed into all of them not currently we have a prototype of a feature that will do just that that we hope to push live in the next four to six weeks so very very soon one of the domains publishes a list that says I am part of a realm with all these other domains and then each member site also confirms and says I am a member of this realm and if those two things overlap and match up then we synchronize the login state across all of them so that is coming very soon I think that's all the time we have again please please please go and give us feedback and implement the module on your site it's a couple clicks we have stickers we are going to be hanging out asking questions, asking Jonathan questions thank you very much