Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pthid vs thid - Out Of Band - Message Correlation #427

Open
FabioPinheiro opened this issue Jan 16, 2023 · 3 comments
Open

pthid vs thid - Out Of Band - Message Correlation #427

FabioPinheiro opened this issue Jan 16, 2023 · 3 comments

Comments

@FabioPinheiro
Copy link
Contributor

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 of thid 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 the id 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.

@swcurran
Copy link
Contributor

swcurran commented Jan 16, 2023

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.

@FabioPinheiro
Copy link
Contributor Author

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.

@FabioPinheiro
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants