XO Ruby San Diego 2025 - Passkeys in Ruby by Braulio Martinez

What is discussed, and when

1. 0:00 – 5:00: GitHub, Ralio Martinez, Syncode
2. 5:00 – 10:00: Google LLC
3. 10:00 – 15:00: GitHub, Google LLC
4. 25:00 – 30:00: Google LLC
5. 30:00 – 35:00: GitHub, Google LLC
6. 40:00 – 45:00: Google LLC

Notable quotes from "XO Ruby San Diego 2025 - Passkeys in Ruby by Braulio Martinez"

• So, my name is Ralio Martinez. I'm a software engineer. I've been doing Ruby since 2010. That's me on GitHub. Twitter and Mustin. Yeah, I learned that I was giving this talk…

  about GitHub · at 0:20

• Browser's cache for example they could try to get access to the QR code you use to set up Google authenticator or obviously whatever application you use and that's just a…

  about Google LLC · at 6:08

Who and what is mentioned in this episode?

People

• Ralio Martinez — Person · 1 mention · first at 0:20
  So, my name is Ralio Martinez. I'm a software engineer. I've been doing Ruby since 2010. That's me on GitHub. Twitter and Mustin. Yeah, I learned that I was giving this talk yesterday. So, I.

Companies & orgs

• Google LLC — Company · 8 mentions · first at 6:12
• GitHub — Company · 4 mentions · first at 0:25
• Apple Inc. — Company · 2 mentions
• FIDO Alliance — Company · 2 mentions
• Syncode — Company · 1 mention · first at 0:46
  Because else I'm going to go over big time. this is I'm I'm one of the co-ounders of Syncode. we help companies grow their teams in size and expertise. we got a special place…

Concepts & topics

• Ruby — Concept · 3 mentions
• WebAuthn — Concept · 3 mentions

Full transcript with timestamps

0:20 So, uh, my name is Ralio Martinez. I'm a software engineer. I've been doing Ruby since 2010. That's me on GitHub. uh Twitter and Mustin. Yeah, I learned that I was giving this talk yesterday. So, I got a lot of slides and I'm going to go through some of them pretty quickly because else I'm going to go over big time. Um this is I'm I'm one of the co-ounders of Syncode. Uh we help um companies grow their teams in size and expertise. uh we got a special place in our hearts for security related things and that's why I'm here today to talk to you about webin or pass keys in Ruby.

1:04 This is the agenda we're going to go through. Um why does something like web and pass exists? What it is? Who created it? Uh what are the internal workings or how how does it work uh behind the scenes? a little bit of how we have seen adoption in both uh browsers uh and actually companies adopting it since since the beginning. Um I'm going to try to encourage you to take the step and actually add uh pass keys to your applications. I'm going to tell you what our plans for the future and how we are going to keep trying to push for this and keep working on it. And then I'm going to leave you with a bunch of resources. So for anyone that wants to design any type of authentication system, there are three categories uh of the so-called authentication factors.

1:56 The first the first one it's something you know uh so the knowledge factors and that could be an example of that could be a password or a P. The second category would be possession factors which is something you have and for that you can think about a banking card or a security key. Third one it's inner factors. So something you are and that could be your fingerprint, your voice, your face or how a typing pattern uh a pattern while you type. Basically ideally to design any a good authentication system you will validate the three of them. Right?

2:36 So if we take a look at some well-known uh authentication systems we got for well it now it's got a little bit old people don't don't use cash anymore but ATMs for example use two of them one possession factor of a banking card and a fourdigit ping which is a knowledge factor WhatsApp authentication uh it has it uses the possession of of your phone number and optionally you can set a a knowledge factor with a six-digit pin So if we talk about the what most u spread out authentication factor it's a knowledge factor and it's password basically and passwords are just a share secret between you and a server as such they are prone to many types of attacks but the most common the ones are around brute force attacks they're prone to fishing Um, if a hacker accesses a database or a server, they can potentially access all users at the same time. Um, users have the tendency to repeat their passwords

