Three ways to cover images, JavaScript and stylesheets in the TokenScript's signature

Tokenscript Design
1

Currently, since we don’t offer a way to sign these data, we require the use of entity reference for stylesheets; and we use base64 embedded format for images.

There are three ways to cover such external data.

  1. include them in XML signature, in XML’s <SignedInfo> (or <Manifest> it refers to) and have the digest of each URI included.
  2. on the HTML level. All HTML elements with external linking capacity have an integrity attribute, like <img src="img/icon.png" integrity="sha1-edfdecafbad..."/>
  3. to embed them as we are doing now.

Since all of the 3 methods are standard-compliant, while the first being part of XMLSIG, the second being part of HTML and the third being XML itself, this issue is not a design issue but rather an implementation one, on which method should we support first in implementation.

The 3rd option is the best for deploying TokenScript directly to wallets. We can streamline it by adding options to an XML signing tool which repackages every bit of such data either in-place in the XML file (stylesheet) or its base64 format in-place.

But the first two are what allows TokenScript to be web-integration. It doesn't break the existing development tools or web-dev workflow. so let's talk about both.

The 1st approach handles URI-referred data that isn't part of HTML, e.g. icons of a token at various resolutions. It, however, requires the existence of XML's <Signature>, which is missing for trusted but unsigned TokenScript (e.g. King of the Ether smart contract's TokenScript).

Either approach would require implementations to do some surgical intervention on WebView, that is, implementations must be able to verify the data after it is retrieved and before it was used in the WebView.

In conclusion, all of the three methods work independently and all are standard-compliance. So ideally it’s possible to write a TokenScript engine in such a way that:

  1. If there is a URI reference, check if the URI (and digest) is included in <SignedInfo>;
  2. If the URI is not included in <SignedInfo>, check if it has integrity.
  3. If both failed, the URI is not loaded (treated like 404 error).
  4. Otherwise, the URI is loaded, and its integrity verified (if has integrity) or digest verified (if it is referred to in <SignedInfo>.

Before we get the ideal implementation like describe, we can choose to support 1st or 2nd approach first.

2

With approach 2. It looks like there is partial browser support for verification (we need to verify if that's true):

https://blog.compass-security.com/2015/12/subresource-integrity-html-attribute/

1 Like