Open pa-long opened 1 year ago
@makerare if you're thinking of writing a CIP for this, it sounds like it would be a good idea to propose. We have a new convention under review for extensions to CIP-0030: https://github.com/cardano-foundation/CIPs/pull/446
If you're suggesting this be added to CIP-0030 under all circumstances then say so here & I'll tag some people involved in the history of CIP-0030 to help discuss that. (You are welcome to do this as well.)
Yes I would appreciate this as I don't know who to reach, so they can arbitrate as they would know what makes the most sense, thank you. I'd be glad to write the proposal !
cc (may be interested in issue discussion of CIP update or new CIP for this): @KtorZ @SebastienGllmt @alessandrokonrad @rooooooooob @ehanoc @refi93 @MarcelKlammer @Scitz0
After some thinking, i think what makes the most sense is not to create a new CIP-0030 function, but to specify in the CIP that wallets should check if signData receives a payload corresponding to a CBOR Web Token (CWT).
I'll fork web3-cardano-token
package repo, which needs two fixes already (CIP-0030 signData conformity and verification of signing address, both of those I have a patch for locally), and change signed payload to use CWT standard instead of a custom json.
That way, wallets could also possibly have a specific interface for displaying data signature of CWT, but most importantly protect their users by verifying the validity of the claims:
aud
claim (StringOrURI targeted audience) made for this exact purpose, if signData is called to sign a CWT containing aud: "domain.com"
different from the current domain, wallet should warn the user about the possible phishing attempt. exp
or nbf
in the past, or iat
in the future.I'll propose an update of CIP-0030 signData section where CWT is referenced.
Currently, any hybrid dApp can authenticate its users using CIP-0030
signData
function. For instance, an implementation of an equivalent of JSON Web Token (JWT) is available here.The problem relying in those methods is their vulnerability to a phishing attack: a malicious website could forge a JWT made for authentication to another website, make the user sign it, and act as a man in the middle. Example: User fetches malicious jpgs.store, signs a message containing "Connect to jpg.store". Signed message can the be used to access user's account on jpg.store Hybrid dApp (which is critical in this case as you can manage NFT collections and their royalty address from their interface).
A solution could be to implement JW3T signature directly in the wallet API.
walletApi.signData
also need to be display a warning sign when it is called to sign a message with JW3T format but not the good domain.To verify the token from the backend:
This standard is very straight forward to implement, as
web3-cardano-token
package provides it with just the addition of the domain key (which could also simply go inside the body object).