Skip to content

wasmtime host: Rust-held keys as typed handles — native parity for the #392 seams #395

Description

@lannbot

#392's parity note anticipated this: "a wasmtime embedder can grow the analogous host API (Rust-held key → handle)". The consumer now exists and is blocked on it.

Consumer: polyvisor's engine-host (wasmtime) filling the engine world's app-owned device-identity import (device-key-pair: async func() -> option<tuple<signing-key, verifying-key>> — the #391 shape). The browser embedder implements it over SigningKey.fromCryptoKey/VerifyingKey.fromCryptoKey; the wasmtime host has no analogue, so its fill is none and two native acts (platform-posture resume with a granted identity; the wrong-key mismatch refusal) are recorded BLOCKED in polyvisor's battery.

The gap, precisely (polymorph-webcrypto-wasmtime 0.1.0 @ b13d252): the backing SigningKey/VerifyingKey types are public but their payload fields are pub(crate) (the minted_resources! macro, lib.rs:476-491); the only constructor is the pub(crate) Minted trait whose minted() takes a pub(crate) limits::Reservation; and no import-from-Rust entry point exists in host.rs. Nothing lets an embedder that already holds key material (e.g. an ed25519 key file) place it in the resource table as a typed handle.

Ask: the #392 contract points, relocated — per-kind constructors on the wasmtime host (SigningKey::from_material(...) / from_signing_key(ed25519_dalek::SigningKey) or equivalent), kind validated at the wrap, policy reported by the existing getters, same table as minted keys. Ed25519 signing/verifying first; derivation kinds on demand, mirroring the browser seam's v1 scope.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions