The usage of the `CommunicationInfo` structure

[zanctor]

If I understand it correctly, the key-value pairs in this structure should be used to identify/authorize a party during the pairing sequence. This may work for string values, but the buffer values may be anything, and a party, that authorizes the request, would not even know what to do with that buffer.

It would make more sense if it contained a strict set of string fields like name, contact (for communication outside of the protocol), and, probably, some auth token for third-party KYC.

[zanctor]

This issue also partially describes a more global topic of peer/person identification. For instance, there is no way for a helper to know, which secrets belong to which sharer/person during recovery. To make it work for us, we will use custom blade-prefixed fields in this structure to send an auth token and other information, so a helper can retrieve some kind of identifier for this person, which will stay the same no matter how many pairings this peer will make.

[lbaird]

The purpose of CommunicationInfo is just to allow any form of human-readable info that might be helpful to display. It isn't intended to be needed for authentication, since authentication is done outside the protocol.

After I authenticate you, then I'll give you the information that's listed in ContactMessage, including the nonce. Then, when you send me a pairing message to initiate the protocol, you'll include that nonce, and I'll know that I'm receiving the pairing message from the same person I authenticated.

If the authentication was done by you giving me an auth token, then I'll store that auth token, and remember that it is associated with the nonce I gave you. So when I receive your pairing message, I'll be able to look up the nonce I stored, and I'll know that you are the person who gave me that nonce.

[zanctor]

Authentication is done outside of the protocol indeed, but we need the result of this authentication/identification to be able to tell, which secrets belong to this sharer. Since the nonce during recovery is different from the initial pairing, it won't help a helper to connect the sharer with their old secrets correctly at all.

In my opinion, that authentication should return some kind of identifier, which will stay the same for this person "forever". So if a sharer loses their device, and they try pairing with a helper in recovery mode, this helper will authorize this person again, and they should get the same identifier, which enables getting old stored secrets.

[lbaird]

Each time they pair with a new secret, the helper must authenticate the sharer. That happens before the contact is sent, and before the first pairing message is sent.

During that authentication, the helper must check whether this is the same person that has paired earlier with any earlier secrets.

How the authentication is done will be outside the protocol. And how the helper recognizes that it’s the same person will be done outside the protocol.

How do you plan to do the authentication? I would guess that it’s some form of KYC including pictures of a drivers license or passport. If that’s true, then the name and other identifying information will be sent during the authentication. And it can be used to see if that person has ever authenticated in the past.

All of that is outside the protocol, and happens before the contact and pairing.

I’m happy to have a call, if that would help.