Comparing Centrally and Locally Verified Memorized Secrets

then it's uh two minutes passed and uh i do guess that quite a few people still out for lunch uh but i'll next because jim fountain uh for those uh who knows jim he needs no introduction and for those who doesn't need no gym he's he's just amazing and he will introduce himself uh and i'm looking forward to this one as usual jim so please go ahead

thank you very much pear um so those of you that have been at passwords con just this morning may have already picked up on this if you've been a your passwords con regular you you know the pair likes to have kittens on all of the slide decks and my kitten is a little bit different it's a little bit pricklier than most kittens i i don't think my talk is necessarily prickly but it was just the picture that i had so i'm going to talk about um i'm and i'm going to use kind of the the formal terminology memorized secrets and the difference between the way that we usually deal with passwords and such uh that are stored

centrally like you know for logging into something uh and those that are that are used increasingly now for activating a multi-factor authenticator so i'm going to start with my usual disclaimer i'm a consultant for nist and i'm working on the revision of special publication 863 which uh deals with user authentication and there's another volume on identity proofing and another volume on federation but everything that i'm talking about here is my own opinion it's not i am not a nist employee i don't represent nist at all um but some of the things that i'm talking about here you may recognize uh if if and when you look at the the new draft that we hope will be coming out

not too far in the future but remember that everything it's that what what's coming out next is a draft and uh everything is subject to change in the review process uh and and by the way i this treats me very well and makes me feel like member of the family and i have a tendency sometimes to refer to nist as we and um just remember that it's just because they've they've made me feel welcome i'm not i'm not really a nist person so i get hung up on terms a lot um and so here's a few of them um memorized secret is kind of the formal term that we used in 863 revision three uh in order to

get away from the notion of password versus passphrase yes i mean if it's a if it's a password can i have a space in it of course it can but um i just didn't want to uh to uh necessarily limit the the scope of of what we were talking about and i've thrown past key in here and our next talk is on past keys so that's kind of a kind of a preview of that um but and and i apologize for the wordiness of this slide i just kind of like cut and pasted some definitions that i had um a couple of of things that may be new definitions new terms for you is what

what i'm referring to is an activation factor and that's when you've got a multi-factor authenticator and you uh need something in order to uh you need a second factor in order to use that authenticator that second factor could be a memorized secret and it could be a biometric an activation secret is the specific case where it's a memorized secret and that's really where i'm going to focus this afternoon is on activation secrets and how they compare with what we might think of as conventional or traditional passwords and what what their requirements should be now one of the things i'm going to actually go off slide for for a minute here one of the things that we did in

the previous revision of 863 we did you know all sorts of things that people have have noticed about memorized secrets recommending that they not be subject to expiration recommending that you not have composition requirements and so forth um but we kind of lump together what i'm now calling activation secrets with memorized secrets and applied many of the same requirements to activation secrets as other sorts of memorized secrets and in retrospect uh i think we we could have done better with with activation secrets um so here's here's here's what i'm talking about here and uh it's used to activate a multi-factor authenticator so examples of multi-factor authenticators are things like uh phyto tokens are things like smart

cards um but they can also be embedded authenticators where your um uh it could be you know an an app in a mobile device or something like that as well um in the case of uh an activation secret you can actually use that in order to derive the authentication secret you can essentially if you will encrypt the authentication secret with using the the activation secret as a key i realize it's not a very long key but we've got some other mitigations for for the the link that i'll be talking about usually the activation secret is something that's selected by the user uh there are some exceptions to that if you get a an atm card sometimes the bank will

choose a pin and maybe give you the option to to change it but usually selected by the user and that has a big effect on the um guessability of of the activation secrets and usually the activation secret if you've got an authenticator like a phyto token is uses the same activation secret for everything that that's uh that that that token uh is used to authenticate at so it's it's one activation secret per authenticator rather than per site that you authenticate at which means there's less to remember now this is this is where the uh the the real differences come in between activation secrets and other sorts of memorized secrets um the first one the first threat brute

force is really the same for both um you know an attacker can just just try and and guess either make an intelligent guess or a dumb guess and that can be done just as well with with an activation secret but a lot of the other threats are different um in the case of of a centrally stored memorized secret uh it's often involves the the cracking of some sort of a centralized authentication database that got x filtered somehow um whereas with the activation secret we'd be thinking since it's stored in the authenticator itself or or in the endpoint in a few cases um it's really you're thinking about the physical uh attacks on that and and possible side channel attacks

you know is there some way that you can maybe buy the um radio frequency it emits or maybe by the uh current drain those sorts of side channels might be possible for a multi-factor authenticator shoulder surfing actually is is similar to both although in the case of an activation secret it's really shoulder surfing plus they steal your authenticator so uh you know if you're at the if you're at the subway station and you're typing in your pin on your phone to to authenticate somewhere um be aware of your surroundings because that might be a situation where you'd have a combined attack where somebody watches you do that and then grabs your phone and then of course for for for regular

passwords there are you know password spraying attacks uh because people have a tendency to use the same passwords in on multiple sites uh so perhaps the same one that you used on some service that got breached might also be usable for your bank account whereas for activation secrets again it doesn't matter if it's the same activation secret for multiple sites um instead we're we're kind of thinking more about other sorts of forensic attacks you know sometimes if it's a pin and there's some sort of a dedicated keyboard for it maybe their particular keys that we're down more quickly or if somebody's very sophisticated maybe after you've authenticated maybe certain keys are warmer than others

so in order to take this into account there are a few dimensions a few different factors that we can uh address about uh how an activation secret should be constructed and how it should be uh how it should be used um of course is the composition question uh what characters uh the length of it uh the uh uh the the throttling i mean we i mentioned earlier about the the fact that there are uh that uh brute force attacks are a significant threat for both activation secrets and regular passwords and so the throttling is a is a very uh significant counter measure to that and and also block lists so um in most cases um uh activation secrets tend to be pins

and and in fact sometimes people equate pins with act with uh with uh activation secrets uh i don't tend to use that term because they aren't always numeric in fact uh for a for a fido token i can change my activation pin to abcdef and it's just fine with that as long as i'm using an endpoint that has an alphanumeric keyboard i can use that so since pin stands for personal identific personal identification number this is an instance of where i get hung up on terminology i try not to use that because i don't want to equate a multi-factor authenticator that uses a a memorized secret for activation i don't want to necessarily say that that

has to be numeric uh but given that they are mostly pins the the use of a pin of course just limits the entropy that you can get and the and the uh the activation secrets are usually very short like four to eight digits for being by far the most common but uh you know you do see examples of well and you see on people's phones i think apple has has pushed people to use more digits and so that's uh you know i think that's going to increasingly happen one of the things about length though is that there's you you might think that a six digit pin is one and a half times as good as a four digit pin

and it's not necessarily because there are different patterns that show up when you use a a six digit pin with four digit pins particular years like maybe a birth year or a marriage year or so forth show up with more regularity than other rent other random numbers with a six digit you get uh dates so you get a lot of you know uh 0 9 1 1 0 1 or something like that that aren't necessarily random as well and so just just because of the fact that different lengths of uh activation secrets lend themselves to different patterns you get uh different amounts of uh you don't necessarily get exactly what you might expect in terms of the uh

benefit from uh having a having a longer activation secret now nist recommends using a block using a block list on memorized secrets and um you know the idea is to avoid having people use things like paris license plate or one two three four five six or or things of that sort as a memorized secret and kind of the same recommendation carries through to activation secrets just because there are there are common values that you're pretty clear that you don't want to allow and i give some examples down at the bottom i think those are the the most common ten pins down there zero zero zero zero one two 3 4 and so forth the the difficulty with block lists is

that some authenticators have a very have very limited storage to keep track of a list of activation secrets that it shouldn't allow and unfortunately small block lists don't provide as much benefit as you would like to have part of the part of the issue there is that attackers will also know what what the block list is it will they will know that zero zero zero zero isn't allowed for this type of authenticator for example and so they won't try it and so essentially what you're doing is you're cutting off the the beginning of the probability distribution and just scaling everything up a little bit it ends up looking very much like the original probability distribution

but nevertheless we recommend there's that we again recommend including a block list more more than 10 if you can but we recognize the practical limitations of a lot of existing authenticators those 10 values that you're looking at there constitute about 14 and a half percent of the pins that people would randomly select given given an unconstrained choice there's a i'll have a reference at the end to this uh website from amateur he did an interesting experiment where he put a an app in the in the app store that did something else i forget exactly what it was but it also prompted for somebody to set a pin in order to to secure it and he kept track of the the uh he collected

uh quite a number of uh of pin values and uh was able to as a result do some research on uh pin distributions at least until he got kicked out of the app store because they discovered that

and the next dimension is is throttling and throttling is can also be a problem on multi-factor authenticator because what you'd like to do is you'd like to slow the attacker down without necessarily cutting off entirely because you don't you know sometimes somebody will fat finger their pin a few times and you don't want them to be necessarily locked out so what you'd like to do is to slow things down or give some warnings or something like that that says uh you know don't uh you know be careful the next time you type it in because this is your last choice or something like that well you can probably do that warning but you can't do the actual

slowing down because many of these standalone authenticators don't have a clock reference there isn't any they don't have a sense of time and they don't have any way of storing the state information about when the last bad attempt was smartphones will often do this but you know if you've got something like a a phyto token or a smart card that plugs into something else it's a little bit more problematic so as a result there's and even even when there is time based time throttling there is a hard lockout after a certain number of bad tries and the difficulty is that the limit needs to be small like 10 if the activation secret is short it's

kind of a trade-off there between making the activation secret longer more you know higher entropy you can you can tolerate a higher a higher limit but the one of the problems here is that you have this risk that you're essentially going to brick your authenticator at some point if you've so the the message here is and i think this is a general message not just for multi-factor authenticators is have a have a backup authenticator because this is not something where if your authenticator locks up you can necessarily call the it help desk and have them have them fix it for you now some some authenticators do have a second password update key it's essentially another a second pin

