ic-auth-protocol-types 0.1.2

Passive application authentication protocol contracts
Documentation

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 and canonical signed encoding extracted from Canic. It does not yet verify tokens, admit sessions or provide wallet login. Hashing a token is not authentication. Both packages are unpublished; their manifests and the guarded publication command now support crates.io delivery of these implemented APIs.

Canic still runs its existing implementation. Its adapter adoption and removal of superseded code require a separately authorized Canic change.

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/                     # Canonical token, certificate and proof encoding

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:

make test-types
make test-protocol
make check-wasm

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.