3:49 across the many different systems they use and of course uh use hackers will try to repeat you reuse that password from system to system when they get compromised. At the end of the day, they're just really bad UX, especially for users. They need to rotate them. They need to follow rules that are not standardized across different systems. Um, they forget about them, etc. Um, for us developers, we need to be careful with them. We need to get them out of logs, uh, store them, uh, effectively with with encrypted, etc., etc. So really bad UX.

4:33 81% of all hacking related breaches were a consequence of stolen passwords. This is this is a 2022 uh piece of research but still still legit. Um people nowadays uses yeah second factors of authentication. Um the most well-known ones are some sorts some some forms of OTPs. Um historically SMSs were the the the kind of the first uh way of of of people receiving OTPs. SMSs have been dis strongly discouraged by the NIST and and the the full US government basically uh especially at the federal level. Um they are prone to many type type of attacks.

5:26 Um mobile transfer uh mobile number transfers um malware interception at the infrastructure level for example uh social engineering they can call the carrier and uh impersonate trying to impersonate you uh money in the middle attacks etc. Um then there's tots those also have other sorts of problems. uh again prone to fishing. Um there's attacks around server clock manipulation where if a hacker gets access to a server, they will try to freeze the clock of that server and a a specific number will work for eternity.

6:06 um they get if they get access to your browser's cache for example they could try to get access to the QR code you use to set up Google authenticator or obviously whatever application you use and uh that's just a secret that it's built into a seat that you use to set up your app so they will get access to your OTPs and I did update this yesterday uh that's that's research that I was able to do um back then when the first time I gave this talk it was 28% of all people that uses some kind of authentic second authentication factor luckily that has been bumped to 52 um that that that research link now it's really good has a lot of good numbers if you want to take a look at that um uh and at a company level that number scales up to 67 not that bad um 80 8904 organ of organizations that suffered at least one fishing attack in the course of 2022 uh had a co that had a cost an average cost of 2.19 million and the the the the

7:18 gray number uh that kind of follows up on this slide. It's that after that that that those attacks 64% of of those companies kept using chest passwords and that was it. So, um, I I I I I like to walk you through a classic fishing replay attack. I know it's more trendy nowadays, but back in the days it was kind of not that well known. Um, but for example, let's say you get an email um with a link to enter one system you use for something you do. um that email might have a link for you to a button for you to authenticate with sign in with Google for example which is a very well-known authentication method we we use across systems um you do that you you seems legit you click on that you land on this page it sounds pretty legit looks Google all all around um put my email put my password put a second factor because I'm um cautious user um very safety security minded person. Um if you take a really good look that's

8:29 actually fake google.com uh a very common practice when when fishing attacks get done it's that they shorten down the viewport of the window that pops up so you just see the piece that they want you to see. Okay. So that is a little bit why something like web of or pass came up. Web of it's a long standard. Uh even its definition it's a lot of paragraphs and complicated words. Um, but for me to put in the simplest words as I can, it's a it's a it's a standard that defines a set of rules for APIs to enable users to strongly register and authenticate on the web using public keybased cryptography.

9:19 the folks that created this um it was a joint effort between the W3C which is an international organization that uh uh works on standards to on the web for the web and the ph alliance. I was actually here in San Diego because I last during the early part of this week I was in in the conference in the annual conference they put together which is called the authenticate con and it was great. It's it's an organization that was uh uh originated in 2013. It's um it's composed by big big companies. Uh like the this is just a few of them, but it's just to show you a sense of the the type of players that that form the the the Fighter Alliance kind of they define the destiny of of of the standards and and they are we need them to because they implement uh operating systems and all the all the pieces that that actually make something like web of possible. Um the standardization process it was it's has

10:26 been going on for a long time. It all started in 2016. It was just uh a working draft back then. Um in 2019 it became a standard level one. Uh it went on to standard level two in 2021. Right now I checked yesterday again still uh we are still in the draft in the draft of level three but that draft has been going on for a while. I think we're pretty close to getting level three and publish it uh as a standard um where people collaborate on it and it's pretty cool that you can see all the discussions and what's being built and baked in into the standard in GitHub basically. Uh that's the best place to follow along and even chime in if you got something to to to say. So internally um webin provides um first a possession factor right is the possession of a of a keeper of a of a public and private keeper basically um and you possess that that that keeper through either physical device or a software a software