that the it department or somebody can use in order to reset your authenticator uh other authenticators like fido don't basically would you have your the the choice that you have with a with a fido multi-factor authenticator is that you basically need to reset it and re you know as it goes kind of goes back to factory factory reset mode um so do do have that extra authenticator that's you know maybe in your closet or some other secure place that um you can use if if that happens so any in any case this throttling is very important if you don't do this there's really nothing to prevent an attacker from that gets a hold of your multi-factor

authenticator nothing that prevents them from going in and just trying all 10 000 possible pins if necessary in order to uh in order to try and uh get into your accounts

so kind of my overall message is that activation secrets have a lot of different characteristics they have a different threat model they have different structure you might say well gee if i have a 16 character password shouldn't i also have a 16 character activation secret hopefully i've expressed to you why that isn't necessarily the case uh in fact most i i don't think i've seen any multi-factor authenticators yet that will accept all 16 characters and we have a visitor hello i'm damon i'm on the program committee and so when you apply we have this tradition you can make an outrageous speaker request okay i believe your outrageous speaker request is i just don't think i'm creative enough to make an

outrageous speaker request [Laughter] so allow me to please present to you this book from john cleese on creativity the shortened cheerful guide for the dedication from all of us here at these sites thank you for everything you do for our community and for being part of this event thank you very much that's very nice oh this this looks fun and i i and i love john cleese's stuff so i will i will treasure this book thank you very much that's this is great this looks like a good book okay i won't read it right now so um you know the capabilities of uh let's see i'm activation secrets ought to be considered a little bit in a

different category and i'm hoping that in the next version of 863 we'll be recognizing that in a better way and you know authenticator capabilities are uh you know vary from authenticator to authenticator so you know look at look at some of these things like what's what's the the number of retries that you're that you're a lot the number of attempts you're able to make and and size of uh activation secrets and all of that sort of thing and then a couple of references here this first one here on the security smartphone unlock pins is just really um kind of the bible on this subject in terms of how people choose unlock pins they've gone sort of done some reverse

engineering of of iphones to see which pins iphones don't necessarily like as much and a lot of research and and i've had some offline conversations with this team as well because they've done a lot of research on sort of the trade-offs between a number of attempts that should be allowed and size of pins and block size block lists and all of that sort of thing and that was the kind of the basis for some of the comments that i made earlier and then the second one is the uh the the website that tells you about the most common iphone passcodes and tells you a little bit about how he collected that data and that's all i have any questions

any questions for jim

um a fair amount of uh smartphone authenticators allow the user to actually activate with biometrics instead of a pin is there any advice on that any well yeah that kind of goes into the into the broader category of activation um uh factors uh and uh yeah i mean the biometric methods are great i mean the uh i think that the current uh uh false accept rate which is the the metric for the security of those of current false acceptor rate is on the order of between one and a thousand one and ten thousand i think the face id is expected one in ten thousand the difficulty that i have and why i always need to have

an activation secret as well is because if i want to unlock my phone and i've just been doing the dishes or i've unlocked my phone and my hands are dry because they're dry and dirty because i've been working in the garden it doesn't my fingerprint reader doesn't work if i'm wearing my mask my face id doesn't work so um you know biometrics are great as a as a as another means to do it but i think that activation secrets are still going to be an important thing

thanks um you said that you're consulting for for this even though you're going to work for them and you mentioned that some of the items here might be in in the final draft so just curious what are the recommendations you're providing to nest for the 800 sp 863 that currently isn't in there uh well i mean the current the current recommendation treats activation secrets with in the same category as other sorts of memorized secrets there is a little bit of a special case there for numeric act numeric memorized secrets that are randomly generated by the verifier but it turns out nobody actually does that and so really the new the new treatment of activation secrets is in

order to come up with some uh guidelines that are uh really intended to be more generally applicable and and actually deal with some of the differences that were that i've talked about in this talk that answer your question otherwise talk to jim jim afterwards we have to move on thank you again jim

and just stay put because now we are heading straight for christian brown from google to talk about passkeys and after that we're also doing the uh panel on all things fido where we have both fido alliance we have microsoft and we have google up here if you have any questions related to that you can ask that while we go ahead with the pound discussion you can tweet at me if you want on twitter and i will ask the question anonymously on your behalf but prepare your questions for that and while chrysalis getting ready i can do some of my old jokes like my ex-wife is probably the woman in the world who knows most against your password about passwords

against your own bill a pin walks into a bar and the bartender says what you're too short to be here obviously yeah um i i i have a little uh thing with christian um i was doing pastorscon in stockholm in 2018. i was incredibly happy to see that christian from google submitted the talk he wanted to come and talk about fido stuff and being the person i am i was thinking about well so christian is coming to talk about fido and uh you know i've been up and down talking about fidu before as well so i figured how to best welcome christian to scandinavia to stockholm and sweden so i created a t-shirt uh saying what do we still have in 10

years from now passwords or web of that so we have a 10 year back between the two of us lucer buys a sabir for the other one what do we still have in 10 years from now christian i'm really looking forward to hear about huskies where we are and where we are going fantastic thank you um let me see if i can make the lapel mic work i like to walk around [Music] and here we go all right here we have something perfect let's see if we can click on this one all right let's do it like this do you let me know if it slips down and then we'll we'll figure that out during the

presentation thank you for the warm welcome um i'm christian uh i'm a product manager at google and i've been working on fido and weber then related initiatives for almost a decade now um this is the here i feel like i said it every year now this really is the year and um i think what i'm going to try and do here is go through um a little bit of background on like what we've been doing you know i think that uh presentation is officially titled like you know where we are where we've been and where we're going um and then we'll lead into a q a with a panel where some of my uh other colleagues on

the fighter side will join me um if folks have any any questions and we can have a healthy discussion uh before we get into that though i just want to make sure that i have my logistics figured out i am planning to do a live demo which is always a lot of fun especially for the people in the audience when it doesn't work um so i think we're good i think we've got everything ready and when we get to that part of the presentation hopefully we should be able to to do that without too much trouble uh i'm gonna plug this into just want to make sure don't want to set up my keyboard now

and hopefully we should be good to go all right excellent cool um can folks still hear me if i'm walking around here no let me clip this on my t-shirt over here let's see if that's better is it okay folks in the back all right excellent great okay um so again i'm christian and we're going to be talking a little bit about pass keys today so let's start with why we're doing this work right what is the reason why we got involved in this in the first place um back in 2009 um google suffered a um an attack uh very similar actually to what has happened just two or three days ago with some other vendors um basically

google got finished right um there was a phishing email phishing message someone clicked on it uh gave away credentials and hey you know someone got into the system um and that same thing happened recently and it still happens and it really is because passwords are so incredibly easy to fetch right it is so trivial in tricking a user into revealing their secret data the thing that is supposed to make them unique so easy for them to reveal that to you know some other resource um and and to be quite honest it's much easier to set up a website and exploit phishing than it is to exploit you know uh i guess the inherent protection in systems today

that come as a result of malware protection right um if we think back like a number of years ago if you look at this graph right back in 2012 2013 2014 the way that you would pop someone is by getting malware on their system um no one does that nowadays right for two reasons phishing is super easy to pull off and secondly operating systems have become much better at isolation um and just in general at keeping bad and unwanted software out apple app store is one way you know very curated google play store kind of similar and even on other desktop operating systems the operating systems will become much much much better at ensuring that bad

software and unwanted software stays out so phishing is the one thing that we want to protect against uh back to the the this short history here 2009 uh you know this stuff happened and we vowed that we don't want phishing and credential phishing to ever be a problem for google enterprise users or google internal users again um and that's really where our journey the google journey started um towards the stuff that i want to talk about here today which is uh fido and and fast keys and web will then um so we wanted to find a solution to this problem so a bunch of different companies got together right this isn't an exhaustive list this is a couple of names uh of

folks that's part of this thing called the phyto alliance and i'm sure folks in this audience have probably all wrote about the photo alliance it's a bunch of us that came together and we said hey we want to solve this problem uh we have this fishing problem um we have usability problems we've got other problems we want to you know band together and we want to try and address this uh problem going forward and what we came up with is something called and in the next slide you'll see a little bit of a different explanation of this but we came up with something called web of n web authentication uh and it's w3 says w3c worldwide web

consortium specification that allows developers or web developers to interact with security hardware and security implementations on platforms and we'll talk a little bit more about what that means in a second but basically there's the worldwide web consortium uh who has the specification for a lot of this work and then there is the fight of alliance which is the organization um in which a lot of us operate together and and and kind of like came up with some of the work that ultimately led to the specification in the w3c and a different representation of how that work and how these things are related to this graphic here essentially you have fido and 502 photo 2 is kind of like this overarching

thing this umbrella you know terminology that sits at the top and then inside of 502 you have a web specification which is how a developer would interact with fido's stuff um you know if you write a website essentially you'll deal with whatever is in the w3c webothen specification that's kind of like on the right-hand side here and then if you are a vendor that makes physical security keys right that's stuff that we'll talk about in a second that's part of what we've done in fido physical security keys was the first instantiation of uh fido hardware and of the solution this phishing resistance solution which we'll talk about but essentially if you're an authenticator vendor um then you deal with the

standard that sits under the fido alliance which is called ctap client to authenticator protocol for most of us in this room if you're not an authenticator vendor if you're not interested in making physical keys you can ignore most of the part on on the left there but what is way more interesting is recently we've decided that not only will we under the fido umbrella be supporting physical external security keys things that a user has to buy and carry and that they can use to authenticate but we will also support built-in authenticators so stuff that's already inside of the platform that can make the platform act and get all of the benefits of a fido authenticator

