Standard Grant: Nydia Passkey Holder – Chapter 3.5

Grants Proposed
1

Standard Grant: Nydia Passkey Holder – Chapter 3.5

Project Name: Nydia Passkey Holder - Chapter 3: Where Nydia Unlocks the Power of Touch
Project Lead: Oleh N.

Project Description

Nydia’s evolution unfolds in three acts:

2024 — Nydia launched as a decentralized passkey authenticator.

Chrome and Firefox gained seamless passkey storage and sync backed by the Sia network, removing vendor-ecosystem lock-in between browsers and their cloud services and shifting credentials from corporate servers to user-owned infrastructure.

2025 — If the first act was an escape, the second is a gathering of allies. Safari arrives, and passkeys flow across Chrome, Firefox, and Safari — powered by Sia.

Nydia also implemented support for the EdDSA (Ed25519) signature algorithm for passkeys, going further than what is currently available in most browser-extension authenticators. While most remain limited to ECDSA (ES256) and RSA (RS256), Ed25519 offers superior performance, smaller key sizes, and enhanced security.

Another critically important feature has been implemented: the onboarding process generates a unique 12-word BIP39 recovery phrase to encrypt passkeys before storing them on the Sia network.

This combination of decentralized storage and cutting-edge cryptography makes Nydia not just another authenticator, but a glimpse into the future of authentication.

2026 — Android has joined the group chat.

With this research and development initiative, Nydia brings passkey ownership to Android with a credential provider backed by the Sia network.

The Android Credential Provider Service lets third-party authenticators plug directly into Android’s native sign-in UI and present passkeys alongside platform options with no app switching. For the first time on Android, users can choose their passkey storage provider while keeping a fully integrated, one-tap experience. With Nydia, user-owned credentials feel as natural as the defaults, pairing control with ease of use.

Two key features distinguish Nydia’s Android release: borderless, cross-device QR sign-in and verifiable, tamper-evident registration integrity.

For universal accessibility, Nydia implements QR-based cross-device passkey sign-in, allowing users to sign in on a desktop or laptop by scanning a QR code with their Android phone. Users can create passkeys on their PC through the Nydia browser extension, securely synchronize the encrypted passkeys with the Nydia Android app via a selected Sia indexer, and use them for QR-based sign-in. The phone generates the FIDO2/WebAuthn assertion, while the browser or app on the other device completes the sign-in. During this flow, private key material remains on the phone and is never transferred to the other device. This enables secure passwordless access on personal PCs, shared computers, public workstations, and borrowed devices.

For registration integrity, Nydia implements Self Attestation — an attestation type that uses the packed attestation statement format, where each passkey proves the authenticity of the registration data and key possession by producing an attestation signature over that data with the private key generated during the registration ceremony. This creates a tamper-evident cryptographic binding between the registration parameters and the resulting credential, ensuring the server can use the corresponding public key to verify proof of possession of the credential private key and the integrity of the registration data. This enhances auditability of registration, from challenge through credential creation. For Nydia, self attestation delivers verifiable passkey registration while preserving Nydia’s commitment to user privacy — each credential carries a self-signature as proof of private-key possession and registration-data integrity.

Who benefits from your project?

Developers: Nydia provides open-source building blocks for creating authentication applications:

  1. Nydia-Core SDK — an open-source passkey SDK with C/JNI bindings for Android. It provides a Go FIDO2/WebAuthn authenticator core — passkey creation, assertion signing, Ed25519/ES256/RS256, COSE/WebAuthn serialization, and self attestation — together with a Sia storage integration layer for backing up encrypted credential records. Key derivation and encryption remain in the Nydia-Vault SDK, while developers can reuse the authenticator logic and get a ready integration path to Sia storage.
  2. Nydia-Vault SDK — a reusable Kotlin Multiplatform library for BIP39 recovery, Android Keystore protection, encrypted Room persistence, and browser-compatible credential import and export. It separates metadata from private key material into independently encrypted envelopes — so passkeys can be listed without exposing private keys — and prepares encrypted credential backups for synchronization through Sia.
  3. Android Credential Provider Service scaffold — a ready-to-extend implementation of Android’s CredentialProviderService that handles Credential Manager registration and the create/get request flow, letting developers expose their own passkey backend as a system-wide credential provider.

