Hello, this is the discussion topic for the AEX-2 Proposal:
so I have a couple of questions:
- How does this handle errors? e.g. when the handshake fails
- What does DH—I assume Diffie Hellman?— mean here? And how do a provider and sdk agree on which cryptographic primitives get used? Are they hardcoded? If so, please specify them
- The spec mentions a nonce. Are there any requirements for the nonce?
- For the callback url, what is the allowed format?
Also, it would be great to have at least a basic threat model section, because unless I’m misunderstanding something, the current model does not protect against MitM scenarios, among other things.
It is a stateless message exchange system and defining and handling errors is out of the scope. The spec should not define how an SDK or wallet implementation handles errors on non-receipt of messages or receipt of corrupted messages.
One of the solutions can be that the SDK and Wallet define a timeout to reinitiate the handshake but this should not be part of the spec.
That being said, we’re planning to put in place a
broadcastmethod so to inform the wallet that the message has been transferred/broadcasted to the network.
Yes, DH means Diffie Hellman and we’ll expand on that in the AEX.
We have proposed the use of box implementation from NaCl and it has the selected primitive
it is the nonce that will be used for encryption and is required for decryption.
Please refer to https://nacl.cr.yp.to/box.html
we have not exactly finalized the spec for this and all suggestions are welcome. For now, we are planning to keep it open and allow all URL/URI formats including any custom ones too.
Thanks for the suggestion on putting the threat model section. Will try to attach that to the document.
I wasn’t really concerned with the method of handling errors but how they can be communicated between wallet and sdk. There is a
ae:registrationComplete but no
ae:registrationFailed. Does that imply that everything will just be done via timeouts?