Trait HostWithStore 

pub trait HostWithStore<T>:
    HasData
    + HostIkmWithStore<T>
    + Send {
    // Required methods
    fn import_ikm(
        accessor: &Accessor<T, Self>,
        raw: Vec<u8>,
        options: Resource<DeriveOptions>,
    ) -> impl Future<Output = Result<Result<Resource<Ikm>, Error>>> + Send;
    fn unwrap_ikm(
        accessor: &Accessor<T, Self>,
        input: Resource<UnwrapInput>,
        options: Resource<DeriveOptions>,
    ) -> impl Future<Output = Result<Result<Resource<Ikm>, Error>>> + Send;
}

Required Methods

fn import_ikm( accessor: &Accessor<T, Self>, raw: Vec<u8>, options: Resource<DeriveOptions>, ) -> impl Future<Output = Result<Result<Resource<Ikm>, Error>>> + Send

Import input keying material. Empty material is accepted (RFC 5869 permits it, and the Web Cryptography API serves it), but an implementation enforcing a security policy MAY reject degenerate material with error.invalid-key, as on hmac-sha2.import-key-raw. Fails error.not-permitted if options grants nothing, per the package-wide options contract.

fn unwrap_ikm( accessor: &Accessor<T, Self>, input: Resource<UnwrapInput>, options: Resource<DeriveOptions>, ) -> impl Future<Output = Result<Result<Resource<Ikm>, Error>>> + Send

Mint input keying material from unwrapped bytes (see the wrapping interface), subject to import-ikm’s contract: a KDF secret can arrive under a wrapping key and parameterize derivations without its bytes ever being observable. Like import-ikm, this is not a format choice — the bytes are the material. input is consumed.

The grants come from options alone (the W3C Web Cryptography API’s unwrapKey model; its forced non-extractability on HKDF base keys is structural here, as on import-ikm).

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.

Implementors

impl<T: Send> HostWithStore<T> for WasiWebcrypto