Introduction

NFID is a set of smart contracts on the Internet Computer where users create identities and store GBs of tamper-resistant, encrypted data. The current phase of development is to make self-sovereign private key management feel like a web2 experience. NFID achieves this with the Internet Computer's smart contracts and cryptographic primitives, allowing the generation of powerful, self-sovereign delegation identities that can make authenticated smart contract calls without user approval prompts and encrypt/decrypt their own data.

The NFID protocol currently allows users to:

• Manage private keys and their assets on ICP (Internet Computer Protocol)
• Sign in using an email address or one out of a set of passkeys (when 2FA is enabled)
• Authenticate to client (3rd party) applications

Functional Requirements

• Users have one identifier for each supported network, with the option to extend with app and stealth addresses
• These identities are stable (i.e., do not depend on the email or passkey from which the user authenticated)
• Users do not need to remember secret information
• Clients can use the user's identity (client delegation) to interact with their own smart contracts (canisters), look up balances, and are otherwise enforced to request user approval
• Each client delegation has a session duration during which it can make authenticated calls
• Non-ICP clients (i.e., EVM dapps) can use the user's identity (provider) to look up balances and request signatures

Security Requirements

• Email addresses are private to users, never to be exposed without user consent
• Client delegations handed out to client applications by NFID must be targeted with the frontend application's canisters only
• Private keys cannot be reconstructed without user authentication
• Users cannot authenticate without a passkey if 2FA is enabled, and otherwise without a Google token or opening a magic link

Security Assumptions

• The delivery of frontend applications is secure. In particular, a user accessing NFID through a TLS-secured HTTP connection cannot be tricked into running another web application.
• Passkeys are trustworthy
• The user's browser is trustworthy

The NFID Identity (NFIDentity)

• A user account is identified by a unique NFIDentity, a natural number chosen by the smart contract.

• A user has one address for each network (same across EVM).

• When a user authenticates to non-ICP network applications, the returned identity is a provider.

• When a user authenticates to ICP network applications, the returned identity is a self-authenticating id (opens in a new tab) of the DER encoded canister signature public key (opens in a new tab) which has the form:

  user_id = SHA-224(DER encoded public key) · 0x02` (29 bytes)

See more detailed information on public key encoding and signatures.

The NFID Identity Manager smart contract stores a set of device information in user accounts, indexed by the respective NFIDentity, consisting of:

• the device's public key (DER-encoded)
• a device alias, matched by AAGUID (Authenticator Attestation Global Unique Identifier) and editable by the user, to recognize the device
• an optional credential ID, which is necessary for WebAuthn authentication

NFID User Flow with Your Application

Users authenticate using email (or FIDO-based device biometrics for returning users with 2FA enabled).

1. User initiates login on your site.
2. User authenticates to their NFID and provides a network address (or delegation identity in the case of ICP)
3. When your application requests a signature, the NFID iframe reappears for user approval.

The Node Network

As of January 2024, the base protocol consists of 559 (live) nodes (opens in a new tab) run by 119 (live) node providers (opens in a new tab) across 105 (live) geographically distributed data centers (opens in a new tab).