11:47 platform might be the keychain of of Apple or your Google password manager or wherever the case might be. Other password managers can also um help you hold the possession of that of that. Um the spec again it's pretty long thing but I can I'm I'm going to make an effort to re to summarize that into this this upcoming explanation. It's defines a web authent credential, the keeper with a bunch of properties. Um, sorry, uh, three entities and two user flows. The web authent credential, it's a good old-fashioned public private keeper that has some special properties. It's strong because it's a it's as strong as the algorithms cho chosen to uh create that keeper. uh and it cannot be brute forced basically like passwords are. Um it's scoped and this is a very important property um because it works the same way as cookies. It only works on a specific domain. It only works on a specific origin. Uh keeper is

12:57 generated and cannot be used in in another website basically for the one that was generated before. Um and the most important thing it provides digital signatures that allows you to prove to someone else that you are the rightful owner of that keeper. The entities are three. Um they are called in the standard the authenticator, the client and the relying but fancy words but it's the authenticator. It's a user device again a security key a platform authenticator like your phone uh your computer whatever through a software um program that holds your credentials and generates them um and does the signing. Of course, the client it's the it's a web browser or in there are native APIs that implement um web of in the case of of mobile applications as well. The reliability it's our Ruby server basically. So nothing else. This is the diagram just for you to identify on what's upcoming in the explanation

14:07 with all the actors that I mentioned. The user flows are two in the standard they have fancy names again they are called attestation and that is a process of registering a credential in a server and the assertion which is the process of uh the user authenticating into that server. Okay. So the registration let me see if I can click on this. Many of you probably already seen that. Uh but I grabbed GitHub, three year old GitHub. I didn't have that time yesterday to update all my videos, but um in 2022, this was um how it looked for you to authenticate uh for to for you to register a credential.

14:55 Some of the dialogues might be a little different. Right now, things are not all called security keys, they're pass keys, etc. But um yeah, great. So back to here here. So yeah, authentication again after you register your credentials things will look like this.

15:32 a process that would take you password plus MFA plus everything. It's just gets reduced to something like that. So what's going on behind the scenes when you just touch on biometrics or use security keys? Um the registration um I want to walk you through this flow. That's why I showed you earlier with the different actors. I mean I'm going to try to do that quickly. So a user goes into a website and wants to register. Basically the the website will talk to the server and initiate the ceremony of the attestation ceremony. The server will come back with all the configuration necessary to perform that ceremony. That includes all the algorithms that are allowed by the server to be used in the creation of the credential.

16:22 and an important piece which is a challenge. The challenge is just a huge token that it's used uh to ensure that the whole process it's not tampered with basically and avoid replay attacks. So the the the the web browser grabs all of that, sends that back, sends that to the authenticator device again, either physical or or software app. And in in that moment, the user needs to acknowledge that it's it's uh accepting the the ceremony that it's present it's present in the in the in the interaction and and and that it's going to accept the creation of a new credential. The authenticator will create a new keeper.

17:10 Um, put together a payload that includes a lot of fields, sign that payload with the private key and alongside with the public key and a and an ID for that credential, send that to the browser which at stands will send that to the server. The server will perform validations um that are quite a few many cryptographic um the or that the origin checks out checks out that the the challenge is the same one as the one that it stored when it initiated the ceremony. Um and there's something called the attestation process which is checking that the cryptographic signature that came with that um with that payload checks out with the device brand type and um root certificate register in something called uh the phto metadata store. Again, most people won't use that won't do that at station process for most applications because it's a level of security that goes a little bit higher of what a consumer app any

18:20 consumer app would need. Uh if it everything goes well, uh signals the success of the process to the user and the user it's in. Authentication process follows pretty similarly. So I'm going to go quick. user tries to log in, talks to the server, the server answers back with um pretty much the same thing, a configuration, the origin, a challenge. Um and the only special thing here is that it also will give back to the browser all the credentials that are already reg that are allowed for that user. So they are already registered.

18:55 The browser sends that to the authenticator device. the device will generate a signature. Um the user will uh accept again the the the ceremony. So acknowledge that it's there on the other side. The authenticator will create a signature that goes to the browser and then to the server. The server will perform a bunch of aliations again. And if the signature checks out and the origin uh checks out then we'll signal success back to the user and the user it's logged in. So again I told you there's a lot of cryptographic uh steps you need to follow to in the server to do that those validations.

19:43 uh it's like a 20 something set of steps you need to go through and you can do that on your own if you are uh if you're in if you're curious and want to read the whole standard and get context on everything or you can use the gem that we've been building for a while that will take care of that for you. Um, if you choose to use the gem, um, this is the most basic thing you will need to do. Just install the gem and configure, uh, the origins of the domain for your own server. There will there are many other options that the server will uh, communicate to the weban API through the browser, but we are making default choices for you.

20:28 uh unless you want to get started to learn about the litic curve algorithms and RSA etc etc and and and just tweak that or or understand what what's best I think the gem will take care of that for you pretty well um the registration process but I don't know let's say you got a form um where where you are input where you where you are showing the reg starting the registration process for the user [snorts] you ask them for a username and a nickname for the for the pass the web authent credential the security key you're going to enroll um the server will give you back through uh web authent credentials options for create all the necessary options um that user valid is actually I don't know emulating that the server is checking out that all follows all the rules all the validations for an active record uh user model or whatever the case might be we challenge in the session and for that uh forward that

21:33 answer to the browser. The browser will call the web of API. This is how it looks to call the web of an API navigator credential script with all those options. The user will uh accept the ceremony and in if it's successful we will send that back to the browser which will grab all that payload instantiate web authent credential from from the create from all the params that came in and call the verify method to verify everything checks out. If it does, you probably have to uh you are going to store the web authent uh credential where you're going to actually store the public key and the credential ID in for your user to later use in the in the login process. That's it.

22:23 Authentication is going to go very similarly. Let's say this is the form you use for for your login process. You're going to call the server. the server is going to give you all the necessary options plus you're going to pass in the the allowed credentials for that user. So just the ID of those credentials that it will flow into the authenticator. You will store the the challenge somewhere and send that to the browser. The browser will call the authenticator. Instead of calling create, it's going to call get this time.

22:59 And if it checks out, we'll answer back. You'll pass all that payload again back to the server, which will perform a verify process. Um, you're going to grab the register the already registered credentials before you do that because that's that's what you're going to use in the process of checking in that the the the private key used for signing the payload checks out with the already installed public key you had for that and that is it. So in most common cases, I hope that changed right now, but uh back in the days when I put together this presentation, it was the most common thing for you to use web of uh web of Nest as a second factor. Um and you will still use the password as a first one.

23:51 Um again you were proving in in the second factory when you do the web authent ceremonies you are proving that you possess a web authen credential but web the standard since the early days offered uh an extra option which was which was called user verification. um the verification of of that of of another factor basically either inherence by checking in your face ID your voice or some something biometric of any kind or a knowledge factor again for example some security keys don't have bio most security keys don't have biometrics in it all right so the only way for you to another to add another factor of authentication is actually putting a pin on a juvico key for example you can do that.

24:46 So in that case you would um ask uh the in the in the the web of call uh in the browser you will ask for user verification as required. If you think about it, you are going to have the first the first factor will be the password. Second, the position of the wand credential and a third factor which would be uh the user verification either through uh a biometric or a PIN you that's a lot for most consumer systems. Uh so we would be potentially in a place where we could remove one and if you're going to remove one why not removing the weakest one basically and just remove the password and that's how you land you end in a world where there's webin as a first and second factor and you go passwordless.

25:42 There's many wins in using web of uh again it's cryptographic um keepers so they're not prone to brute force attacks. You're not storing a secret in the server. It's just a public key and it's public by definition. There's no fishing possible in this in this authentication schema because all the credentials are scope per domain. So fake google.com won't check out if if you register that credential with google.com and there's no money in the middle tax between um by considering that you are scoping them by domain and you got a a challenge in the middle that uh stops them from tampering with the flow.

