Trait SignedMessage 

pub trait SignedMessage {
    // Required methods
    fn fetch_all_signature_headers(&self) -> Vec<String>;
    fn fetch_all_signature_inputs(&self) -> Vec<String>;
    fn lookup_component(&self, name: &CoveredComponent) -> Option<String>;
}

Trait that messages seeking verification should implement to facilitate looking up raw values from the underlying message.

Required Methods

fn fetch_all_signature_headers(&self) -> Vec<String>

Obtain every Signature header in the message. Despite the name, you can omit Signature that are known to be invalid ahead of time. However, each Signature- header should be unparsed and be a valid sfv::Item::Dictionary value. You should separately implement looking this up in lookup_component as an HTTP header with multiple values, although including these as signature components when signing is NOT recommended. During verification, invalid values (those that cannot be parsed as an sfv::Dictionary) will be skipped without raising an error.

fn fetch_all_signature_inputs(&self) -> Vec<String>

Obtain every Signature-Input header in the message. Despite the name, you can omit Signature-Input that are known to be invalid ahead of time. However, each Signature-Input header should be unparsed and be a valid sfv::Item::Dictionary value (meaning it should be encased in double quotes). You should separately implement looking this up in lookup_component as an HTTP header with multiple values, although including these as signature components when signing is NOT recommended. During verification, invalid values (those that cannot be parsed as an sfv::Dictionary) will be skipped will be skipped without raising an error.

fn lookup_component(&self, name: &CoveredComponent) -> Option<String>

Obtain the serialized value of a covered component. Implementations should respect any parameter values set on the covered component per the message signature spec. Component values that cannot be found must return None. CoveredComponent::HTTP fields are guaranteed to have lowercase ASCII names, so care should be taken to ensure HTTP field names in the message are checked in a case-insensitive way. HTTP fields with multiple values should be combined into a single string in the manner described in https://www.rfc-editor.org/rfc/rfc9421#name-http-fields.

Implementors