these are things like fingerprint sensors the screen unlock of the device face recognition so there's a lot of this technology that has been in devices ever since the advent of the iphone 5s i guess which is the first real consumer device with a fingerprint on it i mean before that we had some desktop and laptop systems but it never really took off this is the first time that became mainstream and when we saw that we were like hey it would be cool to allow developers to get access to that hardware with all of the features and all of the benefits that fido authentication provides so we'll talk about that so if we look at a quick timeline here

right we started off with the physical removable security key back in 2009 when google had our issues when we said hey we never want to get finished again we designed a protocol which is basically what ended up becoming u2f together with some other folks that work with us in fido but u2f universal second factor was the first instantiation of fido uh and that is where you use a physical device most of the time a usb device that has some key material on it when you want to sign into a system you present this key material and then the way that the protocol is constructed the the authentication sequencing is is phishing resistant so it means even if you're

tricked into going to a website that's not really the real google or the real microsoft or the real facebook the security key will not reveal its secret and that was kind of like one of the big benefits of of moving into this fighter world because if you look at other forms of multi-factor authentication um pretty much none of them except for smart cards have the inherent phishing protection that fighter devices have so fighter devices brought back in the blue kind of side on the left it brought um phishing resistant multi-factor authentication to the masses into the web but we still needed users to go and buy physical security keys and you know we knew that that had a a very limited

kind of like usable segment there um and then we went on and we said well it's really cool now that the iphone 5 has fingerprint sensors and android's fingerprint sensors and nowadays on laptops and other devices uh we have like windows hello which is a mechanism for doing biometrics on the device what if we could tie that same technology into fido and we can essentially expand from only users who buy physical keys to a world where anyone that has a hardware that has these capabilities can also benefit from phishing resistance fido as kind of like a an additional factor we'll talk about that in a second so that's kind of like stuff that we've done back in 2017 2018 um lately we've

added support for other uh you know purpose build flows for example there are certain types of financial services regulation that came out in europe uh in the us we see a lot of a specific type of credit card transaction security that's needed stuff called 3d secure so we were working together with these other uh bodies essentially in saying what can we do to take fido support that we have and bring it to more and more use cases so not traditional authentication but other types of specialized authentication uh flows as well for example payment flows um and and you know that was all great but we still had a problem we still have this adoption problem where fido was

kind of like for a minority fighter was for users with physical security keys fido was for users or developers who really added fido as an additional option over and above passwords but it wasn't really closer to getting us rid of passwords completely it was still one more option you could use if you think back to the biometric authentication you have in your phone today right if you have a banking app on your phone most of the time you open the banking app uh you know you sign in with your username and your password and then you up step into biometric authentication the next time you come back now you can use your fingerprint but the moment you buy a new

device you're back to password authentication so you're never getting rid of passwords you're really adding biometrics and adding capabilities in order to make authentication easier and more user-friendly but you're not getting rid of the security downsides of having a password attached to that particular account and that's really where pass keys came in which isn't really a different specification or a different technology it is taking what we have in fido when we're both in and applying it in a certain way where we can actually finally start hopefully getting rid of passwords completely and me winning that bet with per and getting a bunch of beer so let's talk a little bit about that in a second here

security keys the fob this is the use case we had first right users go sign in somewhere you type your username you type your password you pull out your security key you plug it into the drive and hey you're magically authenticated not really a you know a better user experience than using passwords uh you one can argue that it's maybe better than you know having to use sms otp in terms of usability or better than having to use push because it's easy and the device is already maybe a new usb port that you just tap it but it was definitely an improvement in security but it wasn't really an improvement usability and it certainly didn't get us

closer to getting rid of the usability issues regarding passwords um platforms indicators is the thing we did next you know as we can see here we saw these things start to appear in more and more devices fingerprint sensor on laptops phones uh you know laptops there on the left-hand side in terms of the of the camera you know facial recognition um and with that we were able to build some interesting web experiences and this is a gif that should play there we go you should see this uh working here this is for example you can see we're on our website right you're on accounts.google.com and you're trying to do something where we need additional assurance that it's you in the past we

would have asked you to enter your google password here we say just touch your fingerprint on the system and we'll authenticate you not really that groundbreaking because apps were able to do this you know since the iphone 5s but finally with web authent we brought these experiences to the web so we allowed web developers to also make use of the inherent technology built into these platforms uh and we had a bunch of relying parties or developers supporting these flows paypal had some implementations ebay had some yahoo japan entity docomo and google and a bunch of others um so actually um i saw an email this morning a colleague of mine sent me a screenshot of a yahoo us

account that actually has a similar functionality here as well so now i can probably start removing the jp designator there under the yahoo side because it looks like we're still seeing more and more adoption of this type of workflow but like i said this is a usability improvement right it's not necessarily a security improvement if your finger is wet as jim said earlier you still get the fallback right you can cancel out of this flow and always opt for still typing your password there is no reason why you can't go back to that what we wanted with fido and ultimately with webothin is we wanted to move beyond the password we want to end up

with accounts that don't have passwords they might not even have user apps so the big question is how do we get from here which is where we were into that role and that's really what we'll be talking about here so i had a problem with fido adoption as i said right problem is usability right limited consumer awareness and usage of security keys um you know i can tell you about the statistics there but as you can imagine it's not like we see all google users using security keys i mean we can't even get all google users to use usb so i mean and there's there are certain types of uh initiatives and things that we have where we're trying

to push more users to take more ownership of account security but it's hard when that entails physically buying something and carrying yet another device so we have that challenge second one is uh you know challenges with patreon authenticator as a second factor um even as a first factor like i said we never got rid completely of the password we just gave you another option and it's great to have more options but that doesn't really change the security paradigm of the security model all that much um and then the last one as i said like high barrier to adoption for users who need to opt-in to usb i mean we can't even get users to opt into usb how

do we up them into using technology that entails an additional step or two or three steps and you know having to carry around physical devices and also to other stuff so these were the problems and these were really the final limits back before we started uh in in this uh engaging in this pesky uh rel um so what is baskey well pesky is a password replacement that is safer easier and faster to use passkey isn't the brand it's not supposed to be capitalized it's now it's like passwords right you just say hey i have a password i have a pass key um the idea here is that this is a word which the industry can kind of coalesce around it's not an

apple brand it's not a google brand it's not a microsoft brand it's not a fido brand it is just a pass key which is very very similar to a password and hopefully in the user's mind um we can start to create this concept of yesterday i use passwords today and tomorrow i'm going to be using aposky and and we can start to um essentially help users with the user journeys and the changes in user behavior that will be needed to support the transition capacities and that's what we'll be talking about here for the next couple of minutes so the capabilities that we get um and i stole these slides shamelessly from andrew's deck thank you andrew um so the

the capabilities that you get in a pass key world what is different from wimbledon yesterday and fido to pass keys today well the first one is remember that problem that i said you know it's great if you have an app and you type in your username and your password and it up steps you into biometrics but the problem is tomorrow when you buy a new device you're right back to typing your password again well what if we can remove that restriction what if we can give you a fido key the moment that you register your biometric for a certain app let's say i open my bank of america take an example i open my bank of america app on my phone i

open the bank of america website on my phone or my laptop i sign in with my credentials username password and they give me a photo key pair um i didn't go into that details i'm assuming that folks here kind of like have a basic understanding of what's going on beneath you know the layers of fido but essentially when you get a fido when you do a fido registration when you register your security key or whether you register your platform authenticator your fingerprint sensor or your facial recognition on a certain website or to an app a public private key key pair gets created the private key stays on the device and the public key goes to

the website right so that's kind of like how fido works back in the day earlier on fido private keys were protected on the device only we have a physical security key the private key is on the device it stays there when you register it on your phone or your laptop the fido private key stays on the laptop what if that restriction didn't exist what if we could take that private key that you have on your phone and we could replicate it to all your other devices that you own as well kind of almost like what a password manager does today right password manager wouldn't be super you know useful if it only ever kept your

password on one device and you couldn't get it off right password manager is useful because your passwords are available wherever you need to use it so what if we take that property when we apply it to fido keys so when you register a fido key and you make a new fido key for a service on your phone we're able to take that phytokey and replicate it and bring it to other devices that you own as well now of course if you're a student here you'll immediately say well how do we know you own those other devices what if it's an attacker and that's the type of thing that we want to get to later in our in

our panel session but essentially if we're able to know that you own two or three other devices let's just proactively go and put your fido keys on there as well what that means and what that looks like is when you move and you buy a new device you go buy a new phone you never have to fall back to typing a password ever again you'll just continue to use your biometric your face your fingerprint your screen unlocked and that gets you access into that particular service without ever having to fall back to passwords ever again it's basically make fido as ubiquitous and available as passwords there are some caveats to this but we can get into that uh in in the in

the later session the second thing is um well what happens if you're on a device and you just don't have your final credentials there and this is the typical password problem right the password manager problem i think i heard earlier folks saying like uh you know i have this issue where i want to sign in on my television or i want to sign in on a friend's computer i have to retype my passwords for my password manager into the keyboard to are special characters a huge pain in the ass but how do we solve that problem well the way that photo solved it is we developed a local protocol that allows two devices to talk to one another over

local proximity using a specialized bluetooth protocol so essentially the use cases i want to sign in on my television i'm going to sign in on my friend's laptop i go to their laptop i click on the website i want to sign into i bring my phone close enough together which has my final pass keys close enough together to their machine i tap the account i want to use and magically i'm signed in no retyping of credentials totally fishing resistant because everything that is fighter related still stays intact and my credential actually never goes to my friend's machine only the signature that allows a once you sign-in actually goes to their machine over this local proximity protocol

because it's not via the cloud because it's local proximity based we get all of the inherent phishing protection that you get out of fido in this particular protocol as well and these two things is basically the only difference between what we had an old fido and what we have a new pass keys it's fighter credentials with the ability to synchronize and the ability to be exercised remotely using these um proximity protocols that we've now defined and that most popular operating systems have stated that they will adopt so we have support for this whether you're using android to a mac device or whether using an iphone to a windows device these protocols are implemented in a standardized way so