26:29 But historically there was some challenges with all of this. It's not everything is not uh uh perfect. Um if you lo if you lost um if you lose the the the security key or you lose your phone um and it's just the credential live there lives there there's no way for you to recover the the access back to the system and let's say I initially register some um in some system using my Jub key and then I want to use that in my phone and they are not NFC enabled for example there's no portability. It's it's very uncomfortable. Again, same thing with your maybe with your phone and your computer or whatever the case.

27:16 So, the fight alliance at some point said like this is not going to this is not going to scale. We need to figure something out to make this to allow mass adoption. And the answer was PKIs. they the big players Google, Apple, Microsoft, the ones that develop open um sorry operating systems came to an agreement and made a big swing. I rebranded the web authent credentials into pass and pass keys are web credentials that are multi-device basically they are not bound to a specific device that you can tell me. Okay. Um, is that the same level of security? For example, the answer is no. No, there's not. It's not the same thing um as a as a device bound pass keys and they are called like that. And in the range of people just using a password to password plus MFA OTPs for example to um pass keys and then the most secure thing you can get would be device about bus pass keys or just web credentials. Yes, it is

28:35 less secure but it was a step in the right direction because we needed to uh change things to create mass adoptions and it was not going to be possible with the vice bound pass keys pass keys um now are still in the works. Uh there are feature more features coming up. Some of them are you already seen them and they are fully functional in all browsers. uh autofill UI when you are logging in somewhere and your pro password manager wherever detects that uh you got a uh register pass key they will prompt you for that for that they are discoverable you can cross boundaries between um different devices again with password managers with uh iCloud accounts um with a roaming technique that I will show you right now which is the one that pops you up with a with a QR code Um there are other features that are a little bit more new um related origins. Uh there's a way for you to expose that different domains are

29:40 part of the of the same relying party basically by exposing a a well-known endpoint and and sharing those domains in the process. Um there's the challenge with iframes basically when they are cross domain and there's there's techniques in the in the works for that. the signals API which allows you is a very dumb problem but right there there wasn't a good way for uh when somebody uh I don't know removed a security key or something from a system to actually remove that credential from the authenticator device and it was still lingering there and confusing the user probably. So now the signals API came in to resolve that. And then the AA GUID, it's a technique that only existed in the cases where attestation was performed. Now it's being developed uh for for the general usage and it allows you allows the authenticator to send data about itself to the server. So the server could actually show you the nice

30:41 Jubico key or whatever the case might be when they list all your pass keys. So, um, yeah, the registration I wanted to show you like the portability solution using a QR code. I maybe you haven't seen this before. uh that I think it's pretty cool to show you show people how it's being how it's used. [clears throat]

31:16 So I grab my phone and scan the QR. The registration process will allow me to directly save my my pass key. Yeah, probably from someone else from my business partner. Yeah. Uh then he he killed everything. So and those those QR codes don't survive much and the authentication in such a process will look like this.

32:07 [snorts] Hopefully you have used this uh maybe some of you have used this in the past. So in 2022 was like okay um so this was all joke now it's not very relevant when we started with web this is how supporting different browsers and devices will look like as you can see Apple was all red they were not pretty they were not really into this they thought it was never going uh going to be a thing but years after they realized that it was the right thing to do to join you. So in 2023 this is how it looked support wise since we started um this is this is a special one for me. I used to work for their their competition actually. But um these guys uh that are uh private publicly founded uh logging identity provider agency uh for the federal government. Um we saw that they were using our gem back in 2018 and that was like very early adopters and that's when the moment we realized we were doing something pretty cool. Um in 2019

33:35 Google Google's adopted uh Pasi uh sorry they were not Pas webin as a second factor uh Shopify uh jumped in in June 2019 GitHub in 2019 also base camp GitLab um we are still helping GitLab uh in collaborating with them uh on on open source stuff adopting evolving their password setup their PKI setup sorry AW WS etc. So how can how can we like adopt Pasis or add Pasis to app? This is this is what me doing things rushed yesterday. Uh the first thing I want to share this is this is new. This is very new. uh a month ago uh we've the we released something that we've been working for a while more than six months in in in Cedar code which is if you are using Rails 8 authentication maybe if you're not too but um regardless um you will generate if if you install web of Rails you will generate um pretty much uh all the all the all the code necessary for you to implement pass keys in your application

