didcomm-messaging
didcomm-messaging copied to clipboard
pthid vs thid - Out Of Band - Message Correlation
In 9.5.3 Message Correlation we read: "The id of the message passed in a URL or a QR code is used as the pthid on a response sent by the recipient of this message. The response recipient can use the pthid to correlate it with the original message."
- Can someone explain why we need to use the
pthid
instead ofthid
when reply to messages that are passed in a QRcode? - Is this a requirement for Out Of Band Messages or for the Transports layer?
The way that is described seems we change the behavior depending on the transportation layer.
Also this explanation below in the specs (that is almost hidden):
This may feel counter-intuitive — why not it in the thid
of the response instead? The answer is that putting it in pthid enables multiple, independent interactions (threads) to be triggered from a single out-of-band invitation.
Yes this is counter-intuitive and why do we think the out-of-band is not dedicated to a single recipient just because it doesn't specify the exact recipient?
How does the pthid enables multiple independent interactions
? What is the problem of replying using thid
?
With this description, I almost wanted to try to give some sort of attack just by knowing the thid
of any interaction.
An Out Of Band Message is just a message without a specific recipient (where the field to
is not defined). right?
The way pthid
and thid
is presented seems that I will use pthid
when starting a new protocol in the middle of the other one.
Example:
- If I define a protocol to login. Where we are pretty much doing an invitation and I expect a reply. Will be just one protocol with two types of messages. So we use
thid
in the reply. It doesn't matter If the invitation is an OOB message or not! - If I do the invitation without a specific recipient (OOB) is send via QRcode or NFC, I still expect the message to be a reply (using
thid
)] - If before login I also require a payment I then can use a payment protocol. Using the
pthid
with the id of the reply. - If the invitation expired then I can use a report error protocol using the
pthid
with theid
of the invitation oob message.
I think @rodolfomiranda also agrees that thid
should be used instead and this point is probably coming from legacy from OOB 1.1.
The use of pthid
in that context in Out of Band (OOB) for DIDComm V1 is because OOB is the parent protocol of whatever protocol is to be executed following the invitation. Further, if the OOB invitation is shared with many agents (a multi-use invitation), it is useful (necessary, I think) to have both an identifier for the invitation (the pthid
) and an identifier for the specific use of the invitation (the thid
). If you use the invitation identifier as the thid
, you have many protocols executing with the same thid
, which is a problem.
I'm less familiar with DIDComm V2, but I believe the same things are required and the same reasoning applies.
But my point is that Out of Band (OOB) is not a protocol. Is just a message without a specific recipient. On 9.5.3 Message Correlation is are only talking about Out of Band Messages
The problem is not technical only semantics you can (and you need either way) always distinguish the message from each DID.
In my point of view the invitation protocol (that I see as any other protocol). This is where we could maybe specify where to use pthid
instead of thid
.
But even so, I would argue against that.
- From the point of view of the who are you inviting use are executing the protocol only once! Since communication is one to many.
- You cannot say that you are executing the protocol many times because you were just creating ONE invitation. In MPV each execution of one protocol should be independent of the other one. And you should not need knowledge about the other executions. (In this case, you need to know about the ID of the invitation message)
- This feels like two different protocols one that gives some information to everyone and another one that builds on that message. Which I believe is also a valid scenario. Maybe you don't need a prior invitation before calling some service.
This was also discussed on the DIF DIDComm user Grupo (min 11) https://us02web.zoom.us/rec/share/oZ0gVJRXV9HOSV72jw75Q8xRYjFOYmuKQGiO23Npti8XYXZWaomOyr7FyHI7aAFC.LztoqpeUWUb7aFC5
So I think we need to better specify where to use pthid
instead of thid
.
Because the way that is described seems we change the behavior depending on the transportation layer.
So in conclusion from the call:
The pthid
needs to be used when replying to a OOB (an message where the field to
is not defined). Regardless of the protocol used.
However, I'm still of the opinion the protocol should define this.
But at this point I just wanted the specification to be a bit more clear around this.