[Public] Passkeys Hackathon Tokyo event report

Please send any inquiry about this event or document to Eiji Kitamura (agektmr[at]google.com).

In June 2024, Google collaborated with FIDO Alliance to organize a passkeys hackathon in Tokyo. The goals of the event were the following:

• Provide participants an opportunity to experience actual passkey development.
• Provide participants an opportunity to receive direct advice from passkey experts.
• Help participants prototype passkeys that can be used in the actual product.
• Further advocate for passkeys by sharing detailed information with the participants.
• Understand the pain points and feedback on passkeys.
• Create resources for running a similar hackathon in the future.

Find out outcomes from the hackathon:

Date: June 21th, 2024

Place: Google Tokyo Shibuya office

Staff: Eiji Kitamura, kokukuma, Kotaro Oi, Hideaki Furukawa, Kosuke Koiwai, Kento Goro, Yoshinori Matsumoto, Naoyuki Shiraishi, Vaibhav Kumar

Participants:

The event started at 10AM with a brief greeting, an introduction to staff and each team, then actual hacking. The hacking continued until 4PM with a brief lunch break. During the hackathon, the staff walk around the room answering questions and feedback. There were quite a few interesting ones which are summarized at the bottom of this report.

Here’s what each team worked on during the hackathon:

Participants and winners

The 9 participants were selected out of 25 proposals following the strict criteria with 5 judges. Even though "passkeys hackathon" sounds straightforward, the teams came up with some very creative ideas!

Grand winner: Keio University SFC-RG pkLock team (Keio University)

Keio University's SFC-RG pkLock team was the only team in this competition to take on the challenge of combining IoT devices with passkeys. They brought a 3D printer for this purpose.

Their pkLock (pronounced "pic-lock") aims to solve the common problem of cumbersome key handover for Airbnb and other private lodging by using Passkey's cross-device authentication (Hybrid Transports).

The device they created consists of a QR code display device installed on the outside of the door and an unlocking device installed on the inside. In addition to the device, there is a web application that users use for booking and unlocking. Guests can unlock the door simply by holding their hand under the QR code display device in front of the door, reading the displayed QR code with their smartphone, and performing passkey authentication (cross-device authentication).

They also paid particular attention to the design of the device to make it a device that hosts want to install in their accommodations. The sophisticated design is not out of place even if it were installed in a first-class hotel. Their comprehensive approach, which also considers the potential widespread adoption of these devices, resonated strongly with us who want to improve the user experience and promote the use of passkeys.

During their presentation, they generated great excitement among the audience by actually unlocking a miniature door they made during the hackathon. For this demonstration, the device displayed a QR code containing a URL with a one-time token that directs users to an authentication page. In the future, however, they plan to implement Hybrid Transports on the device to enable direct unlocking. They won the championship for their pioneering and challenging efforts in exploring the possibilities of using passkeys on IoT devices.

A comment from the presenter (Kosuke Koiwai) about the award: The proposal of a new use case for the utilization of passkeys in IoT, the presentation of solutions using passkeys to unresolved issues, the development carried out within the time limit, and the successful demonstration during the final presentation, though not perfect—these achievements demonstrated high quality in all aspects of the hackathon: presentation, development, and demonstration. It was indeed a model example of what a hackathon should be.

FIDO Award 1: SKKN (Waseda University)

Verifiable Credentials bound by FIDO authenticator

SKKN is a research group from Waseda University, specializing in privacy studies. The team name, SKKN, is derived from "SaKoKeN", referring to the Sako Laboratory. SKKN developed and demonstrated a product for issuing and presenting Verifiable Credentials (VCs) linked to authenticators.

Verifiable Credentials (VCs) are digital certificates that prove user information such as name, affiliation, and address. If the Holder (wallet) that stores and manages VCs is vulnerable, VCs can be stolen by others, and others can impersonate the user by presenting the VC. Therefore, in addition to enabling only the user who has the FIDO credential to present the VC, they have developed a method that allows only trusted wallet services to handle VCs.