that it's not a vendor lock-in it works basically essential well it works doesn't matter what platform you own as long as it's a fairly modern platform and again we can talk about the exact version in there um these types of experiences is what we enable um so you know here's an experience on windows for example user goes want to sign in somewhere um sends a prompt to the phone again it's not a prompt by the cloud it's a prompt to the system on android here it's also not to an app it's to the android system and it allows you to then unlock in this case using your face here um pick the account you want to use and then over the local

proximity protocol we then let the device know that yep the user has authorized this login they can go ahead and they can continue uh you know down this down this track um cross device cross ecosystem you know one mobile device can boost up another uh ecosystem or another device which is essentially um how we get away from the issue of having the user you know re-type long strings and if you retype a long string you can make an error and type it into a phishing website and whatever none of that is is is in effect here because everything is essentially automated between these two systems and there's a handshake so access a new app use your mobile device to sign in and

then the thinking is if you use your mobile device to sign in on a new system if that's your system if that's not your friend you can create a brand new pass key on that system that signs you into the account so tomorrow if you come back on your windows machine you don't have to grab your phone again because that would be painful right you can now just on your windows machine show your face touch your fingerprint whatever you need to do and then get you back into that same service in an easier way so no need to fall back um you know to using your phone every single time that you want to log on on devices that you own and

devices that you trust so with this let's look at a quick demo if i can make this work um this is always a little bit tricky but i'm going to try my best let's open this guy up here and essentially what i want to do is i want to show the um the experience that i just you know talk you guys through i want to show that experience in real time on my android device so let's see if we're able to make this work if everything works you should see my phone screen there in a second cool okay so that's always good if that part works so that is just my android phone that i

have here right so i'm going to take you through a typical experience of a user here using passkeys and essentially it goes like this a user goes opens their browser and they hit you know their favorite banking website in this case i have this fictitious bank called tribank uh i've never dealt with passkeys in my life ever before this is my first time doing that so what will happen is the system says hey do you want to sign in ignore the sign in with a pass key button at the top for the moment let's just talk about the or space at the bottom right so this is a user never dealt with pass keys ever before first time ever they're

going to go in they're going to type oh sorry let's refresh this make sure everything works yep user goes types username types password and hit the sign in button right now what will happen in the background is the system will detect the tri bank uh server side system will detect i'm on a device that supports baskets that's a silent detection mechanism we've added um and it'll offer the user the option to create what's called the passkey so there's an explicit pesky creation moment that takes place i'm going to say yep create me a passkey system ui kicks in and says hey do you want to pass me i say yeah sure i want one here's a little bit of metadata

about the passkey pass keys contains an icon it contains a you know a display name it contains a username a bunch of information and it also tells me they're down at the bottom that this passkey will be synchronized to my google account in the future so if i sign into android on any other device i will actually be getting those pass keys on that device as well and then lastly i need to do a user gesture here touch my fingerprint and that creates me a passing so now that i have a pass key on my phone next time i come back to tribank either on this phone or on any other phone that signs into that same

google account all i have to do is either now know that i have to hit the sign in with a passkey button but we know most users won't so we've decided to also integrate past these with the autofill system on the particular device that we're on so if the user were to click into the account name field here which is what i'm going to do rather than allowing me to type it'll come up and say hey you've got to pass you do you want to use that and i'm going to go yeah sure i'm going to use my pass key click it touch my fingerprint and at this point i should instantaneously be signed into the

account now i mean up until this point that still makes a lot of sense um one other cool thing that i didn't say is once i made a pass key on the web the same task is also usable in an app so if i download the tribank app from the google play store i can now open the tribank app i can hit sign in with the pass key here i can click on that exact same password i created over on the web and because the app on the website is linked using asset linking i can go and just touch my fingerprint and amazingly be signed into my app as well so whether i create the

pass key on the web or the app doesn't really matter they're usable in both places and then as a last um got a little uh add on to the demo is let's quickly show how the experience would work for a user that's on a friend's machine um so i'm gonna sign into tribank on my buddy's machine over here and what i'm gonna do is i'm going to go to the tri bank website so make sure it's online there we go and i'm not going to type in my username and password here i'm simply going to say signing with the pass key the system will detect that i don't have any pass keys yet for tribal so it's

going to tell me to scan this qr code now the qr code is necessary just to let these two devices know that they want to be talking to one another if you have another five laptops and two phones in the audience here we don't want my phone to accidentally talk to your laptop so it's kind of like a disambiguation thing where i want to make sure this laptop and this phone talk to one another over bluetooth i'm gonna say use pass key there is no explicit pairing everything is handled by the protocol so i say yep i allow these devices to talk to one another the pass key i created earlier in my demo is now available on my phone i pick

it touch my fingerprint and at that point in time i should be magically signed in on my laptop here on the left and as i said earlier because i don't have a pass key on my laptop yet the website will offer me to create a local one so next time i come back to tri-bank i don't have to grab my phone so i'm going to say yeah sure make me another pass key on my laptop i can use my fingerprint because this laptop is one of those that's equipped with a fingerprint sensor so i'm gonna touch my fingerprint and now i have yet another pass key for this website on my laptop so if i ever come back to this

website on my laptop here i can just click sign in with a pass key touch my fingerprint no phone needed pick the credential that i want to use and instantly i will be signed into the account [Music] i promise i'm almost done we'll go quick recap and then i will make time for the uh for the panel here uh let's just look at a quick recap here so what did we see here well the first one is user info is stored on the authenticator on the registration right remember i had this promo where the website said hey do you want a pass key at that point in time i create the credential on the device it's called the discoverable

credential which means metadata about the credential is associated with it on the device which means i don't need to type usernames anymore i don't need to type passwords all that information is now associated and stored on the on the particular authenticator on the platform so next time i open that website up the system can prompt me for all of my stored credentials i simply pick the one i want to use click on the one do my fingerprint scan and then basically i'm signed it um as i said the synchronization happens if i own more than one device and they're all signed into the same um into the same account we get synchronization now here's the

little caveat synchronization doesn't happen like in password managers between chrome on windows to chrome on android to chrome on mac no no for fido we want low level platform support so pass keys only sync in between ecosystems owned by the same vendor so on android my pass keys made on android only sync to other android devices it doesn't sync anywhere else passkey is made on mac os sync to ipad os and they sync to ios all part of the apple ecosystem um past keys from android does not sync to ios if i want to sign in on my mac device using an android phone i need to use the cross device bluetooth flow that we saw the qr

code scan flow that's how i get my pass keys or the sign-in mechanism between devices of different ecosystems and the reason why we went for that is we wanted the security properties of hardware bound and stored keys that stored directly inside of the system we did not want to have the the same issues where the private keys is perhaps just stored in a file on disk so malware can get to it we wanted the assurance of having these keys protected by the hardware which means pass keys also inherently get away from other forms of multi-factor if i have a pass key i don't need sms otp i don't need google authenticator i don't need push authentication pass keys solve

two authentication factors in one single step the possession of the key and the way to unlock it is enough to get access to a pass key which should then account for both authentication factors in one fell swoop that's the other reason we wanted to go down the the pass key route here with the protection uh last slide i promise is and then of course the integration with autofor we don't think it's going to be successful if we have to train users to go and find a button like this on a page so we actually don't think that a button like this should even be on a page for the next five years we should have integration with

pass keys directly in the autofill system so that together with your passwords we just show you available pass keys you click on it and you can sign in and if you don't have opacity available you can always go past key from a different device which allows you to pair a different phone bring it to this in proximity and then use the pass key from another device to sign in on the device that you currently own and that you're currently on um that is it i know i am one minute over um any questions i guess we can get into lots of questions afterwards thank you christian all right i i do know i have tons of questions but

that's why we are doing the pal uh now so andrew and tim can also come up and join me on stage um and well short round of applause for christian first of course

now i'm not going to say i i i know christian but we have we have met a couple of times and we have talked online as well so just still have a certain idea on on your how much of pain in the rsi can be asking questions i had dinner with him yesterday and also warned him that i like to do the difficult questions and andrew just walked straight into the trap on this one [Laughter] so back in norway at one of the universities there there's a biometrics lab that are rated as one of the best in the world and every time they are want to do a panel discussion they contact me because they say that i'm

really incredibly good at being the devil's advocate so i wanted to start out by saying that on my phone right now i'm actually looking at a couple of slides from someone named simon youssef son at a company called ubico and these slides are actually from passwords con in june 2011. oh wow in bergen norway where he was presenting the yubikey and very shortly after his talk i purchased my first yubikey and this is then 11 years old so my first question is for andrew what's taking you so long thank you um how much time do we have before the next session well after this session there's one hour break okay so great question um you know i'd note that so fido alliance

for those of you don't know we're an industry body over 250 companies take part uh we're fortunate enough to have all the platforms involved uh yubico security key vendors service providers groups like that we're coming into our 10th year of existence so this is around 11 years ago that yubago had the idea of the yuba key um i actually think we've made remarkable progress with the fido's standards well i mean christian talk about web off then web authent is supported by dozens of leading brands hundreds of millions of consumers can log in re-authenticate without a password thanks to that what we're hitting though is a point of well that's good but to really take on passwords and to have the

same ubiquity as passwords we need to take on some of the same traits which is easy access ubiquitous access and ease of use and i could say like today every conversation i have about fido begins and ends with feasibility and so past past keys first and foremost are more usable means of doing passwords authentication which allows us to hit our core goal of reducing industry reliance on passwords um so i think we've made good progress in 10 years actually the fact that we've seen such adoption every meaningful company is taking part in fido alliance there's no counter standard to fido because everyone understands that this is you know fido is basically the ssl of user

