Add 2 more url types for offline signing

[AngainorDev]

Following @EarthlingDavey suggestion of offline signing and dnaurl as a gateway, the following formats could be useful:

A - raw tx, to transfer a tx to be controlled and signed offline
dna://raw/nonce/epoch/type/to/amount_int/maxfee_int/tips_int/encoded_payload/checksum
fields are in the same order as the transaction to be assembled.
This is from online tx creator to offline signer (offline dnamask instance or anything else).
Having the whole tx content allows the user to make sure what he signs.
technical info (nonce, epoch) is required since it's part of the signed buffer hash.

B - Transaction hash to be signed offline dna://sign/hash/encoded_hash/checksum
this is just the keccak hash to signDigest()
More dangerous, since the user has no idea what is signed.
We would suggest not to implement this one.

C - Signature only dna://txsig/encoded_sig_buffer/checksum
This one is offline signer to online wallet. encoded_sig_buffer is "joinedSignature" encoded in base58. The online wallet then assemble the full tx and sends it.
it should also validate the signature, so no mismatch is possible.

Option: to keep some link between the raw signature and the signature, checksum part of the dna://raw could be used as a temporary txsig id.
That one would then be
dna://txsig/raw_checksum/encoded_sig_buffer/checksum

This can be extended to filenames if tx and sigs are to be transfered by files instead of qrcodes: raw_checksum.txt would contain the dna://raw dnaurl
sig_checksum.txt the dna://txsig dnaurl

[idenatoday]

Hi, Thanks for the suggest.

Agree that B is dangerous. Offline signing should show the transaction to be signed, at least amount, to and data so that the user knows what he signs.
Offline signing is to make thing more secure, not add easy to exploit workflows.

We'll give more thoughts to A and C and see if other users have some feedback on them.

Use of the checksum as temporary id is a nice idea, I like that!

As for filenames, not sure if this is in the scope of DnaUrls, but thanks for trying to spec and normalize things. At least, could be a guideline for specific workflows.

Last thing: Would you be willing to handle that protocol extension yourself?

[EarthlingDavey]

I like the sound of A and C, and the option to keep a link.

For part A, are these 3 parts of the raw tx always required amount_int/maxfee_int/tips_int?

If they are optional, or if we can let devs make define defaults, then they could be merged into a single part of the url like this:

dna://raw/nonce/epoch/type/to/amount_int:maxfee_int:tips_int/encoded_payload/checksum

[idenatoday]

Mixing / and : complexifies parsing and checks and breaks url like structure..

Tips may be null, in that case just don't fill it: no tip nor payload for instance:

dna://raw/nonce/epoch/type/to/amount_int/maxfee_int///checksum

Keep in mind these strings are to be generated - and read - by an app anyway, not by hand by a human.
We don't want the default values to be hardcoded in the protocol, they could change. There, we have all the raw data that will be needed, nothing missing, all required (except tip and payload that can be null) to be signed, in the underlying binary order, under the generic url structure. So it does not require extra transform or doc or specific spec, mappings, translations, conversion: all follows the generic existing rules of both dna core transactions and dnaurl specs.

[EarthlingDavey]

ok no worries, I thought it might simplify. But, I suppose it wont.

[AngainorDev]

agree to keep it as generic as possible

@idenatoday you can refer to https://github.com/AngainorDev/DnaMask/blob/master/js/test/sign.test.js

we think some parts of this belong to dnaurl, like converting a raw dnaurl to a transaction array, or even give its checksum for signing. once this is in the npm module it will be easy for us to add the offline signing feature to the wallet.