Add content rendering to personal.sign calls with mime header

[danfinlay]

As suggested by Gavin Wood in this EIP, if we checked for a MIME type header, we could support human-readable sign forms with full backwards-compatibility.

I think we could implement this as an experiment, and see what needs arise from it.

[danfinlay]

Initial plain-text rendering added in #1177
This issue represents adding mime headers for richer content rendering.

[chafey]

I don't recall ever seeing a JS API that takes a MIME header + content in like this - have you? I understand the flexibility it provides, but it doesn't feel right. Why not just pass in a URI and the app can use data uri to pass on the fly content if it isn't static

[danfinlay]

I don't think "JS API" is the right starting point for this, I think the underlying cryptography is. We can always add convenient JS abstractions on top of a secure foundation, but the signed message has to be to-the-bit consistent to be secure or reliable.

A URI can point at dynamic content, and so a user can sign a URI now, and it can be changed later, so there's a loss of secure correlation between what was signed and what was agreed to.

An IPFS hash might make more sense, because we could load it in an iframe as the terms of service, but even an IPFS hash could point to a web page that loads a dynamic iframe, so that doesn't have solid content consistency guarantees either.

Even if we like that, it's still a very opinionated way to go forward, and doesn't leave us much room to grow, which is one of the virtues of MIME headers.

I'm open to other bit-consistent message formats, but I don't think a URI is the solution, and I think something like "MIME, utf-8 hex-encoded" is pretty wonderfully specific and easy to produce in any language.

If you think JS hasn't done this, try searching npm for mime formatter.

[chafey]

OK so just to be clear, you feel it is important to include the message presented to the user as input to the digital signature? I can see how that could be useful for some use cases (not all), but it also makes things more complex for those trying to check the signature - especially smart contracts which can't access IPFS directly. Is there an API proposal for this yet I can look at? Or are we still in ideation mode?

[danfinlay]

I'd say this is better replaced by the signTypedData proposal EIP.
ethereum/EIPs#712