34:52 for you. Of course, it will need not it will not be style as your as your application will need and it's assuming that you use uh stimulus uh which I don't think it's that troublesome. You can export or grab the pieces the necessary pieces and put it into the type of front end you're using. But again, it's trying to make things easier for Rails uh users to get everything Bootstrap. And we've came up with this after doing quite a few in uh Paskki integrations and realizing that there were common patterns that we were repeating from in every single one of them. So it made sense for us to share something that would that do that out of the box for for the broader community.

35:37 uh it uses web and ruby be under the hood uh of course and the beauty is that we are providing it uh for you to use it as a second factor. You can choose if you want to use it as a second factor or you wanted to use it for for as as the first and second factor. The most classic UX you are seeing right now in applications around Pascis is exactly that like you loging in conventionally with a or register conventionally with a with a password and maybe a password and MFA but then um applications are performing what's called a step up process and actually prompting you to create a pass key after that and then when you come back and try to login if they detect that you have already register a pass key they will try to suggest that you log in using a pass key and that's the only thing that will ask her for you. They will not do the email thing. They will not do the SMS or whatever other OTP you got. They will

36:33 just accept the pass key and be happy with it. So, if you actually take the step and enroll a pass key, you will be making your future life simpler and and avoiding several steps each time you log in from a different device or things like that. That is uh that is not the gem. The QR code is not the gem. a blog post from one of the folks that worked uh mostly on that gem and it explains all the code uh piece by piece of what what we're generating and why is it useful. Okay. Uh if you just don't like that gem, you don't want to even take a look at it and you want to learn everything and go from scratch, we also have a couple of demos. This is using web and Ruby just in a bang sheet application.

37:20 you can strike the pieces you want. This is the fully passwordless version. There's another one when you want to use as a second factor. And there's other examples, more real life type examples that I would like to share with you. We didn't end up uh doing it ourselves for Ruby gems. We opened a big pull request that then was this guy Dorian picked up and actually uh got into a different PR. But it's a great um real life example on a on a clearance based authentication system which I don't I know clearance is not very popular these days but still useful um if you're using Ruby gems and using an OTP as a second factor sorry you're you're using this um master then this we were uh very early in the process we uh added it uh as a second factor in 2020 currently We are working with them to add this behavior this UX that I was telling you about that is pretty standard everywhere. So we are very we're very

38:25 excited about uh helping them with this. Um in the future we are going to keep working on web and Ruby which is the main star. Um again it's web Ruby is just the the the tip of the iceberg. There's a bunch of gems working be below that that layer. We had to implement other standards that the web authenta depends on like civor cos uh different type of attestations like TPM like Android etc. Uh but the phyto metadata store connector that we use for attestation there's there's a bunch of gems we need we we need to invest a lot of time into maintaining them and we're going to keep doing that. Um we are working on a Pasis uh a Pasi setup for device users as a second factor uh that is going to be released soon and I was just in the Pho alliance conference and I learned that there are other depend standards that kind are kind of based on the one from web that are going to allow very amazing things that the guys from

39:29 Visa Mastercard and the banks showed that it's pretty much using Pasis for as uh secure smooth checkouts processes for uh guests uh g uh guest users and and and different contexts which is so cool to see even in agentic contexts where people does e-commerce through an agent and at at at the end of the checkout process just a pusky dialogue pops up and you are done. Uh and then another uh usage that it's I I saw and it's pretty cool. It's in the US is pretty advanced in terms of digital credentials and having your driver licenses and passports in your phones basically uh signed by uh an approved issuer. Great.

40:16 That that doesn't exist in in Latin America to my knowledge. So I was kind of amazed. uh the process of register registering and knowing uh your customers from uh different applications uh mixing those digital credentials plus passing as as the authentication method will be very beautiful future this is a bunch of resources and that's it if you want to play around with my demo I'll leave it Yeah.