The two SDKs form the Nydia SDK family, published as standalone, documented Maven artifacts. The provider scaffold ships as open-source code in the Nydia app, which itself serves as the SDK family’s first consumer.

Users: Android users gain full control over their passkey storage — choosing where credentials are stored and by whom. Beyond personal devices, QR-based cross-device authentication extends Nydia’s reach to anyone who needs secure access on untrusted hardware — whether signing in at a library computer, a colleague’s workstation, or a hotel business center. Passkeys remain accessible everywhere, without ever leaving the phone.

How does the project serve the Foundation’s mission of user-owned data?

With Android support, Nydia brings passkey ownership to mobile devices.
Your keys. Your network. No vendor lock-in.

Who is the target user for your project?

Anyone who uses passkeys and wants portable credential recovery under their own control and secure QR-based authentication on untrusted hardware, without being locked into a single device, platform, or vendor.

Milestones & Project Goals

Note: For planning purposes, the timeline is based on a July 1, 2026 start date.

Milestone #1 (Due by 25 July 2026)

Create CredentialProviderService skeleton for Android 14.

  • Make provider visible in Android system credential picker.
  • Handle Credential Manager requests for createCredential and getCredential.
  • Parse and display PublicKeyCredentialCreationOptions in the UI.
  • Parse and display PublicKeyCredentialRequestOptions in the UI.
  • Publish project on GitHub with clear build instructions.
  • Create a demo video demonstrating provider in action.

Milestone #2 (Due by 25 August 2026)

Implement passkey creation across WebAuthn playgrounds and pilot apps with support for Ed25519, ES256, and RS256 signature algorithms.

  • Implement passkey creation with support for Ed25519, ES256, and RS256.
  • Implement a CBOR encoder for attestation objects and COSE keys.
  • Implement authenticator data flags per the WebAuthn specification.
  • Return authenticator attachment as part of the PublZ
    ZicKeyCredential.
  • Support the credProps registration extension and return rk in client extension results.
  • Implement transport hints for credentials.
  • Implement self attestation support for passkey registration.
  • Implement the C/JNI wrappers, along with a Kotlin API, to expose passkey creation to Android applications.
  • Create a demo video demonstrating successful passkey registration.

Milestone #3 (Due by 25 September 2026)

Implement passkey authentication (assertion).

  • Generate valid assertion signatures that pass relying party verification.
  • Implement allowCredentials filtering in the assertion flow.
  • Support usernameless assertion with client-side discoverable credentials.
  • Extend the C/JNI wrappers, along with the Kotlin API, to support passkey assertion.
  • Create a demo video demonstrating successful authentication flow.

Milestone #4 (Due by 25 October 2026)

Integrate the Sia Storage SDK and publish the nydia-core SDK.

  • Integrate the go.sia.tech/siastorage SDK.
  • Upload and delete passkeys per credential.
  • Reconcile local and remote passkey state via bidirectional sync.
  • Derive and securely store the AppKey for the selected indexer from the user’s recovery phrase through the Sia Storage SDK as part of the indexer approval flow.
  • Define and document a stable Nydia AppID, enabling supported clients to access the same Nydia account on the selected indexer using the same recovery phrase.
  • Publish the Nydia-Core SDK as a versioned (SemVer) Android library (.aar) to a public Maven repository, with a maintained changelog and automated releases.
  • Build native libraries for arm64-v8a and x86_64 so the SDK runs out of the box for any Android developer — on physical devices, emulators, and CI runners.
  • Bundle R8/ProGuard consumer rules in the artifact so the authenticator/JNI surface survives minified release builds.
  • Publish SDK documentation — installation, a quickstart (create a passkey, sign an assertion) and an API reference.
  • Validate the SDK in Nydia itself: the Nydia Android app will depend on the Maven-published SDK rather than local source code, demonstrating that the SDK is a reusable artifact rather than repository-internal code.

Milestone #5 (Due by 25 November 2026)

Design UI.

  • Create UI displaying all saved passkeys.
  • Add per-credential passkey backup UI.
  • Track and display per-credential passkey sync status in the UI.
  • Add UI for bidirectional sync of passkeys.
  • Add a settings screen.
  • Add in-app notifications.
  • Add passkey deletion.
  • Implement dark theme support.

