Thread id when Issue Credential protocol is started by Offer Credential

[genaris]

trafficstars

I've seen that when processing Offer Credential messages, CredentialService creates a CredentialRecord whose threadId is set to Offer Credential message's id. This is usually fine because the flow starts with that message, so threadId = id. However, that's not true when Issue Credential is started as a sub-protocol and therefore all messages include the ~thread decorator.

So I think all Credential Records should be created with originating message's threadId. That is actually the case when creating a CredentialRecord when processing Credential Proposal message.

[TimoGlastra]

If I understand correctly, when starting issue credential as a sub-protocol, the threadId of the super protocol should be set as the phtid. The thid is reserved for the issue credential flow, which if starting with the offer as a sub-protocol, is the id of the offer message.

Do you have a different interpretation of this functionality? If so, could you point me to some of the docs?

[genaris]

I agree with you about the usage of pthid for sub-protocols. Maybe my issue was a bit 'nitpicking' because in other cases, such as createProposal method, we are indeed setting threadId to proposalMessage.threadId. Isn't conceptually the same case? In ACA-PY I see something similar.

I actually raised this because it would make easier for me (with some hacking around) to relate an Issue Credential flow with another before we fully support sub-protocols, which I think it would need some more effort. But anyway, probably it's worth to tackle it as it deserves and think the changes needed to start protocols with a parent thread and being able to filter out events by their parent thread as well.

[andrewwhitehead]

I believe AFJ should always use the thid. DIDComm specifies that thid = @id when not provided.

The flow where I ran into this:

• The sender (issuer) creates a thread ID to represent the credential exchange, prior to any connection being established
• After the connection is formed, it sends a CredentialOffer. It uses the (locally) established thread ID but a new message ID, because the CredentialOffer might need to be repeated with a new message ID, but the same thread ID.
• AFJ sends a CredentialRequest using the message ID as the thid, which cannot be associated with the credential exchange.

[TimoGlastra]

You were right all along @genaris, I couldn't see it at the moment. Should be fixed in #1311

Found the issue here: https://github.com/hyperledger/aries-framework-javascript/pull/1311/files#r1110228962