41:00 So, you hit on something at the very end there that I think is interesting. Uh,

41:04 did you say know your customer as in like the KYC KYB process of identifying users and the ability for that to be shared beyond? So like every app that takes a banking application isn't going to have to run a KYC process. There's going to be you're

41:23 the KYC process will evolve into right now many many apps are doing KYC um by doing the classic take a selfie with your driver license and everybody hates that. It doesn't work well in a world where you do digital credentials and they are signed. Um your phone will will will provide a signature that represents your digital credential. Send that in a passing manner so that the server will check out if that signature checks out. Good.

42:01 Yeah. And actually you will be able to check out that you are who you say you are by calling uh the issuer certain endpoints to verify your digital signature. Basically you will sign your phone will sign with your private key that you are who you say you are and then send that to the server. The server will ask for the for the public key to the issuer. The issue will share that and if it checks out you are who you say you are. then we will avoid the the selfie and all that thing. So it's kind of following the same structure as as as what I showed for Pasis. Basically if you add a there are separate processes like know your customer it's a separate process from pass but it's based uh digital credentials are based on the same type of technology and if you join that with the usage of pass keys for authentication after you verify you are after you done the KYC process then it's going to be a smooth work

43:12 or IP. Yeah. Is there a difference between using like Chrome versus Google versus Apple versus like Microsoft to store your pass keys or is it like

43:29 No, they all they all need to implement well you are relying on the security of those providers basically because some if someone grs access to your keychain or your Google password manager and you are a compromise completely as a user because they got access to all your passes. So you that's the point of choice that I see between them. But as a as an authenticator platform they need to uh implement what it's called the CTIP2 protocol which is part of web authentics one piece. The other piece is how the the protocol that the standard that rules how the authenticator work and that is the CTIP2.

44:13 So they are certified CTIP2 providers. they implement the standard to the dot. There's there's nuances, but they they've gone through the certification process, so they're clear. Uh I I hope I answered your question somehow.

44:31 I guess the follow be is there a place where we can see all the people that or all the companies that have gone through the process like so I can look to make sure my password manager Yes. is

44:42 the fight alliance website. Okay. Yeah. Exactly. where in that I cannot tell you but you will probably navigate very easily to the place that it's going to tell you which uh which ones are certified. There's some some cool websites that I put in the in the resources that will also show you which web applications like Ruby web application Ruby web application you're probably going to choose hopefully to use web and Ruby. I'm not going to do that all that on your own, but that's up to you. But any technology, you got the whole list of server side uh libraries you can use, and you are going to see which ones are certified, which ones are conformant, and which ones are at your own risk. Uh conformant means certified that probably certified that didn't pay the fight alliance to get this the stamp. I'm actually I actually talked to the phto alliance guys to understand what it would imply to uh get the stamp

45:43 moneywise but for a library it's kind of I don't know how much sense does it make because it's like it's the application that should get certified and not all applications should do that probably for example Shopify and I don't think Shopify is certified might be wrong uh but if you're a bank if you're a credit card if you're yeah you you need those certification If if you're doing uh identity verification for the government, you will need to get certified. Depends on your use case basically. Thank you.

Questions about this episode

What is discussed in "XO Ruby San Diego 2025 - Passkeys in Ruby by Braulio Martinez"?

In order: 0:00 GitHub, Ralio Martinez, Syncode; 5:00 Google LLC; 10:00 GitHub, Google LLC; 25:00 Google LLC; 30:00 GitHub, Google LLC; 40:00 Google LLC.

What is mentioned in this Confreaks episode?

8 people, works and ideas are mentioned, including Google LLC, GitHub, Ruby, WebAuthn, Apple Inc., FIDO Alliance. Each one on this page links to its own page with every episode that mentions it.

How long is "XO Ruby San Diego 2025 - Passkeys in Ruby by Braulio Martinez"?

The episode runs 46 min; the transcript is about 6,720 words in 54 timestamped sections.

More from Confreaks

• All analyzed episodes
• Books mentioned on Confreaks
• People mentioned on Confreaks
• Topics mentioned on Confreaks