authentication um it's not it's not critical and i think we to have the same approach and we'll have the same success as far as being embedded in every system service and platform out there um now in regards to yubico and yuba key as christian was talking about before that's another form factor for doing you know fido authentication in fact i would say you know that will remain the gold standard from a security standpoint for fighter authentication there are certain use cases where a key you know will always be used that being said what is so exciting about passkey is a proposition of taking passwords out of play entirely for hundreds of millions if not billions of consumers

and if someone can't get excited about that i don't know you know what they're waiting for so to answer your question i think we're making good progress taski stands to take us to the next level after this thank you um okay um tim fido u2f web authen can you explain this to my mom in like a sentence what is this stuff because my mom is really seriously not interested yeah i mean i think well you know what christian demoed um the way we explain it to folks is that you're using your screen lock on your device to sign in everywhere right that's ultimately the way we abstract it away because the same tech on the device is being used and all

of the all the api service all that's completely abstract away from the user and that's why we believe having a term password pass key like password is so critical because all we need people to do is associate that as they can sign in so the way we kind of thought about this was we're about 10 years into tap to pay right i think google wallet came out in 2012 apple pay was after right like most users know what that tap to pay icon means now whether it's a physical card tap or a phone we need that on the web we need that for apps so we need an icon and a name that users just know oh all i have

to do is you know i'm going to get prompted to to unlock my phone more or less to do this or or my device i want to thank you that i i think up until a year ago we we weren't quite ready with this experience yet because we were always thinking a user will have to know do i have a password do i have a pass key i have to make that mental decision and that was actually a big flaw right in the in the in the development of this it's like users don't know today if you have a security key you need to know you have a security key because you need to have it present

right the thinking with pass keys is everything is abstracted away like like with a password manager today you just go where you want to go you click into the field and whatever is available magically pops up and gets presented and until we really had that experience figured out i think this wasn't really ready for prime time but because we now have it we're hoping that it is yeah um okay uh christian um throughout the years i've seen all kinds of authentication schemes come up and fall down like that flies in in seconds i've got to be honest i do have a certain level of faith in fighter web offend but again i'm here for being the

devil's advocate so i've seen facebook uh try to push two vital on location a couple of years ago and one of the things i got fascinated when facebook was really pushing to have authentication is that after enabling 2500 vacation you would get a pop-up for like every time you logged in for a period of at least two weeks where they said you have unable to find a vacation would you like to turn it off and i was like wait what i do know people on facebook sorry i asked about this and they said well it's pretty simple pair when you have 1.5 billion users in the world there are gonna be some people that are clueless absolutely clueless to

what they just did so they they had to do that just to make sure that people at some level knew what they were doing apple have also tried to push the adoption of queue authentication for your apple account google is pushing the advanced protection program will google when will you try to push the use of fido web authent onto users like to make it mandatory for let's say just a couple of million users just to see what happens that's a great question um i was looking for the meme but then i decided no i have too many tabs open on my browser i don't want to go there i was looking for that meme with a guy riding

the bike and then putting the stick into the wheel right i feel like that is what facebook was doing when they they tried to get like two factor authentication adopted and then giving users these options to keep turning things off oh honestly the question is kind of twofold the first is google is on a journey to enable two-factor authentication managery for a billion users doesn't matter if you want it or not you're gonna get it and i mean apple is already to a certain extent done some of that stuff on the icloud side right today it's very very hard if you have an icloud account it's hard to turn off two factors together in that icloud account

right there was never an explicit moment where i turned 2fa on my icloud account but it's been there for as long as i can remember and that's a conscious choice in the conscious decision they made we're doing the same thing i think we just publicized that we've enabled it for i think 150 million users if you go look at the google blogs uh google two-factor like you'll see some uh stuff that we've said about like successfully testing this out like we we took 150 million users we've enabled two factors indication for them we looked at their account health over like a six month period and see what happened can they still log in can't they log in okay i

will say i'll cover this with that was like a pretty good group of users we pick right they have recovery options there's other things that's good about their accounts that made us want to go and pick them but it worked out and we're definitely on a journey to get two-factor authentication in general to more users now let's talk about web authent the reason why my counterparts in google on the account side is so excited about web authentics you can sell level 10 as a usability benefit right you can't it's hard to sell two-factor as a usability benefit right it really is purely a security benefit and users don't care they're like you should keep me safe they're

really angry at you when you let someone else get into their account but for the most part they don't want to deal with it right they're more angry if you lock them out i mean that's obviously the worst right so lockout is bad getting someone else to their account bad and then of course for the rest of it they don't want to deal with it the way that we're thinking about positioning web of n is exactly what we've seen in that in that banking demo you'll sign into your google account one day and you'll just get a message that says hey you happen to be on a device with a biometric sensor like you can have a fingerprint

or a face or whatever do you want to use that to make your signing process easier in the future and then the user says yes now they have a pass key now that is that is the experience that we're thinking about for google accounts that is the experience that actually um many apps have been have been you know pushing users towards for the last almost decade right if you log into your chase or bank of america or whoever like into your banking app today that's the way that the app up sells you hey do you want to use biometrics in the future i mean i'm not always a fan of the exact user experience and how slick it

is but what we want to do is make it extremely easy for users and have the value proposition center around usability and ease of use and not around security of course it's massive for security but that's not what users i think in general really care that much about sort of tempting to to ask tim the same question i i can't really remember seeing microsoft doing a very significant a very visible push for 200 to fight on vacation but uh are you planning to sort of push to fight away both and on to us and is that going to be voluntary or by chef horse i'll take one little brag we were the first of the three to allow you

to remove your password completely uh that was about a year ago and that's been wildly successful yeah we were certainly thinking about the day when we would mandate to sv um and that would be via most likely be a pass key or security keys um so it's certainly top of mind yeah this is a as christian mentioned right this is a journey this these releases that you're going to see very shortly this is not the end right we're going to constantly improve and you know it's it's going to be you know it's going to be realistically about 12 to 18 months before you know we can really start to push this on these big accounts yeah

andrew i mean what are you doing from from fighter line centrally to sort of like i don't know can can you ask all the members of fighter lines to push this stuff at the same time so we get the maximum attention to it all yeah i'm gonna do that yeah so a couple points here so first of all i think the questions are fascinating because to me they're all about usability the question to tim the question about your mom or whoever it might be my mom is incredibly difficult on this your mom but like it's always your mom or whatever it is but you know it's that that proverbial person but it's all about usability and to that person it's

like you know apple has done a great service of the industry by introducing touch id and apple basically consumerized user authentication with touch id and people are so accustomed now to using biometrics that's the expectation of user experience uh the facebook experiment with trying to mandate uh two-factor authentication and sticking the the stick and the smoke that's usability challenge and these are not technical challenges so again as i said before pretty much every conversation i have about fido these days begins and ends with usability which was not the case 12 months ago it's about security um and all the benefits usability actually have obviously security implications as well they have bottom line benefits and top line

benefits too and so to your question of can we just make people do this well no we can't but the fact of the matter is you know on may 5th of this year we had a press announcement with apple google microsoft and fido alliance where all three platforms announced their commitment to support this vision of passkeys and you know we can't do much better than that right and all three platforms are going to support this starting with ios and mac os this year following with android and windows over the next 12 to 18 months so i think that as that endpoint support becomes more and more prevalent we will see the service providers you know go towards pass keys and

there's a lot of discussions right now about how and when and why they need to do it to be clear as tim just pointed out like this is a technology in development right so the technology's mature right it will be it's already out in ios and beta form right now but like any new technology it does need to iterate it will iterate based on market feedback based on market forces and we're taking you know that feedback's happening organically and also through the alliance itself so that pass key over time will become more and more you know better tuned and also fit all market demands one other point that we're doing inside of fido alliance you know we're not just

hearing about usability we're actually embracing it as a standards organization to everything we do so we have a ux committee we have a ux system coming into place looking at user experience at every step of the way across our specifications and across our outputs so pass key will be front and center but we're also looking at things like ux for security keys and other deployments of photo authentication how can we again the usability is a very good point i do have a t-shirt today a friend in israel avid called a security digger section on twitter he has a rule of its rule he says security at the expense of usability comes at the expense of

security it's a really good one um is fido you know is it easy for normal people just to get started or do we actually have to do any kind of training to get them stuck with this i mean again back to my mom can she figure this stuff out without any kind of training at all because training is a cost so let me talk about the user perspective then turn over to tim and christian talk about the you know the developers perspective so web month in again is a remarkable um api and it's built in every browser and anyone could basically deploy it today for you know use of platform authenticators that being said um you

know we heard from service providers like hey this is really exciting but like there's some wonky stuff happening with like os prompts and browser prompts and like we don't know if this is being how do we deploy this as we actually did our first ux study last year we hired an external ux firm we had a ux beta committee um led by you know not your typical standards wonks but by ux and design leads from companies like visa and apple and intuit and jpmorgan chase who helped scope a study the three-part study both um moderated unmoderated testing of people actually trying to enroll and leverage a platform authenticator to log in to a site supporting web auth in

and we learned so much from that and it's fascinating watching users do things like try to use touch id on a macbook to log into if it ditches bank site and watching like this focus group someone being like wait a second like why does it want my fingerprint and why is this bank with my fingerprint and why do they want this and so what we learned is that there's a lot of education that needs to happen about like hey first of all your fingerprints not leaving but also all the user flows they're in and most of the design stuff that we figured out was not about iconography and colors and stuff like that it's about terminology

and getting information across effectively and letting people know what's happening and like selectively disclosing information as they go along to help walk them through the entire user journey from being primed to enroll for a web then for your account on through to login and customer support and stuff like that so there's a lot of science behind this and we're trying to take that on as a body and then making these guidelines freely available to anyone to use which they are today and they are being utilized uh usability studies on this before we move on to christian just an additional follow-up on last one usability studies in the us fine i'm from norway and i will make the claim there are

