id/ field for OTR fingerprints

[domob]

Since I'm working right now on verifying OTR fingerprints with Namecoin identities (see https://dot-bit.org/forum/viewtopic.php?f=2&t=1045), I'd like to discuss my proposal for how to associate OTR fingerprints with identities. Ideally when a consensus is reached this could be added to the Wiki page about the id/ namespace. My suggestion is simple: Fingerprints can be stored as either a single string value or an array of strings in the "otr" field of an identity's value. (I think it makes sense to allow multiple keys, because for instance I currently have at least two (one for my desktop PC and one for my mobile app), and AFAIK the Pidgin OTR plugin generates separate keys for each protocol / account you have, although multiple accounts (XMPP, IRC, ICQ, ...) may belong all to just one online identity of you.) The fingerprint is just a string of hex digits, case insensitive and spaces may be added (which are stripped from it before it is interpreted) arbitrarily to make it more readable or to allow for copy&paste from applications that display with spaces added (like Pidgin).

For instance, see "id/otr":

Code: Select all

{"otr":"D2A5E5E0704A117D0B43C7FC0caee72C8FE85CA9"}

or "id/cryptonerd":

Code: Select all

{"otr":["D2A5E5E0704A117D0B43C7FC0caee72C8FE85CA9", ""]}

The second string is there to test my code and should just be ignored. Also valid would be (again for the same fingerprint):

Code: Select all

{"otr":"D2A5E5E0 704A117D 0B 4 3C7F C 0caee72C 8FE85CA9"}

I'd even suggest to allow for arbitrary values in the array and just ignore everything that's not a properly formed string. This allows for future extensions in case it would be required and doesn't hurt. What are your thoughts?

[biolizard89]

This looks good to me at first glance.

[phelix]

Maybe we can make it similar to the "signer" field.

Why the spaces? I mean why not always store it without spaces?

[domob]

Maybe we can make it similar to the "signer" field.

Acutally it is already, isn't it? Or do you have suggestions on what I should change? But as I see it, the specification for both ones is basically the same at the moment.

Why the spaces? I mean why not always store it without spaces?

Well, the "real" reason is that in my code I strip the spaces away anyway before comparing fingerprints because the routine I use to get my contact's fingerprint from libotr adds spaces (it is the same that is used to display the fingerprint in a "human readable" way). I think it doesn't hurt to allow them (optionally!), which makes it for instance easier for someone to just copy&paste their own displayed fingerprint from Pidgin. Of course it is trivial to strip the spaces before saving the value if you use a UI (or to add spaces when displaying fingerprints), so I also don't mind if we "forbid" spaces in the values.

[phelix]

Maybe we can make it similar to the "signer" field.

Acutally it is already, isn't it? Or do you have suggestions on what I should change? But as I see it, the specification for both ones is basically the same at the moment.

yeah, I should have said: Nice, it is similar to the "signer" field. Keep it like that.

Why the spaces? I mean why not always store it without spaces?

Well, the "real" reason is that in my code I strip the spaces away anyway before comparing fingerprints because the routine I use to get my contact's fingerprint from libotr adds spaces (it is the same that is used to display the fingerprint in a "human readable" way). I think it doesn't hurt to allow them (optionally!), which makes it for instance easier for someone to just copy&paste their own displayed fingerprint from Pidgin. Of course it is trivial to strip the spaces before saving the value if you use a UI (or to add spaces when displaying fingerprints), so I also don't mind if we "forbid" spaces in the values.[/quote]
Random spaces seem odd to me... but I do not understand the issue enough to have a strong opinion.