IC Auth

Independent application authentication protocol libraries for the Internet Computer, with a wallet-authentication service planned.

The implementation owns IC signature/proof contracts, portable credential admission and caller-bound local sessions. Canic consumes these libraries through host adapters; applications such as Toko retain account and resource policy. Wallet-backed identities and their service are planned, not current endpoints. No Auth library or future service may depend on either project.

Status

The latest local release is 0.9.1. It implements portable certified and enrolled Ed25519 verification, one local session engine, replay/revocation bookkeeping and explicit protected authority/work budgets. See the session contract and current handoff for implementation and validation.

The existing signature, delegation, signature preparation, certificate issuance and chain-key helpers remain reusable primitives. Application resource permissions and IC ingress delegation remain separate.

The private browser client supplies one portable admission coordinator, a durable logout journal, guarded SDK identity and HTTP logout transport. Its Rust-owned IC Wire contracts are in crates/ic-auth-wire/. The former token prepare/retrieve client and stores are retired: the maintainer confirmed no deployed old records or unresolved old issuance. New portable journals still preserve uncertainty. The separate Rust delegated-token API is also retired after explicit confirmation of no deployed users or unresolved issuance. Production issuer/enrollment and consumer integration remain pending; reference qualification is separate from adoption.

Production issuer/enrollment lifecycle, wallet login and the durable session adapter remain unimplemented. The reference receiver uses volatile state. The IC Testkit fixture exercises actual certification, portable sessions, upgrades and signed ingress; it is not a production wallet service or evidence of completed consumer adoption. The unpublished native utility in apps/tooling/ delegates file operations to IC Host and package-lock subset admission to IC Build; release identity and publication/retry policy remain here.

Canic is adopting the shared libraries; its complete runtime verifier and durable host integration remain consumer work. The Canic adoption contract maps the published libraries to its feature, authority, storage and certification boundaries; implementation and acceptance belong in Canic #491.

• Architecture and ownership
• Current handoff
• Developer setup and commands
• Portable browser client and consumer boundary
• Minimum Rust compiler and package qualification
• Shared maintenance task catalog
• Canic source review and incorporation boundary
• Extraction and Canic adoption tracker
• Agent instructions

Application authentication

The accepted application flow is portable proof admission → caller-bound local session → scoped session checks. Each receiving canister admits the credential under its protected fleet, role and scope policy. Ordinary application calls use the authenticated ingress caller and the local session; they do not carry a token. Portable credential verification and atomic admission share one session engine. Application resource permissions and IC ingress signatures remain distinct.

This is the coordinated portable consumer contract, not a claim that Canic/Toko have completed the cut. Their guards, Wire endpoints and frontend calls must change together under the adoption contract.

Workspace

Cargo.toml                     # Virtual workspace and dependency catalog
Cargo.lock                     # One selected Rust dependency graph
crates/
  ic-auth-protocol-types/      # Passive auth contracts and validated identifiers
  ic-auth-wire/                # Bounded transport and generated browser codecs
  ic-auth/                     # Encoding, proof verification and session machinery
apps/
  tooling/                     # Unpublished native release/publication file utility
  qualification/               # Internal Wasm host and IC Testkit/IC-agent tests
packages/
  client/                      # Private browser lifecycle client and generated contracts

The types package is ic-auth-protocol-types (Rust import ic_auth_protocol_types). The unrelated ic_auth_types package belongs to another IC-Auth project and does not implement our application token/proof contracts. Crates.io treats hyphens and underscores as colliding names, so changing only the punctuation cannot resolve that conflict.

The public domain types use IC Platform 0.6's owned Principal through its explicit principal feature, with byte-preserving conversions at external Agent/Testkit/crypto boundaries. Public library capabilities and the reference Wasm exclude Candid; native Agent/Testkit retain their required Candid dependencies. Platform supplies signature creation/verification and the Candid-free runtime; Auth retains admission limits, protected authority and session policy. See the Platform migration and dependency boundary.

Application endpoints, generated TypeScript, private fixture controls and upgrade checkpoints use bounded IC Wire 0.5 contracts. The unpublished Candid checkpoint format is retired. Signed bytes, Wire frames and retained records keep their formats; no implicit browser or production storage reset is permitted. See the consumer transport contract.

The future wallet service belongs in apps/wallet-auth/. No accepting wallet endpoint is created before its complete proof verification and service contracts.

With the declared tools prepared, run the focused checks:

make test-types
make test-protocol
make test-chain-key-signatures
make test-signatures
make test-signature-store
make test-certified-proofs
make test-sessions
make test-qualification
make check-wasm

Planned wallet authentication uses custom Solana/Ethereum login challenges without SIWS or SIWE, with established signature primitives and wallet message signing. Wallet adapters remain unimplemented; see the wallet design. NFTs remain in their application's ledger. This service does not mint, index, bridge or custody wallet assets.

Canic integration uses local library calls. It must not add a remote authentication request to every protected application call.

Ownership and dependencies

Signed claims, bounded transport and checked stored records serve different trust boundaries; their independent validation is intentional. Production wallet/issuer and durable host acceptance remain explicit unfinished work, not alternative authentication flows. The current handoff separates current evidence from historical extraction notes.