First, the user registers with the Wallet Service Provider (WSP) using FIDO, and as a result, the user receives a VC (hereafter referred as “VCw”) containing a secret ID from the WSP and stores it in the wallet.

When obtaining a VC that proves user attributes from the issuer (Issuer: affiliated company, etc.), a Verifiable Presentation (VP) containing the VCw is sent to the issuer in advance. After receiving the user-attribute VC from the issuer, the user sends the VC to the WSP for storage using FIDO authentication.

When presenting the user-attribute VC, both the VCw and VC are received from the WSP and presented to the verifier (Verifier) on the other side. At that time, a zero-knowledge proof is given to prove that the ID in the VCw matches the ID in the VC. This allows the Verifier to confirm that the VC is from a user authenticated by the WSP with FIDO.

Furthermore, it is possible to back up and restore VCs to the WSP using FIDO authentication.

The advantages of this method are:

• By linking and issuing VCs and FIDO credentials, only the owner of FIDO can use the VCs.
• Only wallets trusted by Issuer and Verifier can be used.
• By using FIDO (passkeys), VCs and wallets can be backed up and recovered, and users can recover even if they lose their device.

A comment from the presenter (Hideaki Furukawa) about the award: The SKNN team has presented a very advanced use case of passkey as combining it with emerging technologies such as verifiable credentials and zero-knowledge proof. As the verifiable credentials and zero-knowledge proof are in the spotlight in the context of self-sovereign identity and distributed identity (SSI/DID), their presentation has attracted great attention from both the hackathon’s judges and other participants. The team’s work has carved out the future of digital identity.

FIDO Award 2: TOKYU ID (Tokyu)

The URBAN HACKS team, also known as the TOKYU ID team, from Tokyu Corporation, has been awarded the FIDO Award for their innovative passkey adoption for TOKYU ID. The Tokyu Group is a large Japanese conglomerate with a wide range of businesses centered around transportation and urban development.

TOKYU ID is designed to streamline everyday interactions, such as train rides. Recognizing the critical importance of user experience, the team implemented passkey sign-in in February 2024. This is to address potential issues such as missing a train due to delays in two-factor authentication in digital ticketing services provided by a web application.

They participated in this hackathon to validate their vision for TOKYU ID. Their ideal scenario envisions all users registering and logging in with passkeys, coupled with seamless account recovery. To realize this, they focused on two key implementations at the hackathon: enabling passkey registration during the initial membership sign-up process and introducing social login for account recovery. Uniquely, after recovery through social login, users are only permitted to register a passkey, underscoring the team's commitment to a passkey-centric design. They also integrated FedCM to improve the user experience in account linking processes.

The Iwashi-san team's passkey-centric approach demonstrated a deep understanding of user needs and product requirements. At the hackathon, they successfully implemented their solution and delivered an interesting presentation. This led to their FIDO Award win.

Notably, they integrated Google Sign-In without using the GIS SDK with just vanilla JavaScript using FedCM!

A comment from the presenter (Koichi Moriyama) about the award: The significant contribution from the Tokyu team was to make the best use of passkeys benefits, simpler and stronger authentication. The demonstrated use cases such as how their customers may avoid taking time for logging in and authenticating in front of a ticket gate. Almost all merits using passkeys were well designed, implemented, and demonstrated; thus, the outcome can be the best example for the future passkey developers.

Google Award: Team Nulab (Nulab)

Nulab is a software company that provides services such as Backlog, Cacoo and Nulab Pass. They have multiple two-factor authentication solutions (security keys, SMS OTP, email OTP, TOTP) and WebAuthn across their services. And they have fully supported passkeys since October 2023.

They have implemented eight new features and staff got an opportunity to pick one for a demo:

• Passkeys card
• A passkey introductory content
• Passkey adopter rewards
• Assistance for smooth account recovery
• Sign-in with a passkey button
• Mandate 2FA for passkey adopters
• Password removal and passkey promotion on credential leaks
• Promote passkeys upon resetting a password

They demoed "Assistance for smooth account recovery": The idea was to nudge the user with an additional action when they add a passkey. If the added passkey is device-bound, recommend the user to add another passkey from a different password manager. If the added passkey is synced, recommend the user to remove the password.

After the award ceremony, they also showed off some interesting tricks to their implementation:

• Passkeys card: indications

• creation date and platform
• last used date
• whether the passkey is synced or device-bound with the BE flag

• "Use a security key" checkbox next to the "Register a passkey" button for better credential handling.
• AAGUID for identifying the passkey provider.
• Passkey adopter rewards: User account icon highlighting. When the user adopts a device-bound passkey, the icon starts to circling. When the user adopts a synced passkey, the icon starts to blink. Since this is an enterprise tool, this motivates users to stand out within the company by adopting passkeys.

A comment from the presenter (Eiji Kitamura) about the award: Nulab was an early adopter of WebAuthn and they were one of the firsts to adopt passkeys as well. I'm impressed by their creative ideas to improve their passkey implementation, in particular how users can recover their account. Not just suggesting to add a second passkey, also suggesting to create a passkey when the user forgets their password is new. I believe this is one of the guidelines we can recommend many relying parties to do which is transitioning from passwords.

Nikkei ID (Nikkei)

Nikkei Inc. is a news publisher known for high investment in tech with 1.1 million online subscribers and is the parent company of FT. The Nikkei team took this hackathon as an opportunity for a cross-team collaboration as well as a chance to prototype passkeys which were already on their roadmap. Their team consists of people not only from the backend and frontend but also from client and security.

Their authentication system is built with OpenID Connect. They took on the challenge of implementing passkeys on top of it, aiming to reduce user pain by skipping traditional reCAPTCHA and MFA. Furthermore, they were the only team that implemented passkeys on an Android app using Chrome Custom Tabs. They are planning to implement sign-up flow using Credential Manager in the future.

Despite typical hackathon troubles such as deployment taking 10 minutes, a member unable to attend hackathon at the last minute, and environment issues, the Nikkei team demonstrated a successful and smooth passkey enrollment and login operation.

Dentsu Soken (Dentsu Soken)

Dentsu Soken Inc. is a leading IT services and solutions provider based in Japan. Established in 1975 as a joint venture between Dentsu Inc. and General Electric, the company has a rich history of supporting digital transformation for businesses and society. They are developing a digital identity wallet which is issuing verifiable credentials and accommodating such credentials.

At this hackathon, they implemented passkey on OID4VCI endpoint as an issuer, combined with the Google Sign-In. As soon as a user signs up to the service using Google Sign-In, a passkey enrollment is prompted so that the user can create a passkey for faster sign-ins in the future. Even if it's dismissed, the user is prompted to do so next time they visit. The benefit of using Google Sign-In for the service is to be able to obtain verified information such as an email address without additional steps.

In the future, they plan to allow users to add configuration so that signing in with a security key is possible, or the sign-in flow can skip showing the confusing QR code.

While their demo looked smooth, ordinary and nothing special, the staff enjoyed their advanced concept of combining passkeys and identity federation and the verifiable credentials as a product. We learned a lot from them.

SST-Tech (Secure Sky Technology)

SST-Tech is a team from a security expert company conducting security assessments. As part of their work, tools like Burp Suite and OWASP ZAP, which are proxy-based, are often used for scanning. If a login session expires during the scan, it is necessary to automatically recreate the login request. While this is easily achievable with traditional form-based authentication, the same approach cannot be used with passkey authentication. Therefore, they attempted to emulate passkeys in this case.