social and cultural differences between well different cultures uh different countries across borders across nations everything have this been tested out in european countries as it passes out in germany which are just a tad more privacy concern than anyone else in the world i think so i just want to act that before andrew armstrong we're seeing statistically significant difference in in pass rates users being able to pass this and looking at different jurisdictions so absolutely there is definitely differences that we see in ways that we need to approach that yeah okay uh anything more to add to this you know how to do you want to talk about the developer side yeah yes well we can

go to the technical side as well it's a good point yeah i mean i mean even just high level for developers right all of everything that you saw um today was very minor tweaks to the existing 502 web then stack right we the the autofill is literally adding a new tag to a username field the cross device thing is not something you as a relying party or website have to implement that's all handled by the platform all that magic is handled at that c-tap layer that christian mentioned client to authenticator protocol and so one thing that we think is different here is that we have a very very clean specific use case now right which

when all these specifications came out right there was you know if you've ever read any spec right you know they're they're very hard to read right no matter how hard we know how hard we try to to to make them easier to read and i'm one of the people who write some of them they're just they're too big they're hard for a developer to pick up and so what's unique here is you know the goal that we have for some new developer resources is that if a developer that has a site that the only reason they added sms otp or email magic link was because they're you know they were told you know passwords are

phishable and we can't have that they should be able to go to the site and implement pass keys without ever picking up the web authent spec right that's the goal right like we never we may not even link to it that's what we're thinking and that that would that didn't that really wasn't possible before because there's just when you when you start looking at a spec like that there's so many different use cases it's addressing and we really have a very clean very boxed in use case here that applies to nearly everyone and the other dimension to it is we didn't have any good libraries at the time right there were some like reference implementations but

again they were served either not enough use cases or too many use cases there's a one one specific library called simple web authent that is already ready for all this pesky stuff we found a bug in it last week it was fixed in two days right we have amazing libraries that no one has to go write the stuff themselves anymore and we think that that's a that's a big change from the first go around with trying to get folks to implement this and when why do i then have developers telling me that implementing this stuff is difficult no i and i think it was and i think what we're hoping is because we have kind of

a big a big package now that can be whether it's the sdk whether it's the docs everything should be ready to go and and much easier to implement and dive into initially than it was before and that's from microsoft's perspective it's easy yeah these resources are actually a collaboration between the fido and the three companies so okay sure that's certainly my perspective but i i think i think the dots aren't being connected quite yet and that is definitely i mean i'm i'm talking to internal business development relationship folks on google this week finally where we're saying all right we can now take a breather most of the technology pieces are now there and we're on our journey and by the way

apple mentioned that by the end of the year they want to have their releases out we're on the same time frame right so um on the android side by the end of this year we're sincerely hoping that we have a release out there that is not only ready for testing but is actually ready for developing and deploying against so so uh many of the things that i've that i've shown i mean all of the stuff that i showed was a real live running code right nothing there was mocked up it was real code um it was you know behind some flags and experiments but but but the pitch is these things should be ready by the end of the year

um there there should not be a reason why developers you know can't get access to that and then on the other side get access to the resources but like i said about the dots i don't think developers know that you can go and look at this great new library over here and you should be looking at this docs error here people google web of them they get to the spec and they're like what the hell is this and i think that that really is something that we need to address so back to my business folks it's like we want to try and make it easy like if we can get relationships started with the developers and i mean that includes the

top 100 apps but it includes also all of the long tail like how does someone pick this stuff up the last thing i'll add is um whereas we need to make sure there's messages for developers or messaging for developers i think we've already lost if we need to pitch this to end users right if we need to go pitch the value proposition like today with security keys you need to take an action you need to buy one and then you need to go and navigate on a website and look for multi-factor options and look for security keys if this is the way that the webinar is going to be deployed it'll be a huge failure in my opinion

right web of n should be deployed the way that biometric authentication works today which is as a matter of course when you're just interacting with the product there should be an upsell it should be easy to understand in plain language one to two sentences at most and it should start working no one should go digging through settings to enable an account for web authentic because that already means you need this cognitive kind of understanding of how things interact that is not the way that we're thinking right and one example of this there's a there's a very large retailer in the us which we're super excited they rolled out web authentic but guess what their login page says signed in with web

authent like that's what the button says yeah like who what who knows what that means right like as a user that's right they were first right no and that's what i mean we were super happy they implemented it but that that highlighted a market problem which we was the reason we needed a generic term like pascal but you said that you know people will just google for web authent and then they find the standard and they will say you know what the hell is this exactly hi well you're the owners of the search engine so i assume something could be done we don't have control over the search engine results remember but yes yeah the search engine is just living

his own life so yeah but what one side effect which i think is good like inside phyto alliance like the like within what three weeks after we started using the term passkey you we didn't hear web off then again everyone was saying passkey so that's a nice thing is that we get hopefully people are actually finding the pesky resources not web yeah i mean we actually invested in uh creating kind of a consumer brand option for fido so we had sign in with phyto buttons which is i still think better than assignment web authent or whatever so the market but the market didn't accept it which is fine you know and we have a mark with that but we put it out there's

a straw man the market didn't accept it and that's fine you know but we understand there needs to be a name for something right and so we we do think that pasqui as a noun will be that name yeah but but that's what i want to i want to i mean the reason why we're here is like i want to also put it out to the room here the folks here are the like this is our ambassadors like hopefully like help us in getting the word out like resources and developer efforts and libraries like i mean that is really what we need we can put forth like our perspective and and you know collectively maybe our three

organizations but um we will really only have success if this is like i was like a grassroot efforts between everyone involved and the the experts in this area kind of like using the technology making it their own and releasing their own artifacts like that is how we get success here i think anyone in the audience would like to ask questions well but that i didn't have to ask that question any developers that are thinking about implementing web or then but they would like to ask a couple of questions on you know how do i do this or if you find it difficult raise your hand yep okay yeah i can't hear you hi i'm a developer i read a little bit

about fido and the web as a lot i'm gonna go and give it a try on a demo and i kind of drowned the commentation it was like a month and a half ago i was like oh my god i'm not going anywhere here so i i think you guys doing a great job but maybe make it easier for the developers that that would be great yeah but uh and also i'm very happy that you guys came here but i'm missing one uh big actor it would be nice if apple was here too to get some bit though you can check twitter and like like it's not anything but like we're still in a position where it's hard for

folks to travel and things like that but we're still an epidemic yeah but uh when you say we want people to collaborate maybe we should be giving people like the idea of community like the final community so people feel like they can so that's actually so the the actually the the the developer resources that i'm talking about which will end up being passkeys.dev will be the website once it's live that's actually being driven by a community group in the w3c called the authen community doctrine group which maybe we'll need to rename the pesky adapter but that is actually anyone you know anyone can join we meet every two weeks and actually it's myself and matt miller

from cisco who is actually we're actually taking the output of that group feedback resources and building out this developer resource center so please i can i can uh yeah if you google web authentication group it'll come right out that's not the thing web off n is a bad word yeah no i know and that's what i'm saying we probably need to rename it yeah yeah that's an artifact of the past i guess but that is but we are we do have a i would say a pretty good sense of community in that group there's also there's also a uh where's this thing it's also a fido dev uh mail list if you're if you're on the issues so it

it's not a super vibrant group but there is a fido dev google group that you can mail to if you run the issues as well next hello i just had one question to make sure i'm understanding the security model around the pass keys right so the web authent u2f more specifically i guess is a very decentralized security model right the private key doesn't leave the security token concept right this is now a switch over to the credentials are essentially being managed by the vendor right so there is a shift there i think mentally that we need to make sure we're okay with or we're thinking about the implications of that is that an accurate way to capture it

yeah i don't know i mean let me give you my my perspective on this right so so uh yes to a certain extent i think i think we were trying to figure out in which way what are different ways in which we can address this right um the the challenge around every single time you buy a new device we're gonna know you're gonna be up quick right and that's essentially what happens to the current model and that's also what happens to the physical authenticator when you lose that authenticator you're so dead right so now we recommend get you i mean okay that's maybe for like for for folks who's like well let's go by these i mean

that's fine but in a general consumer adoption thing we looked at what already has traction and what attraction is password managers right also not the level of attraction we really want them to have but but they have traction and it's because of synchronization we then looked at what is the best kind of like line that we can weave through here which is like don't place this as files on disk like have the os like kind of mediate the access to them there are certain additional security properties but you're right it looks if you squint at it it looks a little bit more like federation than what level and used to look it still isn't quite federation

because it's still a direct two-party relationship right it's between the the authenticator and the developer yes there is another third party like meddling here in the middle now which is doing the synchronization but if you think about it google has a thousand folks that is purely tasked with making sure that bad guys don't get into good use google accounts right you're now leveraging if you're if you're using pass keys in this way you're essentially leveraging the fact that we're already have all that protection and all that investment and making sure only the right users get access to the right google accounts you're leveraging that now it might be that you have a particular use case

where excuse me even that level isn't good enough you need to take responsibility of your own you know i i guess like uh direction here and if that's what you want to do there are certain things in the specification that allows you more granularity where you don't have to rely on synchronization i will say use that with caution because that what that will mean is when the user changes to a new device they're going to have to start over and unless you have a good story there and i and i think that's another i didn't want to get into that because that's kind of like where some of the viewpoints between like what google's doing markets

are doing and apple doing differs a little bit it's like how much of that control do we give developers and how much of that of control do we give developers in the initial release we're very worried that this might go away where the usability suffers because of a perceived security look at per shirt right i mean that's exactly that right we we shouldn't all be trying to dial this up to 11 because of some perceived risk and then in the meantime usability suffers and no one uses the technology so i i'm being a little vague here but i just want to mention yes you're taking a new like a new uh anyway i'll stop talking on this but i'll say you are you