Milestone #6 (Due by 25 December 2026)

Implement secure encrypted passkey storage and publish the nydia-vault SDK.

  • Implement 12-word BIP39 recovery phrase generation, validation, and entropy decoding.
  • Coordinate Android onboarding so one 12-word BIP39 recovery phrase initializes both the passkey-encryption root key and a separate AppKey for access to the selected indexer, while keeping the two keys and their security roles isolated.
  • Derive separate encryption keys for credential metadata and private key material using HKDF-SHA256.
  • Encrypt credential metadata and private key material as independent AES-256-GCM envelopes, allowing passkey metadata to be listed without decrypting private key material.
  • Store only encrypted credential records in Room.
  • Protect the passkey-encryption root key with Android Keystore for day-to-day unlock.
  • Implement an onboarding walkthrough with recovery phrase generation and confirmation.
  • Implement a login wizard for passkey recovery.
  • Implement biometric authentication.
  • Implement fallback to PIN/pattern when biometric authentication is unavailable.
  • Publish the Nydia-Vault SDK as a versioned (SemVer) Android library (.aar) to a public Maven repository, with a maintained changelog and automated releases.
  • Publish the Nydia Vault Format v1 specification and reference test vectors, enabling independent interoperable implementations.
  • Publish SDK documentation — installation, a quickstart (initialize the vault, store and recover a credential), and a security model.
  • Validate the SDK in Nydia itself by depending on the published Maven artifact rather than local source code.

Milestone #7 (Due by 25 January 2027)

Implement QR-based cross-device authentication and ensure compatibility across Android 14–17 platform versions.

  • Implement QR-based cross-device passkey sign-in.
  • Comprehensive testing across Android 14–17 to ensure compatibility.
    • The first months will focus on Android 14 in daily development, but scheduled regression cycles will also run on 15-17 to watch for API changes, added features, or behavioral changes. If those newer releases surface platform-specific quirks, I’ll budget time within this milestone to address them so that Nydia remains feature-aligned across Android 14-17 without assuming breakage in advance.
  • Test websites and applications including QR sign-in scenarios, using the FIDO Alliance Passkeys Directory as reference.

Milestone #8 (Due by 25 February 2027)

Integrate the Sia Storage SDK into Nydia browser extensions for Chrome, Firefox and Safari.

  • Replace the renterd API with the @siafoundation/sia-storage SDK across the Chrome, Firefox, and Safari extensions, including WebAssembly asset packaging, WebTransport compatibility and availability checks, extension content security policies, and browser-specific background runtime handling.
  • Enable one 12-word BIP39 recovery phrase to independently derive Nydia’s passkey-encryption root key and the AppKey used to access the selected Sia indexer, providing a unified onboarding and recovery flow while keeping both keys and their security roles separate.
  • Adopt the same Nydia AppID across Chrome, Firefox, and Safari, and verify cross-client access to the same Nydia account from the same recovery phrase.
  • Implement WebAuthn Conditional Create support for seamless passkey creation after successful password-based sign-in.
  • Run AppKey registration in the extension’s background context so it can continue when the popup closes during indexer approval, and allow onboarding to recover from interrupted or failed approval flows without losing the initialized passkey-encryption root key.
  • Verify onboarding, indexer approval, backup, restore, cross-browser synchronization, and synchronization between the browser extensions and the Nydia Android app against both sia.storage and a self-hosted indexer.

High-level architecture overview and security best practices

Components:

  • Go Core layer: credential creation, assertion signing, COSE key encoding, and WebAuthn response serialization.

  • Kotlin Multiplatform Vault layer: a two-tier key model — BIP39 recovery phrase for deterministic root-key recovery, device-local Android Keystore for biometric day-to-day unlock — with private passkey material encrypted in Room.

  • Kotlin Application layer: Android UI, Credential Provider service integration, passkey request flows, and backup/restore orchestration.

  • Sia integration: Nydia uses the Sia Storage SDK across all clients — go.sia.tech/siastorage in the nydia-core SDK on Android and @siafoundation/sia-storage in the Chrome, Firefox, and Safari extensions — to upload encrypted backups, manage object metadata, and restore backed-up passkeys through the selected Sia indexer.

