splitting ERCs into 2

Author: Weiwu Zhang

ERCs/ERC5XX1 draft.md

@@ -0,0 +1,61 @@
+### eip: 5???
+
+### title: asserting authenticity of Client Script for Token Contracts
+
+### description: Provide a method to assert the authenticity of client script for token contracts, and a way for revokation
+
+### author: Weiwu (@weiwu-zhang), Tore Frederiksen (@jot2re)
+
+### discussions-to:
+
+### status: Draft
+
+### type: Standards Track
+
+### category: ERC
+
+### created: 2s022-05-03
+
+### requires: 
+
+### Abstract
+
+This ERC describes how to assert the authenticity of signed client-script and adds a `revokeClientCodeSigningKey()` function for revocation.
+
+### Motivation
+
+Often NFT authors want to provide some user functionality to their tokens through client scripts. This should be done safely, without opening the user to potential scams. By signing such code with a *Script Signing Key* linked to the creation of the smart contract. Refer to ERC xxxx examples of such scripts.
+
+Although ERC xxxx specified a way to obtain a set of client scripts through URI, in many cases, it is
+
+- insufficient; for example, a smart contract might has script for different environment or use-cases. Take a subway token as an example, it might invoke a minimal script to drive the purchase and use of subway tokens in order to send them through NFC (Internet might be slow or inaccessible underground)
+- inapplicable; for example for token contracts that was issued before the creation of ERC xxxx
+
+This ERC offers a way to assert authenticity of such client scripts disregarding how it is obtained, and can work with smart contracts prior to the publication of this ERC.
+
+### Overview
+
+Although the *smart contract author* and the *client script author* can be the same person/team, we will assume they are different people in this ERC, and the case that they are the same person/team can be implied.
+
+Step 1. The *script author* creates a *script signing key*.
+
+Step 2. The *smart contract author*, using the *smart contract deployment key*, signs a certificate whose subject is the code signing key, which includes expiry.
+
+Step 3. Any client script is to be shipped signed by the *script signing key* and with a certificate attached.
+
+This process is a deliberate copy of the TLS certificate, which is based on x.509 and was proven working in the past decades.
+
+The authenticity of the client script may be obtained through `scriptURI()` function call as in ERCxxxx, or maybe supplied separately by the use-cases, but this ERC is applicable to any code that is signed, and a client must validate the signature in the way specified in this ERC. In real life use-cases, the client scripts can be either supplied by aforementioned `scriptURI()` or offered to the client (wallet) in anyway the wallet can work with, even through NFC connections or QR code.
+
+### Format of the certificate and signature
+
+[expand here] certificate is to be in x.509 format. the signature is to be compatible with XMLDSIG.
+
+### Format to attach signature
+
+This ERC does not specify how a wallet client obtains the signature [examples of ways to obtain]
+
+### Concerning Proxy Contract
+
+
+

ERCs/ERC5XXX draft.md

@@ -22,8 +22,9 @@ Concretely each element in the array contains a pair of URIs, one to the script
 
 The script provides a client-side executable to the hosting token. Examples of such script:
 
-- A 'miniDapp', which is a cut-down dapp tailored for a single token
+- A 'miniDapp', which is a cut-down dapp tailored for a single token.
 - a 'TokenScript' which provides [T.I.P.S.](https://tokenscript.org/TIPS.html) from a browser wallet.
+- an extension that is downlandable to the hardware wallet with an extension framework, such as Ledger.
 
 It is expected that the return value of scriptURI() is constantly updated to reflect the current latest version, if used. However, there is a way to assert the authenticity of signed client side code without frequently updating the URI. Developers should refer to ERC 5xx1 which detailed a method of asserting code authenticity without relying on an URI. Note that both ERCs can be used together.
 
@@ -40,6 +41,11 @@ While the simplest solutions to facilitate specific script usage associated with
 3. Storage fee. If the script is large, contains special graphics or other large elements, then updates to the script can quickly costs thousands of dollars.
 
 For these reasons it makes sense to store volatile data, such as token enhancing functionality, on an external resource. Such an external resource can be either centralized, such as a cloud provider or private server, or decentralized such as the interplanetary filesystem.
+
+#### Authenticity
+
+If the ScriptURI points to a hash, such as with IPFS, the client (wallet) should assume it authentic, if the hash matches. However, if ScriptURI points to a dynamically downloaded location, the client must verify the signature of the script in the method described ERC xxxx, and warn user against executing the script.
+
 Since using centralized storage for a decentralized functionality goes against the ethos of web3, this ERC handle this this by allowing the token provider to store multiple URIs to the script on-chain. The URIs might point to either multiple centralized storage providers or fully decentralized ones, e.g. the IPFS, another blockchain or even on Ethereum itself. It could also be a mix of centralized and decentralized locations.
 
 While this ERC does not dictate the format of the stored script, it should be noted that the script itself could contain pointers to multiple other scripts and data sources. Hence this allows for advanced and rich expansion of tokens.