Sign transaction API

[devbugging]

The current SDK API for signing exposes two methods: SignPayload and SignEnvelope which must be used in correct order to produce a valid signature, although these methods are valuable for advance usage I believe a simpler method Sign could be added to hide "implementation details" of signing a transaction which could be quite complex for new adopters.

Proposed API addition:

func Sign(signers []Signer) error

Based on the transaction parameters (authorizers, proposer, payer) the method can figure out how to sign the payload and the envelope. Signers array should contain a key index and address along with the signer function.

[bluesign]

This is very nice idea, I think the Signer should be an interface, so we can extend with KMS and other providers.

One thing lacking unfortunately in Flow is the key management. ( especially wallet side )

[devbugging]

This is very nice idea, I think the Signer should be an interface, so we can extend with KMS and other providers.

One thing lacking unfortunately in Flow is the key management. ( especially wallet side )

Thank you.

Signer is already defined as an interface in GO SDK no? https://github.com/onflow/flow-go-sdk/blob/master/crypto/crypto.go#L103 And Google KMS is implemented here https://github.com/onflow/flow-go-sdk/blob/master/crypto/cloudkms/cloudkms.go but supporting other KMS should be possible by just implementing signer interface.

[bluesign]

@sideninja, I thought this would be another Signer interface, which will be something like SigningEntity ( address, keyIndex, signingFunction ) ( actually this is mapping to single public key )

What I was thinking was making this SigningEntity to provide many keyIndex and signingFunction actually. More like SigningAccount. ( mapping to account's all keys to entity ) This would be great if it is also connected with some kind of priority ( to use the key )

Main problem currently is I have to give keyIndex ( which should not be necessary actually, SDK can resolve that from account keys )

[devbugging]

@sideninja, I thought this would be another Signer interface, which will be something like SigningEntity ( address, keyIndex, signingFunction ) ( actually this is mapping to single public key )

What I was thinking was making this SigningEntity to provide many keyIndex and signingFunction actually. More like SigningAccount. ( mapping to account's all keys to entity ) This would be great if it is also connected with some kind of priority ( to use the key )

Main problem currently is I have to give keyIndex ( which should not be necessary actually, SDK can resolve that from account keys )

Yes, my plan was to create an interface that would hold be used to pass arguments to the signing method. I've already started some work on this, hopefully be out soon.

[bluesign]

It can be nice if it can support reverse of the logic.

Maybe something like Signer interface providing the public keys (with algo) it can sign for. And SDK choosing from that options with some priority. ( or some priority of Signer interfaces )

In here ( address, keyIndex ) is actually just used to lookup ( privatekey ) which ( pubkey ) also can be used. This allows somehow not looser coupling.

Also allows some kind of back up scenarios, let's say can't reach KMS can sign with local key, or can send signing request to user etc