Added address Verification

[gavinharris-dev]

Added the method verifyAddress; this method takes the provided Public Key and Address (supplied by the signing process signData) and we attempt to recreate the address.

To recreate the address we get the stakeKeyHash and combine it with the publicKeyHash to create a 'reconstructed' address. We then verify that both the 'reconstructed' address matches the address provided when signing the data (token).

This change is to try and prevent actors spoofing a token. Prior to this change, in theory (in my head so it may not be correct) a user could create a signed token with any address as there was no verification that the Public Key (used to verify that the token has not been tampered with) belongs to the address that this token is making claim to.

[gavinharris-dev]

I have to add reference to https://cardano.stackexchange.com/q/2498/4255 And give kudos to: https://cardano.stackexchange.com/users/2815/jeroen

[pyropy]

Linking PR with the Issue ticket #2

[pyropy]

Hey buddy, do you need some help with this? Give me a shout if I can help somehow :D

[gavinharris-dev]

Really sorry! Work and life got in the way of this one!! I will schedule a few hours next week to get this done.

[pyropy]

Really sorry! Work and life got in the way of this one!! I will schedule a few hours next week to get this done.

No problems, I completely understand. Take your time and let me know if you need anything 😄

[gavinharris-dev]

Do we want to look at getting this Merged? If you have time to do a further review?

[pyropy]

Do we want to look at getting this Merged? If you have time to do a further review?

Hi there, I'll take a look at it later today ⏰

[pyropy]

@gavinharris-dev Hi, I see that you're making quite a lot of progress. Request review when you are ready.

Also, if you could remove the commited dist directory it would be awesome 🙌🏻

[chrizcros]

Hey @gavinharris-dev @pyropy wanted to check if there is any progress on this pull request? When I test out the PR I got the error:

Error: "signature" argument should be a function that returns a signature string (Promise<string>) at _callee$ (sign.ts?b2ef:9:1) at tryCatch (runtime.js?96cf:63:1) at Generator.invoke [as _invoke] (runtime.js?96cf:294:1) at Generator.eval [as next] (runtime.js?96cf:119:1) at asyncGeneratorStep (asyncToGenerator.js?1da1:3:1) at _next (asyncToGenerator.js?1da1:25:1)

The reason is that api.signData is a string and not an object:

await Web3Token.sign((msg: string) => api.signData(address, toHex(msg)), '1d')

Do you have an idea how to handle that?

[gavinharris-dev]

Hi @bieric,

Here is an example that I am currently using in our Application. This is using my main branch i.e.,

"dependencies": { 
...
"web3-cardano-token": "gavinharris-dev/web3-cardano-token",
...
}

const getLoginToken = async (wallet) => {
  const address = await wallet.getUsedAddresses();

  if (!address || address.length === 0) {
    throw new Error('No wallet address');
  }

  return await Web3Token.sign(async (msg) => {
    return await wallet.signData(address[0], Buffer.from(msg).toString('hex'));
  });
};

Wallet.signData (according to CIP30 and implemented on Nami Wallet) will return the type DataSignature which is structured as such:

type DataSignature = {|
  signature:cbor\<COSE_Sign1>,
  key: cbor\<COSE_Key>,
|};

The DataSignature type is the expected return type for the Callback method provided into Web3Token.sign.

Note: Older versions of Nami Wallet (and perhaps other Wallets) returned a CBOR String as a result of the signData method, I should probably (when allowing users to link a wallet) check that not only is the Wallet supported, but also the Version provided is supported.

In terms of getting this PR merged in, I think (with the extend of the code changes) it would be highly useful to get the code reviewed again. Also really need to work out how to write some Unit Tests for these changes! I need to verify several things now:

• Provided Token is Signed correctly; i.e., with the Private Key of the supplied Address,
• Provided Token has not been tampered with, i.e., the Signature matches a 'recalculated' signature,
• Provided Token is still 'in date'; I.E., has not expired,

I also think that there is a discussion around packaging; I have on my branch the Dist folder where I have the build artifacts available. This is probably undesirable but I'm too new to developing JS modules to know what the process should be; so any tips would be appreciated!

Ref: https://github.com/cardano-foundation/CIPs/tree/master/CIP-0030#apisigndataaddr-address-payload-bytes-promisedatasignature

[bitlands]

@gavinharris-dev Thank you a lot for your detailed description!

Unfortunately, I have still some problems. I'm trying it with Nami and Eternl wallet.

I guess eternl is still returning the CBOR string.

Nami has other problems (v3.2.1):

My questions:

1. What wallet/version do you use?
2. When a wallet returns a CBOR string do you have an example of how to handle it?

I also want to help maintain this repository since it could be a huge deal for the Cardano community but first I would like to have a working example to better understand it. Thank you in advance!

[gavinharris-dev]

What wallet/version do you use?

We use Nami 3.2.1 and get good results. The error you are getting with Nami appears to be thrown in 3 places (in the Nami code):

https://github.com/Berry-Pool/nami-wallet/blob/11fcd502504f9ce0fa22ef8f108892e2f3828aa8/src/api/extension/index.js#L694

https://github.com/Berry-Pool/nami-wallet/blob/11fcd502504f9ce0fa22ef8f108892e2f3828aa8/src/api/extension/index.js#L721

Without seeing how you are using the library I'm not really able to help much here. Perhaps print out the inputs that you are sending to signData so that you can verify that they are valid HEX encoded values (you need to verify that the address input is in-fact an address and that the 'data' can be decoded back to plain text).

Perhaps if you can post a small example that we can work through it?

When a wallet returns a CBOR string do you have an example of how to handle it?

This is a great question; @pyropy should we be looking to support the 'old' sign data structure? It looks like the community has settled towards the CIP30 version of signData and so my opinion would be that we would not support the return of CBOR string.

@pyropy Do these discussions need to move into an Issue / Discussion rather that a Pull Request?

[bitlands]

@gavinharris-dev Thank you a lot I've found the issue. I've decoded the address to the readable string and not let it in the hex format. That's why the signer fails.

Thank you again!

[pyropy]

Hey folks, sorry for being absent lately -- I've focused mostly on my day job.

@gavinharris-dev When wallet returns CBOR I guess simplest way is for user to simply handle the decoding process -- we should always stick with the CIP implementation.

Is the PR ready to be reviewed?

[chrizcros]

@pyropy I agree. Yes I think so. I've tested it with Nami and it works good.

[chrizcros]

@pyropy Do you have an example how to decode the cbor string to make other wallets compatible?

[pyropy]

@bieric You should be able to decode CBOR using some libraries -- for example here's an JS library for encoding/decoding CBOR

https://github.com/paroga/cbor-js