When implementing AEX-3 I noticed a couple of things that could be clarified or described in more detail.
Some fields, like kdf-salt, cipher-nonce, and the ciphertext should have a format specification. I would suggest hexadecimal string, but base64, etc. are other alternatives. (And if you really, really want add a format argument and make it configurable - but this just adds complexity in my eyes.)
The secret type ed25519-slip0010-masterkey is a bit of a mystery, there is no format specified in SLIP0010, you could perhaps go with the BIP0032 extended key-format, but then make it specific.
For the secret type ed25519-bip39-mnemonic string is probably the natural format, but again a hint (and an example?) would help implementers.
Or, perhaps just specify further what are allowed values of secret_format (string, raw bytes, base64, hexstring, etc?!)
Also it would be nice with some test vectors - once the above issues are settled/discussed I should be able to provide a bunch of good an bad examples.
When implementing AEX-3 I noticed a couple of things that could be clarified or described in more detail.
salt, cipher-nonce, and theciphertextshould have a format specification. I would suggest hexadecimal string, but base64, etc. are other alternatives. (And if you really, really want add a format argument and make it configurable - but this just adds complexity in my eyes.)ed25519-slip0010-masterkeyis a bit of a mystery, there is no format specified in SLIP0010, you could perhaps go with the BIP0032 extended key-format, but then make it specific.ed25519-bip39-mnemonicstring is probably the natural format, but again a hint (and an example?) would help implementers.secret_format(string,raw bytes,base64,hexstring, etc?!)Also it would be nice with some
test vectors- once the above issues are settled/discussed I should be able to provide a bunch of good an bad examples.aeternity/eaex3