aren't taking another uh um you know um an additional dependency but i think it's a net positive and not a net negative yeah i'd say the same thing so one other point i want to make is so it does change fido security posture fundamentally but i want to point out this was not done without a lot of deliberation and a lot of conversation internally this wasn't done flippantly or without a lot of a lot of a lot of conversation ultimately as christian said it's the greater good right so our goal fido's mission since day one has been to reduce reliance on passwords and this stands to do that taking again passwords out of play for so many

consumer use cases um that we decided that this change is is worth it and that being said also there are ways to work on the spec you can you can actually still using passkey allow for some you know device bound characteristics additionally you know for specialized use cases enterprise i.t highly regulated use cases and so on so forth phyto security keys will still be the default go to approach and that won't change and just um one other important thing right um the pass keys in your account will be intended encrypted right so that's an encrypted blob to google microsoft and apple they're entering encrypted like other intended encrypted data so yes we manage how they get down to the device but you

have to unlock them right and analyze your policies um yeah so i was i was wondering what um what are the um what have you been discussing regarding um account recovery um when it comes to this and like the issues with vendor lock-in that arise as a result of um putting the authentication in the device yeah i i i think that's a great question i'll try and briefly just answer this in case you know some of my colleagues here also want to get in but i i think um you're absolutely right this this this again hinges on the fact that like with many other user data like you you have data there is data now that's sitting

somewhere and you need to like with any other data it's your data right you need to have the ability to get that data out of the ecosystem if you ever want to move somewhere else we definitely recognize that um you know how we do that in a secure way with passwords it's kind of like a little easier because we all know passwords are like effie and you know you have other second factors but like i said if we want pass keys to be something where you don't necessarily need a second factor now suddenly that bar is high right and what do you do now apple and google have both said i mean apple has their uh white paper on

essentially how the pas key mechanism works they also have the one i called you know keychain encryption google will do the same thing right so we will also like like them said like it's going to be end-to-end encrypted um really they're very very similar to ike like keychain um first you need access to the google account now we are driving we're trying to drive a multi-factor adoption of google accounts um by default right and that's not an accident that is that is part that is part of the foundation what you really need for this to be successful right it doesn't help to say past is good a second factor but then the recovery is a

single factor thing that someone can just guess right so that needs to be solved number one the second thing that needs to be solved is or the second thing that we're doing is similar to apple um just having access to the account is not enough um you also need to have access to some other information the information that apple chose the information that google is choosing to do is you need to know how to unlock one of the devices that was previously part of your call it sync fabric like whatever that local lock screen that's actually used as a derived key for as part of the end-to-end encryption mechanism that we use um so we think

mandatory like usb which we're trying to like drive in plus that factor plus all the other additional i mean i had a slide that i didn't show here but like if you think about it over 99.9 percent of automated attacks where an attacker has your correct google password will block we won't allow them in because there are so many other things that we know about attackers and where they come from and how they look so all of that benefits are there and on top of that we then layer the 2sv we layer the the additional like screen unlock so we think we have a very a pretty strong and a pretty robust system if after that you

say no no i still need additional security for my use cases there are things in the spec that enable that but i think for most relying parties we're hoping that that where we've set the bar is essentially where we'd like to where we'd like to keep it i'll get in front of one question just briefly by also saying we're not saying this has to be keys always stored in apple or it has to be keys always stored in google that is our initial implementation but we are very much of the opinion that we need to do what we've done with password managers and we need to make an open user choice right if you want to use a

credential called our credential manager password manager a third-party one we need to allow for good pluggable architectures to make that possible but you can imagine how much more complex that decision tree now is for a relying party or a developer because google end-to-end encrypts does password manager xyz end-to-end interrupt what is their security properties when it comes to account recovery so all these things have to be taken into account um we think we have solutions but we would actually love to have a separate conversation about those kind of things with folks providing password managers and credential managers so that we can design the system in a way that makes sense for developers and for users and

even in the short term right if you if you look at i would recommend looking at some of the apple's demos right apple's done a fantastic job about merging like you can have your pass keys in icloud keychain but using lastpass for your passwords and they all come up in the same ui and you just pick which one you want to use right so there's also the convergence there in i would say what is the short term until we have a fully plugable model where you can punch your pass keys over to lastpass or whatever password you want yeah so uh questionnaire from twitter what is fido doing to continue to provide high security authentication

with the introduction of pass keys that are lower security although on security i take offense but i will i think i think we kind of hit on that right so yeah i also disagree with low on security for all the reasons that we just talked about so there's a difference thank you twitter user yes but i i think um yeah it's a different model and again i think that um you know i like to say that fido can address address a whole range of use cases right so again if you know we have a very robust certification program we actually certify authenticators at different levels uh to protect you know to verify that a physical authenticator protects against

malware attacks or brute force attacks or hardware attacks you know so if that's your use case you can use one of these certified authenticators for that i think again the base level fido security key will remain you know the default go-to for you know high security profile use cases now beyond that again i think the the security properties of passkey are not weak they're not weak at all and there's in fact i was talking this morning with the head of authentication at a major uh bank in the us i was like hey how are you guys looking to pass key what do you think about this how do you feel about the security posture his point is like andrew that's a bunch

of he's like the gap between what i'm doing now which is sms otp and what i get with passkey the the bar has risen so much from that right so maybe there's some use cases where like a high transaction or certain scenarios where i want to get added data or added bullet points in that case you know i can take capacity as just a single signal feed it into my risk engine and do other sorts of step up or other sorts of data to make sure that's a secure authentication but ultimately pasca raises a bar so high from the default means of authentication today that i don't think it's fair to say it's a weak security approach

so i i have two i have two quick questions um i think a lot of people's concern when they're talking lower security is in comparison to what the 502 does right now which i i do prefer the 502 model i recognize the failings and like well now you've got to register on every site but the quick question is one of the fundamentals of 502 originally was the key existed on the device and it would never surrender it for any reason how do you know a key hasn't been cloned off like is it possible for a key to get cloned off maybe you authenticated it through some um you know you didn't realize what the page is showing you click something and

then there's a clone out there that you're not aware of and that key is there is there any way to revoke credentials um so that's the first question i i mean i i'll let other folks also answer this i think that michael said that further but i'll just quickly mention that i mean remember um the qr code flow and all these things it's not actually your private key ever that goes over the only time that that will happen is when the user decides to sign in to a like to a new ios device to a new mac os device like in the apple ecosystem or to a new android device where where there is like

okay maybe you want you can kind of contrive this like this contrast back where like you know the user things they're giving a google credential credentials to like a phishing site and then the bad guy runs an emulator at the back that looks like a real android device and they use that to pull the credentials down i mean we have a lot of um technology and signals around are we dealing with real legitimate devices or not so i think everything there feeds into our decision on whether or not we want to allow the credential syncing to come down to the device um if a user does let's say let's say i mean you convinced me on your android phone to

type my credentials in there type my previous screen unlock in everything and now all my credentials are on that particular device let's say that's the attack that we're talking about right okay now my credentials are there i've got new options when i if i realize it i hope i do at some point um i can either go and i can go to you know settings and i can go and sign out that device which essentially then invalidates the pass keys like almost like a remote wipe right i can go do that or i can go to the various accounts for which i hold pass keys but but this is the difference in let me kind of take an analogy right i lose my

wallet can i call one number to just block you sure can i can i can i block my entire wallet or do i have to call all five credit card companies do i have to call up all five credit card companies that's not great you have that option with baskets you can go to the site and individually revoke the past key on that device but i would say mostly you would just go and like remove the account of the device which immediately will invalid all the passwords so just to clarify on that um each each device has a unique credential that there's some mechanism that it authenticates with like it it's either a signing chain or are they all sharing it

in the android world there is some uniqueness that can be used as part of the risk detection um not all platforms support that mechanism but there is something to die back onto there is caveats there but but there is a capability right but just just to answer more specifically if i have an android phone and an android tablet signed in the same google account it is the same credential on both devices okay so if i revoke it from tribank both of those devices lose access right okay just like a security key today and then the other question was because everything on like say a yubikey now is done locally and the way the mechanism works

the low-level mechanism you can do two-factor authentication or even passwordless with um out leaking a lot of information on what sites you're doing stuff like that what type of like metadata analysis could google facebook or anyone in the phyto alliance be now um open to um because they're involved in the syncing process is it as limited as like apps there's no change right because the pass keys tied your account are intended encrypted right so there's no change in that model

so right now we're definitely encrypting all the private keys um to encrypt the metadata has issues regarding the way that we rendered it on the usability side so the mechanism that will work today metadata won't be encrypted but there is also no mining or anything of that but but technically that's something that we could add or that's something that if you choose to use a different provider in the future that they might provide for usability reasons we encrypt the private crease and not the metadata today but that's something that is for no reason other than just there's a usability constraint on that for us yeah i have a question regarding dual security keys uh i've implemented a

couple of these about 10 sites and tried to do the password right sorry yeah okay hello okay much louder or put it in my mode yeah i developed a lot of this uh uh i'm an early adopter and i tried to implement a lot of this what i felt lacking in the documentation or the implementation from before is like the um support but dual security keys so i want to have my computer that has a dpm and such and also my security key that is attached to my yeah keychain to be able to do this yeah co-op the login how are your thoughts about that so just to make sure i understand the question like like dual security keys

[Music] so being able to use or need to use both at the same time for an authentication i mean that's technically already possible it's like a relying party choice it's kind of like almost like a workflow where the relying party today can make the decision and saying hey i need my criteria as a password plus a security key or my criteria is a security key plus sms otp or my criteria is two security keys and that's something that is totally implementable uh from a workflow perspective on the relying party not something that the spec needs an easy change to teach you support uh yeah so my question kind of goes along with some of the questions that

