pub struct ImportKeyBody {
pub key_type: KeyType,
pub private_key_sealed: Option<String>,
pub private_key_jwe: Option<String>,
pub private_key_multibase: Option<String>,
pub label: Option<String>,
pub context_id: Option<String>,
}Expand description
Request payload for canonical keys/import/0.1.
Exactly one carrier member conveys the key. The choice between them is a
confidentiality decision, not a formatting one: private_key_sealed
and private_key_jwe encrypt the material to the VTA, so it is opaque to
every intermediary and to the transport itself, while
private_key_multibase is cleartext and safe only where the transport is
end-to-end confidential.
The trust-task dispatcher refuses the cleartext carrier outright, because
one dispatcher serves REST, DIDComm and TSP and cannot tell which one carried
a given request. The legacy key-management/1.0/import-key DIDComm message
still accepts it, where authcrypt has already established that guarantee.
Fields§
§key_type: KeyType§private_key_sealed: Option<String>Armored sealed-transfer bundle carrying the private key, encrypted to the VTA. The carrier to prefer.
private_key_jwe: Option<String>JWE compact serialization of the private key, encrypted to the VTA.
private_key_multibase: Option<String>Raw multibase-encoded private key — cleartext. Refused by the trust-task dispatcher; see the type’s documentation.
label: Option<String>§context_id: Option<String>Trait Implementations§
Source§impl Clone for ImportKeyBody
impl Clone for ImportKeyBody
Source§fn clone(&self) -> ImportKeyBody
fn clone(&self) -> ImportKeyBody
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more