AEX-3: what does secret_type mean?

[davidyuk]

Its current value ed25519 is ambiguous, for example, it can be just a private key, or a key that is for the derivation of child account that will use the same curve for signing. Is it correct to use AEX-3 for arbitrary data or it should be somehow related to user accounts?

[shekhar-shubhendu]

@davidyuk the first part is not very clear as I don't know how base app generates child accounts. can you please expand on this?
AEX-3 allows arbitrary data and recommends that it should be user related but it can not enforce the type of data the wallet can store.

[davidyuk]

Here is my implementation of account derivation in Base app: https://github.com/aeternity/hd-wallet-js/blob/master/src/hd-wallet.js
And some explanations: aeternity/aepp-sdk-js#41 (comment)

If secret_type doesn't have any strict meaning, let's drop it for now.

[shekhar-shubhendu]

@knarz will be able to provide more information on this since he is the original author here.

[knarz]

Right now I imagine the secret_type to be taken quite literally in the sense that it is a private key, which should be used to generate signatures according to ed25519.
I'd rather include more types and keep the field around s.t. the files can be self-contained.
Otherwise we either specify that a version field with value 1 should indicate to a reader that it contains above key material or we add more types to the spec. What would you suggest?

[davidyuk]

I think AEX-3 becomes more useful if we get rid of the ambiguity of secret_type field by adding more types like:

• ed25519-bip39-mnemonic, or just mnemonic?
• ed25519-slip0010-masterkey
• aex*-account -- a key that can be used to derive subaccounts
• aex*-keypair -- derived key

where aex* is a standard explaining account derivation. Also, it is important to define the payload layout for all types to get consistent implementations.

[knarz]

Addressed in b762e6d, please re-open if that doesn't solve the problem