A ToenScript might be used:
- In user-agent (Android)
- In user-agent (iOS)
- In user-agent (MetaMask plugin)
- In data processing service (Amber data's data engine)
- In IoT devices
- In a Token management console (token issuer's backend tool)
- In an IDE (IntelliJ or Microsoft based)
- There is some cross-section of the former two. e.g. Rust/C code can be ported between the two to a certain extent and can be used in IoT as well
- but a Java-based approach works best on Android and in data Processing.
There is quite a bit of pathfinding needed. Here are my thoughts, using the route of least resistance method.
- Java's Java Cryptography Architecture (JCA) is the easiest to use and produces the least amount of code. So a Java-based library might be produced anyway.
- From there, a library suitable for data processing might be produced as well.
- And to develop a plugin for IntelliJ.
- It's also easy to build a Java desktop tool for Token Console.
† we depend on web3.js so ECDSA validation of the Express-of-Trust isn't a problem. Here we talk about ECDSA signatures on the TokenScript. See the difference between these two concepts.
To run Rust/C code in iOS/Android, we need it to have a minimalist dependency. There already was a libxml2 wrapper for iOS, so we are left with these choices:
- Build a basic XML security library in SWIFT thanks to the XPATH/C14N support in libxml2. This has the least reüse value.
- Build a minimum RUST library for XMLDSIG and shoehorn it into iOS. This requires extending the current RUST wrapper for libxml2 to include support for c14n (libxml2 supports c14n but the wrapper doesn't).
- Shoehorn a RUST wrapper for libxmlsec1 into iOS.
The 3rd choice is the safest since it doesn't start with the word Build. One should not create a security library on a whim. But the community work has just begun on wrapping libxmlsec.
It will be easy to write a Token Console in Rust/C, but it will be difficult to integrate libxmlsec, which uses openssl/gnutls/nss, with Android/iOS's security strong-bux. Luckily we can avoid that.†
- When used in Android/iOS, both validates XML security, not signing TokenScript files, so we don't have to integrate iOS/Android's security strongbox with that C library.
- When (potentially) used in a Token Console (use-case 6) or in an IDE (use-case 7), signing would be actually needed. But the environment is likely not mobile, so again we don't have to integrate iOS/Android's security strongbox with that C library.
What about running the RUST/C library in Web Assembly
For the security quarantine reason, I prefer to think WebAssmebly as the run time environment of Token Enclave code - the bit of code embedded in TokenScript files, and not where the TokenScripts are parsed and examined. Rather instead, the TokenScript library running outside of the web page (in plugin-space) prepares the code to run in a WebAssembly (on the web page). This way the website, if gained the ability to compromise a WebAssemly instance, will not be able to validate a falsely signed TokenScript.
We still can, if that turns out to be an easy path, have a special WebAssembly instance just for TokenScript file parsing and security functions, live inside a plugin. This is an atypical way of using WebAssembly, since a WebAssemly instance runs on a web page, not on a plugin, and are supposed to live within the life-span of a web-page. Going down that route we are likely to trigger bugs that others don't see important.
At first, it seems all 3 of them has to be implemented. Not any 2-out-of-3 combination will serve all purposes.
But that means we ditch the easier route (Java) in round 1. Java is the easier rought thanks to JCA.