Despite being a smaller team of only two people compared to others, they maintained strong communication and collaboration throughout the project. They initially tried implementing their own emulated authenticator but encountered technical difficulties with crypto and issues with FIDO MDS, which prevented further progress. After exploring Chrome and DevTools, they found DevTools' WebAuthn Emulator supported FIDO MDS and could emulate passkeys in headless browser environments.

Unfortunately, they encountered "Bad Request" errors and could not complete the task within the given timeframe. However, they had several ideas for potential solutions and plans to continue development.

If this method can be successfully implemented, it will not only enhance security assessments but also facilitate debugging and automated testing during passkey authentication development, thereby improving development efficiency.

Ajitei Nekomaru (Keio University)

Ajitei Nekomaru is a team consisting of students from Keio University. They took on the challenge of introducing passkey authentication to an open-source LMS (Learning Management System) used at their university. Their goal was to reduce the cost of introducing and operating additional solutions by directly implementing passkey authentication into the open-source LMS.

Based on the experience with the system they use at their university, they analyzed the user experience and user types, and shared their medium- to long-term plans for introducing passkey authentication.

They also shared the challenges they faced in introducing passkey authentication to an existing open source project. As passkeys become more widespread, how to incorporate passkey authentication into an existing open source project will become a challenge, and sharing such experiences will surely be beneficial to many developers.

Questions and answers

Technical session

• Are there anti-patterns for passkey implementation that could lead to vulnerabilities?

• Implementing passkeys without relying on a server side library is not recommended.
• Check the UV flag following your policy.
• Authentication before registering a passkey must be strong. An attacker may create a passkey on the sly and use it later.

• If the user changes the email address used for login, can it be updated on the passkey as well?

• Currently, no. But the Signal API is being discussed to address this matter.

• What is the difference between a FIDO credential and a passkey?

• Officially speaking, any FIDO credentials are passkeys.
• Meanwhile, there are people calling only discoverable credentials passkeys.
• In WebAuthn L3, a passkey will be defined as a synonym of a discoverable credential.

• From a phishing resistance perspective, I would like to know the difference between Chrome's password manager and passkeys.

• In terms of suggesting a credential on proper domains, password managers treat passwords and passkeys in the same manner. However, while passkeys are not, passwords are easily copied and pasted as text on any input field on another domain which leads users to be phished.
• 3D-Secure on some payment services asks for a password from a completely different domain than where it was created without proper affiliation. This makes the situation worse.

• To what extent can WebAuthn extensions be specified flexibly? Can values be freely set as long as there is agreement between the Relying Party and the Authenticator?

• Availability of WebAuthn extensions depend on the browser and the authenticator. You can't use an extension if they don't support it.

• Mercari initially used only device-bound passkeys but later allowed synced passkeys. Were there any new or unique issues due to allowing synced passkeys?

• Some users saw unique issues with enabling synced passkeys on devices such as iOS. However, the number of inquiries related to device-bound passkeys (migration, lost device, etc) was far more and the situation is much better with synced passkeys.

• I think there is a risk of QR codes being scanned from behind in cross-device authentication. Is it possible to prevent this through specifications such as CredentialCreationOptions?

• PublicKeyCredentialHint is an emerging feature that may prevent showing a QR code, depending on browser's implementation.

• Regarding the cross-device authentication with a passkey, is it possible to operate the passkey device separately like CIBA? Is Bluetooth connection mandatory?

• Bluetooth connection is mandatory, hence it will be difficult to achieve the same use case as CIBA.

• My understanding is that Webauthn Level 3 specifications are still in draft status. Could you explain the current differences between Level 2 and Level 3? Additionally, for the hackathon implementation, which specification should we refer to among the two versions available on w3.org and w3c.github.io?

• The specification on w3.org is stable and recommended. The one on w3c.github.io is actively being discussed and subject to change.

• In the Mercari stats, what affects the passkey authentication success rate compared to ID and password, which often have incorrect entries?

