Handling of a DIDComm message containing a JWT

[frazur]

Hi everyone,
I'm using the Veramo message handling pipeline to receive incoming messages on a wallet-like app.
Perhaps the complete functioning of the message handling mechanism is not clear to me.
Some handlers (such as the JWT handler) pass the message forward in the pipeline, after it is handled or if they fail.
Others (such as w3c credential handler) return the message to the caller when it has been handled, while the message is pipelined if they cannot handle it.
I would have expected the DIDComm handler to behave like the JWT because a DIDcomm message is basically an envelope, which contains an extra message inside. Instead, it behaves as in the second case. What happens then, is that when the DIDComm message contains a JWT inside it, I have to explicitly call the handle() again in order for it to be validated by the JWT handler. Also, I have to specify that the new message.raw is the previous returned message.data (where the didcomm handler puts the unpacked msg).

something like this:

function acceptDIDComm(req: Request, res: Response) {
....//ask the agent to handle the did-comm message
....myAgent.handleMessage({ raw: JSON.stringify(req.body), save: true })
.........then(async msg => {
............let vcCheck: VerifiableCredential = msg.data as VerifiableCredential
............if (vcCheck['@context'])
................await handleVC(msg, res)
............else { //here ask the agent to handle the JWT inside
................myAgent.handleMessage({ raw: msg.data.toString() }).then(jwtmsg => {
....................logger.info(jwtmsg)
....................handleSDR(jwtmsg, res)
................})
............}
........}).catch(validationError => {
............logger.err(validationError)
........})
}

What am I doing wrong? What am I missing in understanding the whole mechanism? :)

Thanks in advance

[mirceanis]

Thank you for raising this!

I don't think you are doing something wrong. Our message handling API needs to be reworked.
The two types of MessageHandler that you very well spotted need to be separated into different plugins, as this messageHandler chain architecture we have now is quite inflexible and confusing.

A possible new architecture is this:
One plugin should be just pass-through handlers which should only do some heuristic work to convert a blob of bytes into something with a type. Then, based on this type, validators and protocol handlers can pick it up and interpret the message.
Of course, this is just an idea, and other constructions are also possible.
Please share if you think something else makes more sense.

[frazur]

Thanks for the reply @mirceanis !
Well, the good news is that I understood the mechanism, the bad news is that I understood the mechanism :D
The solution you propose makes sense, definitely.

The next question is: do you have any idea when this architecture change might take place? Even just an order of magnitude: months, years?
(Unfortunately for what you write I guess there is no work in progress yet, right?)

And last, do you think the behavior of the didcomm handler as it is now (that is, returning the message without putting it back in the pipeline) could be considered a bug?

[mirceanis]

You are right, it's not in progress at the moment.
We're aiming for months, not years to change the design.

It's debatable whether or not it's a bug.
The thing is, if the contents of the message are not handled by a terminal MessageHandler (by returning a Message object), then there is no way to to actually get your message contents.
It would just pass through the handler pipe and fall out into "Unsupported message type" at the other end.

In your case, since the contents are a credential or SDR, it would get handled, but for other protocols it would just throw an unhelpful error.

The bootleg didcommv1 handler that we had before was actually a pass-through handler that would just unpack the message and forward it.

I wouldn't object to changing it so if you're looking for something fun to do, feel free to drop us a PR ;)

[frazur]

Thanks for your time @mirceanis,
if I had to find a shareable solution, I will definitely ask you for a PR :)