AnteHandler

D-Chain and other apps the use this AnteHandler decoration can specify fine grain verifiable presentation requirements for each of the different messages in the transaction. Each of the verifiable presentations will be verified before the messages are processed by the app.

For example, a message with type URL as /d.notary.MsgNotarise and certain fields in the message might have a requirement of for a SD-JWT presentation with a disclose attribute equal to the document hash; derived from a credential issued by a set of trusted issuer. This requirement would have been set in the VerificationRoutesRegistry (see state). The AnteHandler decorator will route the presentation to the SD-JWT verifier contract, load the correct Route for this message type and verify the presentation.

ing different smart contract address as part of MsgNotorise value.

AnteHandler verifying ExtensionOptions

The AnteHandler function (impl of AnteDecorator) interface is implemented for the x/vcv keeper wrapped in the a struct defined as VcvExtensionOptionDecorator.

VcvExtensionOptionDecorator is used to extract the ExtensionOptions from the transaction which is expected to match the message verification requirement of the same index in the TxBody.Messages. If no prsentation verification is required for a message, the corresponding ExtensionOptions index should be an empty string.

TxBody {
    Messages[Msg1, Msg2, Msg3]
    ExtensionOptions[Pres1, "", Pres3]
}

Msg2 does not require a presentation to be verified, so the ExtensionOptions index is an empty string.

This ExtensionOptions value must be in the message format defined by the typeUrl - /d.vcv.v1.VerifiablePresentation.

type VerifiablePresentation struct {
 Presentation []byte `protobuf:"bytes,1,opt,name=presentation,proto3" json:"presentation,omitempty"`
}

Implementation into app

This provides the ExtensionOptions AnteHandler can then be added to the app. In the case of D-Chain, See app/ante.go