Security practices:

  • Passkeys are encrypted locally before being stored or backed up.

  • One BIP39 recovery phrase supports two independent key-derivation flows: Nydia
    deterministically derives the passkey-encryption root key, while the Sia Storage SDK derives a separate AppKey for access to the selected Sia indexer; the two keys remain isolated and are used only for their respective security roles.

  • Recovery on a new device requires the same BIP39 recovery phrase.

  • Android Keystore backs biometric unlock for day-to-day access.

  • Sensitive key material is cleared from memory after use where possible.

  • Backups contain only encrypted credential records and non-secret object metadata; Sia hosts and indexers never receive plaintext passkey material.

  • No third-party cryptography libraries: the Vault layer’s primitives are supplied by Android JCA, with Android Keystore protecting the root key, while the Go Core layer uses the Go standard library’s crypto for key generation and signing.

The Architecture in Action

Early development prototype (1:06): a passkey created on Android, encrypted locally, backed up through a Sia indexer, and restored in the browser extension with the same recovery phrase — then used to sign in on desktop. This is the happy path running against a local indexer — the grant covers turning it into a product: sync reconciliation, onboarding and biometrics, QR cross-device sign-in, and publishing the two SDKs.

Instead of a thousand words — here’s 42 seconds of what the passwordless future looks like. You create an account the old way, with a username and password, and Nydia quietly creates a passkey alongside it. That’s Conditional Create from the W3C WebAuthn Level 3 spec: no registration prompt, no extra clicks or a trip to account settings, and your next sign-in is passwordless — passkey-first, with no password to remember or type. Bringing this to all three extensions on the Sia Storage SDK is part of Milestone #8.

Behind terms such as WebAuthn, Conditional Create, SDKs, BIP39, and Ed25519 lies a straightforward idea: users should own their passkeys and carry them securely across platforms. This seven-minute explainer makes that idea tangible, showing what Nydia does, how Sia enables it, and what this grant will deliver. I hope plain-language video explainers become more common across grant proposals, helping anyone — not just specialists — understand the work being funded, share feedback, contribute ideas, and take part in the conversation.

Potential Risks

While Android 14+ allows third-party passkey managers to provide passkeys, certain OEM devices may lack support for this feature. This may result in limited availability of Nydia on some devices.

Supporting native Android applications via the Credential Manager API may require additional discovery, testing, and adaptation to app-specific behaviors (e.g., apps that integrate WebAuthn in nonstandard ways). If full implementation proves infeasible during the grant period, initial support will focus on browser-based use cases, with native app flows deferred to post-grant development.

Budget Justification

The project requests $60,000 to cover the developer fee over an 8-month research and development period. This budget reflects the substantial complexity of architecting and launching a robust credential provider service for the Android ecosystem with comprehensive passkey support. The scope deliberately goes beyond a single application: the budget covers the additional engineering required to ship reusable infrastructure — two SDKs (nydia-core, nydia-vault) delivered as documented, SemVer-versioned Maven artifacts, an open-source credential-provider scaffold, and a published storage-format specification with reference test vectors. This API-design, documentation, and compatibility work does not exist in an app-only scope, and it leaves the Sia ecosystem with building blocks that any future project storing user secrets on Sia can reuse.

Beyond the Grant

The Nydia Android app and all three browser extensions — Chrome, Firefox, and Safari — are targeted for their first public release in their respective stores in late Q1 or early Q2 2027.

Nydia has developed across several chapters, but the underlying direction has remained consistent: passkeys should be portable, recoverable, and controlled by their users.

The SDKs and the Nydia app itself are all open source under the MIT License and will remain so, with Sia continuing to provide the user-owned storage foundation connecting Nydia across platforms — the thread woven through every chapter, past and future :thread::sparkles:

Are you a resident of any jurisdiction on that list? Will your payment bank account be located in any jurisdiction on that list?

No to both questions.

Will all of your project’s code be open-source?

Yes.

Where will the code be accessible for review?

Do you agree to submit monthly progress reports?

Yes.

Contact info

Email: [email protected]
Discord: new0ne