you had earlier and uh but my scenario is more of the sense of the user trying to recover their account when their devices lost stolen or no longer accessible they're traveling for business vacation whatever else they they have to resort to a machine at the hotel whatever to log in to access their information whether it's bank whatever else what is the user's option to be able to access our account when they don't have access to their uh devices that's already been in the ecosystem super tough question probably the toughest one that anyone is asked today right and that is that is ultimately like how do i know it's the right user and it's not someone

pretending to be the user in this exact scenario right um the the easy answer today is going to be you're gonna need to prove to us that like it's you through something um you will you know if if there is no signal if it's not coming from a known ip address or like a location or something that we know about you which is you know we've got many different types of signals um you know if in the future the idea is that we remove passwords of google accounts so there will not be a password that will not be a signal that you can provide us anymore right because it's such a weak signal but then the

question is what can you provide us well maybe you can tell us about how you unlocked your previous phone but then where are you going to tell that to us to the kiosk machine you know maybe that's okay but the question is also even if you can get into that kiosk machine we can't really make your pass keys usable from there because then that means they will be leaking onto the kiosk machine so it is a very this is a very tough problem um we're kicking the count down the road a little bit where we say well if you can at least get access to like another phone like a new one or someone else's you can sign in

there like then then maybe you can sing things down but it's it's very hard because it's it's clearly a usability issue but it is also such a big security issue if we let the wrong user in or sync the credentials to a shared terminal then we don't have a perfect answer for that today but that is a problem that users are already experiencing right now but i think one potential thing right so let's assume that their phone got stolen but their laptop didn't we do have the ability to reverse that cross-device flow yeah it's just a little awkward right now turning your laptop to scan a qr code um that the protocol allows that right we just

haven't enabled that experience so you could in theory use your laptop that didn't get stolen because in your hotel room to get back into your google account by reversing the flow it's totally possible and apple's actually already supporting it for ipad and mac if you have nothing that we're stuck right they don't have access absolutely yeah hey uh yes uh thank you for your time by the way um how do you see uh onboarding working for first time log in like say you had no relationship to that tri bank no account no nothing no existing account how do you see that working and can you complete that workflow without ever ever making a password that that's the goal right i would say i

i hope in the next 12 to 18 months we'll start to see the first truly passwordless accounts with passkeys right the way we see this right you you still probably have to capture name and email address and phone number and then maybe when you hit submit it invokes web invokes the api creates a pass key and away you go you're on your way so the password field is gone you never capture it password and there are there are sites that already very small number but there are already sites that are doing that today but we hope the user experience will be much cleaner with us yeah and certain service providers are onboarding people without passwords

today based on other proprietary data they might have like a telco for example has account information about them or other network api data they can use um we're also inside of fido alliance we have we're doing some standardization work around identity proofing and verification which if we pull off which is you know very complex i think actually stands to have as much impact on the market and this whole problem as the authentication piece does that's still pretty nascent um although we do have we'll have our first uh doc-off requirements document out in the next next couple months um it's it's really good to hear that you're taking on such a skilled uh usability uh team uh to uh work on your

usability because my primary worry is and then i get divorced what happened i i managed to set up all my devices but all of a sudden i am now going to untangle myself from the complexity that i've just made am i able to do i understand this or what if i die what happens that's a good one for you yeah christian well no tim well just like fashion magic right i mean yeah i mean there's well no no it's like it's like the bathroom manager today it's i'm not saying the problem is solved but it's very similar to what you already have with basketball right yeah yeah i would agree with that we're not we're not necessarily solving

everything right these are not necessarily net new but that's part of iterating over time too right like we've already seen apple iterate on some of the digital legacy stuff that a lot that is thinking about that right so that's something we can enable over time as we start to think about what are the security implications of sharing a passkey right like all these different how do you pull that passkey back is it better you know one question we keep asking is it better for me to send you my pass key for my netflix account or just have you add a passkey to my netflix account right these are the these are the things we're starting

about all around revocability and all these models netflix things neither yeah well yeah terms of service official yeah yeah yeah yeah netflix i would think is very happy about pesky now they are yeah yeah i just i have basically the same question about shared devices it's a really common use case our customers are commonly coming to i work at slack and they they want the ability to have check out personnel use the same ipad and have a secure experience logging and logging out yeah so that that's actually so the one thing um you know christian's demo is really great showing the cross device flow where we step up and create you aposky on the local device the other flip side of that

use case which we will heavily use in windows right the example i always use as a gate agent at the airport right you never want to create local pass keys on that terminal you always want to use the cross device flow so the shared device flow the shared device scenario is one where you will always want to use that cross device and never never even you may not even want to keep the relationship between that phone and that device it's completely ephemeral and in some cases maybe even a security key it's better than a phone there like tap the security key it personalized and then when you remove it and those are great examples of you know

you know the question we got i think last night at dinner was like well this is this is a consumer feature right and the answer is it's targeted at very consumer-centric use cases but if you look at a frontline worker in a retail environment uh you know i can tell you as azure ad identity provider they're using sms sign-in this is instantly better and those are quote-unquote enterprise scenarios right so the gate agent use case same thing like what is what is better than using a fishable mechanism or this fishing resistant thing that may or may not be on their personal phone or a managed device it's still better and in a better user experience less efficient yeah we

shouldn't rule out pesky for the enterprise what's the azure date like 28 of azure clients are using mfa yeah so we can move that up you know 10 20 percent by using pass keys that's that's a great thing and christian alluded to right where we are we have added to the to the specifications options for enterprises or i hate the term enterprise work school higher security you could argue that like a twitter verified user is closer to an enterprise user than a consumer as one example so where uh you know there are there are mechanisms in the spec to to accommodate those that you'll start to see uh implementing so we are we're getting close to the

time where i have to uh end this and there will also be a one hour break before we continue but again uh this one's for you first andrew um privacy in this i mean security is one thing privacy is part of security it is also something different so have you looked into if this pass keys fido web authentic youtube whatever you want to call it you should really look into standardizing stuff yeah yeah on the privacy part of things have you looked into whether this technology will improve privacy or if it also introduces new privacy difficulties for people in any way whatsoever like my friend cecilia asking well what about when i got get divorced

is it suddenly harder to maintain good privacy as an example yeah but that's a great question and this is the type of discussion we're having inside of fido alliance today so i'm not going to give you a really square answer on that we have a security and privacy working group that's looking at these issues coming up with the best kind of a canonical approach if you will for how one should implement passkey to um to adhere to fido's privacy principles that we've had since day one yep and so i think there's certainly already implications there's there's so there's that conversation happening the other thing we do as a body actively is we engage with regulators um

across the world to understand how you know fido authentication in our various forms fits in with current and emerging privacy and regulatory policies so i mean like any new technology that we introduce in phytoalliance or elsewhere that impact user authentication we look at it closely inside the alliance and figure out you know how fido's best practices and specifications can meet you know the privacy needs so yeah one one thing that i'll and i'll speak specifically for microsoft on this um one thing that has come up uh in the past few months for us is thinking about how easy it is for users to use consumer federated sign-in right passkey has the opportunity to remove the need to do consumer federated

signing which has serious privacy implications right you're telling that identity provider everywhere you're signing in now on the enterprise side that's what people pay for right you're paying for federation you're paying to track employees because you need to enforce policy the consumer side they're doing it because it's easy so it's back to whoever asked the sign up flow if that sign up flow is as frictionless as as clicking sign in with x that i won't name i'm just kidding yeah i know just kidding we have it too technically no one uses it but um no no so if we can make that as frictionless as possible um then you could make the argument that consumer

federation with these big big identity providers could and maybe should go down significantly over time i'll say one thing for 30 seconds this is the other point right i think a lot of the a lot of the questions around like i mean there there's a whole you know slew of use cases which i won't even go into because they're all super depressing but around you know whether or not users should get access and what happens when folks break up and like there's there's this whole and i think a lot of that isn't so much the protocol it's around the implementation of the protocol and that's good and bad because that means hey the protocol is done but

that also means the relying parties need to take ownership of those experiences themselves i know we're having discussions at google around like what does it mean to give someone access to you know and rather than typing a google account password now you can just use the screen lock on the device what if that's a you know a spouse's device what if that's the shared kids tablet like how do i revoke that and i think we're trying to think through those and implement uh you know particular workflows but the the downside is that means every single relying party need to do the same thing and and i think that can be tricky and i think we're gonna

you know folks will get it wrong like i think you know we're not better like it'll but but i think we are absolutely trying to think through those use cases because we do realize that they are important and and use cases on this i i think that well i i know that cecilia myself we will most definitely be looking into the abusability aspects of this absolutely for the for the next weeks and months and years as well we are really interested in this stuff so it's interesting um we're getting very very close um i want the sales pitch for this because i'm based on me saying there is no risk analysis and there is no business case

just defined removal of passwords so try me yeah give me the sense i'm going to give you a hot tape tell me i'm wrong i'm going to give you a hot take one how much is your sms cost your sms service how much did you pay per year i could tell you i'm not going to tell you what microsoft is we're talking millions of dollars across these companies for even just an sms based sign-in right that's not the primary reason but that's a hot take that often has come up in discussions is what do these other methods actually cost that are completely unnecessary if the primary factor is phishing resistant christian sales pitch i mean

i i haven't prepared this one but i guess my talking points here would be something along the lines of if you're not removing the password and you're making the password safer you're adding something adding something comes at the like you're immediately the moment you're adding you're you're you're taking you know you're making usability worse like that is just the insecurity like the the when there's something additive security is being made worse the only way where we can make usability better or keep it on par while adding the security protection is taking something away and what is the thing we can take away it's certainly not fido it must be ergo it must be the password like that that is my argument

here to make i we need to talk more afterwards okay well uh that's it for for this discussion i'm really really incredibly happy that you come andrew christian and tim so thank you for having us thank you very much i'll be around at the pool thing tonight so if i ask questions

so use the next hour to talk to them or do something else i will continue at five o'clock thank you