IC Auth
Independent application authentication protocol libraries for the Internet Computer, with a wallet-authentication service planned.
The accepted scope includes IC signatures, application tokens, local application sessions and wallet-backed IC identities. Canic will consume the libraries; applications such as Toko will integrate through a documented client/service contract. The libraries and reference service must not depend on either project.
Status
The Rust workspace implements passive token/proof contracts, validated protocol
identifiers, canonical signed encoding, optional IC signature/application-token
verification and atomic session/replay admission extracted from Canic. Both
libraries are published on crates.io at 0.1.5; see the
signature, token and
session contracts. Durable canister adoption remains pending.
The working tree adds bounded signature preparation and retrieval
with explicit host certification composition, for pending 0.1.6.
Wallet login remains unimplemented. Tokens and local sessions do not grant
application resource ownership. The native utility in apps/tooling/ is unpublished and reuses
ic-host-fs/ic-host-artifacts for release and publication file operations.
Canic still runs its existing implementation. Its adapter adoption and removal of superseded code require a separately authorized Canic change.
- Architecture and ownership
- Current handoff
- Developer setup and commands
- Canic source review and incorporation boundary
- Extraction and Canic adoption tracker
- Agent instructions
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/ # Encoding and optional signature/token/session machinery
apps/
tooling/ # Unpublished native release/publication file utility
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.
Future service and client packages belong in apps/wallet-auth/ and
packages/client/. They are not created as empty or accepting placeholders.
With the declared tools prepared, run the focused checks:
Planned wallet authentication targets Solana message signing without SIWS or
ic-siws. NFTs remain in their application's ledger. This service does not mint,
index, bridge or custody Solana assets.
Canic integration uses local library calls. It must not add a remote authentication request to every protected application call.