pub trait CardTransaction {
    fn transmit(
        &mut self,
        cmd: &[u8],
        buf_size: usize
    ) -> Result<Vec<u8>, Error>; fn init_card_caps(&mut self, caps: CardCaps); fn card_caps(&self) -> Option<&CardCaps>; fn feature_pinpad_verify(&self) -> bool; fn feature_pinpad_modify(&self) -> bool; fn pinpad_verify(&mut self, pin: PinType) -> Result<Vec<u8>, Error>; fn pinpad_modify(&mut self, pin: PinType) -> Result<Vec<u8>, Error>; fn max_cmd_len(&self) -> Option<usize> { ... } fn select(&mut self) -> Result<Vec<u8>, Error> { ... } fn application_related_data(
        &mut self
    ) -> Result<ApplicationRelatedData, Error> { ... } fn initialize(&mut self) -> Result<(), Error> { ... } }
Expand description

The CardTransaction trait defines communication with an OpenPGP card via a backend implementation (e.g. the pcsc backend in the crate openpgp-card-pcsc), after opening a transaction from a CardBackend.

Required Methods

Transmit the command data in cmd to the card.

buf_size is a hint to the backend (the backend may ignore it) indicating the expected maximum response size.

Set the card capabilities in the CardTransaction.

Setting these capabilities is typically part of a bootstrapping process: the information about the card’s capabilities is typically requested from the card using the same CardTransaction instance, before the card’s capabilities have been initialized.

Request the card’s capabilities

(apdu serialization makes use of this information, e.g. to determine if extended length can be used)

Does the reader support FEATURE_VERIFY_PIN_DIRECT?

Does the reader support FEATURE_MODIFY_PIN_DIRECT?

Verify the PIN id via the reader pinpad

Modify the PIN id via the reader pinpad

Provided Methods

If a CardTransaction implementation introduces an additional, backend-specific limit for maximum number of bytes per command, this fn can indicate that limit by returning Some(max_cmd_len).

Select the OpenPGP card application

Get the “application related data” from the card.

(This data should probably be cached in a higher layer. Some parts of it are needed regularly, and it does not usually change during normal use of a card.)

Get a CardApp based on a CardTransaction.

It is expected that SELECT has already been performed on the card beforehand.

This fn initializes the CardCaps by requesting application_related_data from the card, and setting the capabilities accordingly.

Trait Implementations

The resulting type after dereferencing.

Dereferences the value.

Mutably dereferences the value.

Implementations on Foreign Types

Implementors