• Can't recognize face, fingerprint or the user enters an incorrect PIN. No passkeys found.

• Are operational costs similar between passkeys and SMS OTP?

• Mercari previously relied on SMS for authentication during login and app usage, which led to increased SMS sending costs as the number of users grew. However, since prioritizing the use of FIDO, they have been able to reduce costs.

• If you don't want to sync passkeys, does the WebAuthn specification offer any options for that?

• On Android, you can create a device-bound passkey by making it non-discoverable. However, there's no guarantee this will forever be the case. Also, non-discoverable credentials are different from discoverable credentials in terms of user experiences; users have to type their ID first.
• In FIDO Alliance and W3C, there's a discussion around Supplemental Public Key extension which allows RPs to bind another key to the device which can be sent along with the device. Maybe it will be available in the future.

• My understanding is that passkeys are based on RSA (or other asymmetric cryptography) and strong against MITM attacks. Is this correct?

• Not quite. Passkeys are safe because clients (browsers) make sure the RP is genuine and connected through a secure channel (https) before the passkey is used.

Hackathon (including feedback)

• I'd like to create a passkey during new user registration. How should I create a user ID?

• The user ID can be a temporary passkey specific user ID. You can store it in the session and obtain it from userHandle on authentication.

• Why is it necessary to create a separate user.id instead of using the user's main ID?

• It becomes PII (Personally Identifiable Information). It can be obtained from userHandle.

• On Android, passkeys cannot be launched unless the OS default camera is used. It would be great if Chrome can add a note beside the QR code.
• I registered a passkey in Chromium DevTool's virtual authenticator, but allowCredentials is called empty and it doesn't show up.

• Check that it is not registered as a discoverable credential in the virtual authenticator, and recommend explicitly setting residentKey in the parameters when registering the passkey.

• LINE can display a QR code and scan it with the app to log in. Can we do the same thing?

• LINE likely uses OAuth 2.0 Device Flow. Even if the behavior is similar, the protocol is completely different from passkey's hybrid. Device Flow has the weakness of not being able to guarantee proximity.

• There are cases where you want to tell users not to use device-bound passkeys on shared PCs. How should you convey this? Is it a good idea to explain about private keys?

• The concept of private keys may be difficult for end users to understand. It might be better to break it down and say, "Please do not set it up on PCs other than your own device, such as shared or public PCs." It is better to emphasize "not setting up" rather than "not using".

• I'd like to use the same passkey on Android and websites.

• Please use Digital Asset Links.
• Just be careful about Origin verification.

• I'm having trouble with a vulnerability assessment app because the protocol between the browser and the server is not defined. The tool does not currently include a mechanism to check parameters passed by JavaScript.
• It would be helpful to have a way to reproduce credentials in a virtual authenticator. I'd like to be able to import existing passkeys.
• Question about PRF usage. I would like to create an ID that is shared only between a client and a server.

• I couldn't grasp some of the finer details of the question, but the ID itself is something you want to use even if the credentials become invalid, so PRF might not be suitable for that purpose. PRF is intended to be used more on the client-side.

• Is there a security key that can import credentials for the purpose of automated testing products that check MDS?

• As far as I know, there isn't. Such a key wouldn't pass the certificate and wouldn't be listed on the MDS.

• When authenticating cross-device from a PC to a smartphone, it sometimes times out depending on the network. What could be the cause? It feels like it's being stopped by a firewall.

• When authenticating using Hybrid transports, WebSocket (Secure) communication to the following two domains must be allowed. If they are blocked by your company's firewall or web proxy, please allow them.

• cable.ua5v.com (Android)
• cable.auth.com (iOS/iPadOS)

Summary

All the staff shared that they have enjoyed the event more than the participants. It was such an engaging, passionate and exciting event we had. Especially the discussion around the tricks how participants make passkeys more usable and convenient, topics around verifiable credentials and zero-knowledge proof were notable. We've learned a ton too.