From 5e1c09017240c50bbb670ad0f5d0a2fc6700b5d0 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 20 Feb 2019 16:23:09 +0100 Subject: [PATCH 01/92] first draft eip on app keys --- EIPS/eip-draft_app_keys.md | 286 +++++++++++++++++++++++++++++++++++++ 1 file changed, 286 insertions(+) create mode 100644 EIPS/eip-draft_app_keys.md diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md new file mode 100644 index 00000000000000..116f0ecd313ec9 --- /dev/null +++ b/EIPS/eip-draft_app_keys.md @@ -0,0 +1,286 @@ +--- +eip: +title: ERC - App Keys: domain specific accounts +author: +Vincent Eli @Bunjin vincent.eli@gmail.com +Dan Finley @DanFinley +discussions-to: +status: Draft +type: Standards Track +category: ERC +created: 2019-02-20 +requires (*optional): +replaces (*optional): +--- + + +## Simple Summary + + +This proposal describes a new standard and api for wallet accounts that are derived specifically for a given app (domain) and that allow for a more permissive level of security (delegation) while keeping main accounts secure and increase privacy. + +Wallets can determine more permissive security rules for these accounts because they are not the main accounts that hold most of an user's cryptocurrencies. This should allow to significantly improve UX and to allow for new apps designs. + +## Abstract + +In a wallet, an user often holds most of her funds in his main accounts. These accounts require a significant level of security and should not be delegated in any way, this significantly impacts the design of crypto apps if a user has to manually confirm every transaction. Also often an user uses the same accounts accross apps, which is a privacy and potentially also security issue. +We introduce here a new account type, app keys that allow for signing delegation and accounts isolation accross domains for privacy and security. + + +## Motivation + +Allows to give more power and flexibility to the crypto apps developers. This should allow to improve a lot the UX of crypto dapps and allow to create new designs that were not possible before leveraging on the ability to create and handle many accounts, to presign messages and broadcast them later. + +Can allow to easily implement several of the features that where requested to MetaMask but that where incompatible with the level of security we were requesting for main accounts: + +offline signing without broadcasting of txes +be able to sign without prompting the user +be able to use throwable keys to improve anonymity +be able to use different keys / accounts for each apps +While being fully restorable using the user's mnemonic or hardware wallet and the HD Path determined uniquely by the app's ens name. + + + +## Specification + + +### HD path +requires BIP 32 and BIP 39 +derives from BIP44 and EIP +BIP 44 for eth: https://github.com/ethereum/EIPs/issues/84 and https://github.com/ethereum/EIPs/issues/85 +not stricly BIP44 because of cointype should be a number between 0 and 2^31. + +eth: +m/44'/60'/a'/0/n + +Favored spec, bip32 + +m/EIP#'/[persona path]'/[domain uid path]'/[domain custom subpath] + +where EIP, we use a different path than 44 since it's not bip44, not sure if there is a list of alternative standards + +[persona path] allows to have personas that are not known by apps while having this independant of accounts, thus blockchains keys. +hardened indexes +[domain uid path] +Since each derivation step only has 31 bits we will decompose the domain uid into several indexes + +### Domain's UID and authentication + +#### domain source + +##### domain's UID: Favored spec, ENS name hash and resolving url through ens +0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0 + +ENS Specs +http://docs.ens.domains/en/latest/implementers.html#namehash + +domain - the complete, human-readable form of a name; eg, ‘vitalik.wallet.eth’. +label - a single component of a domain; eg, ‘vitalik’, ‘wallet’, or ‘eth’. A label may not contain a period (‘.’). +label hash - the output of the keccak-256 function applied to a label; eg, keccak256(‘eth’) = 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0. +node - the output of the namehash function, used to uniquely identify a name in ENS. +Algorithm +First, a domain is divided into labels by splitting on periods (‘.’). So, ‘vitalik.wallet.eth’ becomes the list [‘vitalik’, ‘wallet’, ‘eth’]. + +The namehash function is then defined recursively as follows: + +namehash([]) = 0x0000000000000000000000000000000000000000000000000000000000000000 +namehash([label, …]) = keccak256(namehash(…), keccak256(label)) + +keccak256(‘eth’) = 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0 + +Normalising and validating names +Before a name can be converted to a node hash using Namehash, the name must first be normalised and checked for validity - for instance, converting fOO.eth into foo.eth, and prohibiting names containing forbidden characters such as underscores. It is crucial that all applications follow the same set of rules for normalisation and validation, as otherwise two users entering the same name on different systems may resolve the same human-readable name into two different ENS names. + + + +#### domain's uid hash decomposition to get an Hd path + +Since each derivation step only has 31 bits we will decompose the domain's hash as several path indexes, first as hex bytes then parsed as integers + +if we use an eth address of 20 bytes, 160 bits + +``` +x = x0 || x1 || x2 || x3 || x4 || x5 +``` +where `x0` to `x4` are 30 bits and `x5` is 10 bits. + +which gives the derivation sub path: + +``` +x0'/x1'/x2'/x3'/x4'/x5' +``` + +or alternatively equal length +``` +x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 +``` +where `x0` to `x7` are 20 bits. + + + + + +if we use an ENS namehash 32 bytes, 256 bits + +0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0 + +``` +x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 +``` +where `x0` to `x7` are 30 bits and `x8` 16 bits + +equal length would be 16 * 16 bits + +or 16 * 2 bytes, cleanest: +4f5b 8127 89fc 606b e1b3 b169 08db 13fc 7a9a df7c a726 41f8 4d75 b470 69d3 d7f0 + +does not seem to really matter which we pick between the 2 decomposition approaches, +Maybe favor the one that leads to less indexes +alternative has the benefit of being much cleaner, especially for the 256 bits decompositions + +## API: + +### App keys exposure: +wallet.appkeys.enable() +uses the persona selected by the user (not shared with app) +uses the domain ens hash that was resolved to load window +depending on user choice, user will be prompted for signing confirmations or not for those app keys + +### Global HD methods: +none + +### Ethereum methods: +hdSubPath +with uint under 0x80000000, 31 bits +should follow bip32 +can be hardened +can be writen in hex or int + +* appKey_eth_getPublicKey(hdSubPath) returns 64 bytes +0x80b994e25fb98f69518b1a03e59ddf4494a1a86cc66019131a732ff4a85108fbb86491e2bc423b2cdf6f1f0f4468ec73db0535a1528ca192d975116899289a4b +* appKey_eth_derivePublicKeyFromParent(parentPublicKey, hdSubPath) returns 64 bytes +parentPublicKey should not be hardened + +* appKey_eth_getAddress(hdSubPath) returns 20 bytes +hdSubPath: "index_i / index_(i+1) '", can use hardening +e.g. 0x 9d f7 73 28 a2 51 5c 6d 52 9b ae 90 ed f3 d5 01 ea aa 26 8e + +* appKey_eth_signTransaction(fromAddress, tx) +tx is ethereum-js tx object + +* appKey_eth_sign(fromAddress, message) +* appKey_eth_personalSign(fromAddress, message) +* appKey_eth_signTypedMessage(fromAddress, message) + +### Other potential methods: +#### other cryptocurrencies +#### other crypto +* **encrypt(uint index, data) return bytes** +Request Encryption + +* **decrypt(uint index, bytes) return data** +Request Decryption +#### cross domain communication / signing +#### storage +* **persistInDb(key, data)**: +Store in MetaMask localdb, specific store for plugin + +* **readInDb(key) returns data**: + + +## Rationale + +### Isolated paths ut customisables +### persona isolation +### API not exposing private keys + +### HD derivation path Using ENS as domain +#### HD Path: Alternative derivation spec than bip32? +HD still but not with hardening? +hardening has benefits ? +## HD Paths: +### Proposal 1 (use their own paths): + +[Standard beginning of Hd Path] / [Domain Specific Hd Path] / [App controlled HD subPath] / [Account index] + + +Standard beginning: +m/44/60 is eth +but we won't be using bip44 here since not a crypto +and we don't want app keys to be ETH specific + +### Proposal 2 (make them subsets of ETH main accounts) +[Hd Path of an Eth main Account] / [Domain Specific Hd subPath] / [App controlled HD subPath] / [Account index] + +pros: +allows to use isolated app paths for the same app using the same mnemonic. +can have several accounts fully separated to use the same domain without the domain knowing I'm the same individual. All this with the same mnemonic, I would just use 2 different mainAccounts. +One question though is how do you handle apps/plugin that would like to interact with several "main accounts", accounts outside of their control? Not sure if this use case really exists tho and we could have. +Also how does this applies to the plugins if metamask doesn't have a "selected account anymore"? Logging into plugins in the same way as in websites, EIP1102? + +cons: +makes this a subset of an ethereum account or should be eventually generalised to non ETH main accounts? +adds complexity to restore, one should remember which account is which +same benefits of privacy could be implemented by add an user provided field in the HD path, after domain and before app subpath + +### Hardening + +we harden all but the + +### domain's authentification +##### domain's UID: Alternative spec, eth author address and including a signed message +0x9df77328a2515c6d529bae90edf3d501eaaa268e + + + +## Backwards Compatibility + +No incompatibity since these are separate accounts +For apps that registered their user using main accounts eth addresses, they need to have a migration pattern to app keys accounts when desirable + + + +## Test Cases + + +## Examples: +token contract: +https://github.com/ethereum/EIPs/issues/85 + +## Implementation + +WIP +Link to hdkeyring methods + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + + +## Acknowledgements +Liam +ricmoo +jeff coleman +for discussions about the domain's hd path + + +## Sources: + +### HD and mnemonics +BIP 32 specs, Hierarchical Deterministic Wallets: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki +BIP 39 specs, Mnemonic code for generating deterministic keys: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki +BIP 39 tool: https://iancoleman.io/bip39/#english +BIP 44 for eth: https://github.com/ethereum/EIPs/issues/85, https://github.com/ethereum/EIPs/issues/84 + +### ENS: +http://docs.ens.domains/en/latest/implementers.html#namehash + + +# Notes: +- In Hd Paths, Merge app controlled subset and account index ? + + +- XPubKeys, how do we introduce them? How do we isolate them such that we don't leak a single XPubKey for the whole mnemonic, which would be a big privacy concern and would also remove the benefit of proposal 2 for hd path isolation per main account. + + +json rpc method middleware +private RPC methods for app keys From 515d28637a977c88a0397f4812fa148353a04110 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 20 Feb 2019 16:53:11 +0100 Subject: [PATCH 02/92] better writing for summary and abstract --- EIPS/eip-draft_app_keys.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 116f0ecd313ec9..ea069c40439192 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -17,15 +17,16 @@ replaces (*optional): ## Simple Summary -This proposal describes a new standard and api for wallet accounts that are derived specifically for a given app (domain) and that allow for a more permissive level of security (delegation) while keeping main accounts secure and increase privacy. - -Wallets can determine more permissive security rules for these accounts because they are not the main accounts that hold most of an user's cryptocurrencies. This should allow to significantly improve UX and to allow for new apps designs. +Among other cryptographic applications, Scalability and privacy solutions for ethereum blockchain require that an user performs a significant amount of signing operations and may also require her to watch some state and be ready to take some cryptographic action (e.g. sign a state or contest a withdraw in a state channel). The way wallets currently implement accounts poses several obstacle to the development of a complete web3.0 experience both in terms of UX, security and privacy. +This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given app (domain). We propose to call them `app keys`. These accounts allow to isolate the accounts used for each app, thus increasing privacy. They also allow to give more control to the applications developpers over accounts management and signing delegation. These app keys have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally one can use these to sign transactions without broadcasting them. +This new accounts type should allow to significantly improve UX and to allow for new designs for apps of the crypto permissionned web. ## Abstract -In a wallet, an user often holds most of her funds in his main accounts. These accounts require a significant level of security and should not be delegated in any way, this significantly impacts the design of crypto apps if a user has to manually confirm every transaction. Also often an user uses the same accounts accross apps, which is a privacy and potentially also security issue. +In a wallet, an user often holds most of her funds in her main accounts. These accounts require a significant level of security and should not be delegated in any way, this significantly impacts the design of crypto apps if a user has to manually confirm every transaction. Also often an user uses the same accounts accross apps, which is a privacy and potentially also a security issue. We introduce here a new account type, app keys that allow for signing delegation and accounts isolation accross domains for privacy and security. - +We specify how to uniquely define each domain, authenticate a request to use a given domain's app keys, how to derive the accounts along an HDpath restricted for the domain and we finally define an API to derive and use these app keys. +We propose this EIP as an ERC such that our community can aggree on a standard that would allow for cross wallet and cross app compatibility while fitting most needs. ## Motivation From 1e0460c1fe3d3c932c888f1afa501fdb4733af0a Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 20 Feb 2019 17:26:51 +0100 Subject: [PATCH 03/92] better writing for specs --- EIPS/eip-draft_app_keys.md | 95 ++++++++++++++++++++++++++------------ 1 file changed, 65 insertions(+), 30 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index ea069c40439192..92d4b7ece98a52 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -17,7 +17,7 @@ replaces (*optional): ## Simple Summary -Among other cryptographic applications, Scalability and privacy solutions for ethereum blockchain require that an user performs a significant amount of signing operations and may also require her to watch some state and be ready to take some cryptographic action (e.g. sign a state or contest a withdraw in a state channel). The way wallets currently implement accounts poses several obstacle to the development of a complete web3.0 experience both in terms of UX, security and privacy. +Among other cryptographic applications, scalability and privacy solutions for ethereum blockchain require that an user performs a significant amount of signing operations and may also require her to watch some state and be ready to take some cryptographic action (e.g. sign a state or contest a withdraw in a state channel). The way wallets currently implement accounts poses several obstacle to the development of a complete web3.0 experience both in terms of UX, security and privacy. This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given app (domain). We propose to call them `app keys`. These accounts allow to isolate the accounts used for each app, thus increasing privacy. They also allow to give more control to the applications developpers over accounts management and signing delegation. These app keys have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally one can use these to sign transactions without broadcasting them. This new accounts type should allow to significantly improve UX and to allow for new designs for apps of the crypto permissionned web. @@ -30,51 +30,44 @@ We propose this EIP as an ERC such that our community can aggree on a standard t ## Motivation -Allows to give more power and flexibility to the crypto apps developers. This should allow to improve a lot the UX of crypto dapps and allow to create new designs that were not possible before leveraging on the ability to create and handle many accounts, to presign messages and broadcast them later. +Wallets have aggreed on a derivation path for eth accounts using BIP32, BIP44, SLIP44, ERC85 (https://github.com/ethereum/EIPs/issues/85) +Web3 (browser) wallets have implemented in a roughly similar way the rpc eth api. +EIP 1102 introduced privacy through non automatic opt-in of a wallet account into an app increasing privacy. +But several limitations remain to allow for a proper UX of the crypto permissioned web. -Can allow to easily implement several of the features that where requested to MetaMask but that where incompatible with the level of security we were requesting for main accounts: +Most current wallets don't allow for -offline signing without broadcasting of txes -be able to sign without prompting the user -be able to use throwable keys to improve anonymity -be able to use different keys / accounts for each apps -While being fully restorable using the user's mnemonic or hardware wallet and the HD Path determined uniquely by the app's ens name. +* offline transaction signing without broadcasting of txes while still being able to perform other transaction signing +* being able to sign without prompting the user +* be able to use throwable keys to improve anonymity +* being able to automatically and effortlessly use different keys / accounts for each apps +* All this while being fully restorable using the user's mnemonic or hardware wallet and the HD Path determined uniquely by the app's ens name. +We try to solve this by introducing a new account's type, app keys made to be used along side the existing main accounts. + +These new app keys should allow to give more power and flexibility to the crypto apps developers. This should allow to improve a lot the UX of crypto dapps and allow to create new designs that were not possible before leveraging on the ability to create and handle many accounts, to presign messages and broadcast them later. These features were not compatible with the level of security we were requesting for main accounts that hold most of an user's funds. ## Specification -### HD path -requires BIP 32 and BIP 39 -derives from BIP44 and EIP -BIP 44 for eth: https://github.com/ethereum/EIPs/issues/84 and https://github.com/ethereum/EIPs/issues/85 -not stricly BIP44 because of cointype should be a number between 0 and 2^31. +### Domains -eth: -m/44'/60'/a'/0/n - -Favored spec, bip32 +A domain is an app that would like to request access to app keys, crypto app, eth but not only. -m/EIP#'/[persona path]'/[domain uid path]'/[domain custom subpath] +#### Domain's UID +ens domain +namehash node -where EIP, we use a different path than 44 since it's not bip44, not sure if there is a list of alternative standards +Favored spec, ENS name hash and resolving url through ens -[persona path] allows to have personas that are not known by apps while having this independant of accounts, thus blockchains keys. -hardened indexes -[domain uid path] -Since each derivation step only has 31 bits we will decompose the domain uid into several indexes +bytes32 e.g. 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0 -### Domain's UID and authentication - -#### domain source - -##### domain's UID: Favored spec, ENS name hash and resolving url through ens -0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0 ENS Specs http://docs.ens.domains/en/latest/implementers.html#namehash +``` domain - the complete, human-readable form of a name; eg, ‘vitalik.wallet.eth’. label - a single component of a domain; eg, ‘vitalik’, ‘wallet’, or ‘eth’. A label may not contain a period (‘.’). label hash - the output of the keccak-256 function applied to a label; eg, keccak256(‘eth’) = 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0. @@ -91,6 +84,48 @@ keccak256(‘eth’) = 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47 Normalising and validating names Before a name can be converted to a node hash using Namehash, the name must first be normalised and checked for validity - for instance, converting fOO.eth into foo.eth, and prohibiting names containing forbidden characters such as underscores. It is crucial that all applications follow the same set of rules for normalisation and validation, as otherwise two users entering the same name on different systems may resolve the same human-readable name into two different ENS names. +``` +See alternative specs in rationale below. + +#### Domain's authentication + +Load window or script through ens resolution + +using for instance this resolver. + +we either point the name to a string or use metadatafields if it points to an address + +we also add a authorEthAddress metadatafield that can be used to authenticate message from the app's dev + + +### Personas + +We allow the user to use different personas in combination to her mnemonic to potentially fully isolate her interact with a given app accross personas. One can use this for instance to create a personal and business profile for a given's domain both backup up from the same mnemonic, using 2 different personnas indexes. The app or domain, will not be aware that it is the same person and mnemonic behind both. + + +### HD path +requires BIP 32 and BIP 39 +derives from BIP44 and EIP +BIP 44 for eth: https://github.com/ethereum/EIPs/issues/84 and https://github.com/ethereum/EIPs/issues/85 +not stricly BIP44 because of cointype should be a number between 0 and 2^31. + +eth: +m/44'/60'/a'/0/n + +m/[EIP#]'/[persona path]'/[domain uid path]'/[domain custom subpath] + +where +EIP#, we use a different path than 44 since it's not bip44, not sure if there is a list of alternative standards + +[persona path] allows to have personas that are not known by apps while having this independant of accounts, thus blockchains keys. +hardened indexes +[domain uid path] +Since each derivation step only has 31 bits we will decompose the domain uid into several indexes + + + +#### domain source + @@ -198,7 +233,7 @@ Store in MetaMask localdb, specific store for plugin ### HD derivation path Using ENS as domain #### HD Path: Alternative derivation spec than bip32? HD still but not with hardening? -hardening has benefits ? +hardening has benefits ## HD Paths: ### Proposal 1 (use their own paths): From 540f7cc48da46673d3d6891a981a45db2dcd73a4 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 20 Feb 2019 17:31:26 +0100 Subject: [PATCH 04/92] draft --- EIPS/eip-draft_app_keys.md | 44 ++++++++++++++------------------------ 1 file changed, 16 insertions(+), 28 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 92d4b7ece98a52..8cd217970bda43 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -124,11 +124,6 @@ Since each derivation step only has 31 bits we will decompose the domain uid int -#### domain source - - - - #### domain's uid hash decomposition to get an Hd path Since each derivation step only has 31 bits we will decompose the domain's hash as several path indexes, first as hex bytes then parsed as integers @@ -153,9 +148,6 @@ x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 where `x0` to `x7` are 20 bits. - - - if we use an ENS namehash 32 bytes, 256 bits 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0 @@ -226,32 +218,31 @@ Store in MetaMask localdb, specific store for plugin ## Rationale -### Isolated paths ut customisables -### persona isolation -### API not exposing private keys +### Isolated paths but customisables -### HD derivation path Using ENS as domain -#### HD Path: Alternative derivation spec than bip32? -HD still but not with hardening? -hardening has benefits -## HD Paths: -### Proposal 1 (use their own paths): +### persona isolation for privacy -[Standard beginning of Hd Path] / [Domain Specific Hd Path] / [App controlled HD subPath] / [Account index] +### hardening for privacy +hardening has benefits for security and privacy if parent is leaked +### API not exposing private keys -Standard beginning: -m/44/60 is eth -but we won't be using bip44 here since not a crypto +### Alternatives about HD derivation path +HD Path: Alternative derivation spec than bip32? +HD still but not with hardening? +We won't be using bip44 here since not a crypto and we don't want app keys to be ETH specific -### Proposal 2 (make them subsets of ETH main accounts) +Proposal 2 (make them subsets of ETH main accounts) [Hd Path of an Eth main Account] / [Domain Specific Hd subPath] / [App controlled HD subPath] / [Account index] pros: allows to use isolated app paths for the same app using the same mnemonic. + can have several accounts fully separated to use the same domain without the domain knowing I'm the same individual. All this with the same mnemonic, I would just use 2 different mainAccounts. + One question though is how do you handle apps/plugin that would like to interact with several "main accounts", accounts outside of their control? Not sure if this use case really exists tho and we could have. + Also how does this applies to the plugins if metamask doesn't have a "selected account anymore"? Logging into plugins in the same way as in websites, EIP1102? cons: @@ -259,16 +250,13 @@ makes this a subset of an ethereum account or should be eventually generalised t adds complexity to restore, one should remember which account is which same benefits of privacy could be implemented by add an user provided field in the HD path, after domain and before app subpath -### Hardening +==> personas seem better -we harden all but the - -### domain's authentification -##### domain's UID: Alternative spec, eth author address and including a signed message +### Alternatives about domain's authentification +domain's UID: Alternative spec, eth author address and including a signed message challenge for author for authentication 0x9df77328a2515c6d529bae90edf3d501eaaa268e - ## Backwards Compatibility No incompatibity since these are separate accounts From a0a3cd9dc83749cd826c7840f13dd2012491d4e7 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 20 Feb 2019 18:10:36 +0100 Subject: [PATCH 05/92] draft --- EIPS/eip-draft_app_keys.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 8cd217970bda43..caee43467e77e2 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -118,10 +118,10 @@ where EIP#, we use a different path than 44 since it's not bip44, not sure if there is a list of alternative standards [persona path] allows to have personas that are not known by apps while having this independant of accounts, thus blockchains keys. -hardened indexes +hardened [domain uid path] Since each derivation step only has 31 bits we will decompose the domain uid into several indexes - +hardened #### domain's uid hash decomposition to get an Hd path @@ -186,8 +186,9 @@ can be writen in hex or int * appKey_eth_getPublicKey(hdSubPath) returns 64 bytes 0x80b994e25fb98f69518b1a03e59ddf4494a1a86cc66019131a732ff4a85108fbb86491e2bc423b2cdf6f1f0f4468ec73db0535a1528ca192d975116899289a4b + * appKey_eth_derivePublicKeyFromParent(parentPublicKey, hdSubPath) returns 64 bytes -parentPublicKey should not be hardened +hdSubPath should not be hardened * appKey_eth_getAddress(hdSubPath) returns 20 bytes hdSubPath: "index_i / index_(i+1) '", can use hardening @@ -223,7 +224,9 @@ Store in MetaMask localdb, specific store for plugin ### persona isolation for privacy ### hardening for privacy -hardening has benefits for security and privacy if parent is leaked +hardening has benefits for security and privacy if parent extended public key is known, public keys of child of hardened indexes can not be computed. +hardened indexes in case some extended public key leaks at some level, protects the sub trees (of course this has no impact if private keys leak) + ### API not exposing private keys From af6f7267449665637d5f4db90b9e6d9e62bf7c14 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 20 Feb 2019 18:17:42 +0100 Subject: [PATCH 06/92] draft --- EIPS/eip-draft_app_keys.md | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index caee43467e77e2..16fcc07e312f6b 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -177,7 +177,7 @@ depending on user choice, user will be prompted for signing confirmations or not ### Global HD methods: none -### Ethereum methods: +### Ethereum accounts methods: hdSubPath with uint under 0x80000000, 31 bits should follow bip32 @@ -187,12 +187,18 @@ can be writen in hex or int * appKey_eth_getPublicKey(hdSubPath) returns 64 bytes 0x80b994e25fb98f69518b1a03e59ddf4494a1a86cc66019131a732ff4a85108fbb86491e2bc423b2cdf6f1f0f4468ec73db0535a1528ca192d975116899289a4b +* appKey_eth_getAddress(hdSubPath) returns 20 bytes +hdSubPath: string +"index_i / index_(i+1) '", can use hardening +e.g. 0x9df77328a2515c6d529bae90edf3d501eaaa268e + * appKey_eth_derivePublicKeyFromParent(parentPublicKey, hdSubPath) returns 64 bytes -hdSubPath should not be hardened +hdSubPath: string should not be hardened -* appKey_eth_getAddress(hdSubPath) returns 20 bytes -hdSubPath: "index_i / index_(i+1) '", can use hardening -e.g. 0x 9d f7 73 28 a2 51 5c 6d 52 9b ae 90 ed f3 d5 01 ea aa 26 8e +* appKey_eth_getAddressForPublicKey(publicKey) returns 20 bytes +publicKey 64 bytes + +### Ethereum signing methods: * appKey_eth_signTransaction(fromAddress, tx) tx is ethereum-js tx object @@ -219,14 +225,13 @@ Store in MetaMask localdb, specific store for plugin ## Rationale -### Isolated paths but customisables +### Isolated paths but customisable ### persona isolation for privacy ### hardening for privacy hardening has benefits for security and privacy if parent extended public key is known, public keys of child of hardened indexes can not be computed. -hardened indexes in case some extended public key leaks at some level, protects the sub trees (of course this has no impact if private keys leak) - +hardened indexes in case some extended public key leaks at some previous level of the tree, protects the sub trees (of course this has no impact if private keys leak) ### API not exposing private keys From 9e817cf43885651172a5ea920cf35a02bd63f74f Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 20 Feb 2019 18:19:45 +0100 Subject: [PATCH 07/92] draft --- EIPS/eip-draft_app_keys.md | 33 ++++++++++++++++++--------------- 1 file changed, 18 insertions(+), 15 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 16fcc07e312f6b..5d86e992f716a0 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -128,7 +128,23 @@ hardened Since each derivation step only has 31 bits we will decompose the domain's hash as several path indexes, first as hex bytes then parsed as integers -if we use an eth address of 20 bytes, 160 bits +if we use an `ENS namehash` 32 bytes, 256 bits + +0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0 + +``` +x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 +``` +where `x0` to `x7` are 30 bits and `x8` 16 bits + +equal length would be 16 * 16 bits + +or 16 * 2 bytes, cleanest: +4f5b 8127 89fc 606b e1b3 b169 08db 13fc 7a9a df7c a726 41f8 4d75 b470 69d3 d7f0 + + + +The same reasoning, if we use an `eth address` of 20 bytes, 160 bits ``` x = x0 || x1 || x2 || x3 || x4 || x5 @@ -148,22 +164,9 @@ x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 where `x0` to `x7` are 20 bits. -if we use an ENS namehash 32 bytes, 256 bits - -0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0 - -``` -x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 -``` -where `x0` to `x7` are 30 bits and `x8` 16 bits - -equal length would be 16 * 16 bits - -or 16 * 2 bytes, cleanest: -4f5b 8127 89fc 606b e1b3 b169 08db 13fc 7a9a df7c a726 41f8 4d75 b470 69d3 d7f0 does not seem to really matter which we pick between the 2 decomposition approaches, -Maybe favor the one that leads to less indexes +Maybe favor the one that leads to less indexes, less computations alternative has the benefit of being much cleaner, especially for the 256 bits decompositions ## API: From 9eb88fe3cc5d6a7716e2223d0e8cd912b4651eee Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 20 Feb 2019 18:21:24 +0100 Subject: [PATCH 08/92] draft --- EIPS/eip-draft_app_keys.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 5d86e992f716a0..a0a2796966c8f2 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -30,12 +30,12 @@ We propose this EIP as an ERC such that our community can aggree on a standard t ## Motivation -Wallets have aggreed on a derivation path for eth accounts using BIP32, BIP44, SLIP44, ERC85 (https://github.com/ethereum/EIPs/issues/85) +Wallets have aggreed on a derivation path for eth accounts using BIP32, BIP44, SLIP44, ERC84 (https://github.com/ethereum/EIPs/issues/84) Web3 (browser) wallets have implemented in a roughly similar way the rpc eth api. EIP 1102 introduced privacy through non automatic opt-in of a wallet account into an app increasing privacy. But several limitations remain to allow for a proper UX of the crypto permissioned web. -Most current wallets don't allow for +Most current wallets don't allow for: * offline transaction signing without broadcasting of txes while still being able to perform other transaction signing * being able to sign without prompting the user From 45014be3bc55b04b9a1225efc1a6aeb02e654307 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 20 Feb 2019 18:26:22 +0100 Subject: [PATCH 09/92] draft --- EIPS/eip-draft_app_keys.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index a0a2796966c8f2..912a1abf7c6149 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -3,13 +3,13 @@ eip: title: ERC - App Keys: domain specific accounts author: Vincent Eli @Bunjin vincent.eli@gmail.com -Dan Finley @DanFinley +Dan Finlay @DanFinlay discussions-to: status: Draft type: Standards Track category: ERC created: 2019-02-20 -requires (*optional): +requires (*optional): BIP32 replaces (*optional): --- @@ -30,7 +30,7 @@ We propose this EIP as an ERC such that our community can aggree on a standard t ## Motivation -Wallets have aggreed on a derivation path for eth accounts using BIP32, BIP44, SLIP44, ERC84 (https://github.com/ethereum/EIPs/issues/84) +Wallets have agreed on a derivation path for eth accounts using BIP32, BIP44, SLIP44, ERC84 (https://github.com/ethereum/EIPs/issues/84) Web3 (browser) wallets have implemented in a roughly similar way the rpc eth api. EIP 1102 introduced privacy through non automatic opt-in of a wallet account into an app increasing privacy. But several limitations remain to allow for a proper UX of the crypto permissioned web. @@ -278,18 +278,16 @@ For apps that registered their user using main accounts eth addresses, they need ## Test Cases -## Examples: -token contract: -https://github.com/ethereum/EIPs/issues/85 ## Implementation WIP Link to hdkeyring methods -## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). +## Examples: +token contract: +https://github.com/ethereum/EIPs/issues/85 ## Acknowledgements Liam @@ -297,6 +295,8 @@ ricmoo jeff coleman for discussions about the domain's hd path +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). ## Sources: From b72bdccb61ee8c1ed71bd1d22e2fe9e08b67ba6a Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 20 Feb 2019 18:35:06 +0100 Subject: [PATCH 10/92] draft --- EIPS/eip-draft_app_keys.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 912a1abf7c6149..c21c0f7db84260 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -110,9 +110,10 @@ BIP 44 for eth: https://github.com/ethereum/EIPs/issues/84 and https://github.co not stricly BIP44 because of cointype should be a number between 0 and 2^31. eth: -m/44'/60'/a'/0/n +`m/44'/60'/a'/0/n` +where a is a set of account number and n is the account index -m/[EIP#]'/[persona path]'/[domain uid path]'/[domain custom subpath] +`m/ [EIP#]' / [persona path]' / [domain uid path]' / [domain custom subpath]` where EIP#, we use a different path than 44 since it's not bip44, not sure if there is a list of alternative standards @@ -140,6 +141,7 @@ where `x0` to `x7` are 30 bits and `x8` 16 bits equal length would be 16 * 16 bits or 16 * 2 bytes, cleanest: + 4f5b 8127 89fc 606b e1b3 b169 08db 13fc 7a9a df7c a726 41f8 4d75 b470 69d3 d7f0 @@ -169,6 +171,14 @@ does not seem to really matter which we pick between the 2 decomposition approac Maybe favor the one that leads to less indexes, less computations alternative has the benefit of being much cleaner, especially for the 256 bits decompositions +### Example HD paths for app keys: +EIP#: 12345 +personaPath: 0 +uid: 4f5b 8127 89fc 606b e1b3 b169 08db 13fc 7a9a df7c a726 41f8 4d75 b470 69d3 d7f0 +app custom path params: (entirely customisable by app under BIP32 standard) app_version set_of_accounts_index, change_index, account_index + +`m/0'/12345'/4f5b'/8127'/89fc'/606b'/e1b3'/b169'/08db'/13fc'/7a9a'/df7c'/a726'/41f8'/4d75'/b470'/69d3'/d7f0'/app_version'/a'/0/n` + ## API: ### App keys exposure: From bdb8772627283ae55bc79b64134eda1d94c7ba0e Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 20 Feb 2019 19:01:40 +0100 Subject: [PATCH 11/92] draft --- EIPS/eip-draft_app_keys.md | 27 +++++++++++++++++++++++---- 1 file changed, 23 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index c21c0f7db84260..2ee9c07a6ffc4a 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -102,6 +102,10 @@ we also add a authorEthAddress metadatafield that can be used to authenticate me We allow the user to use different personas in combination to her mnemonic to potentially fully isolate her interact with a given app accross personas. One can use this for instance to create a personal and business profile for a given's domain both backup up from the same mnemonic, using 2 different personnas indexes. The app or domain, will not be aware that it is the same person and mnemonic behind both. +We use a string following BIP32 format (can be hardened) to define personas + +e.g. `0'` or `0'/1/2'/0` + ### HD path requires BIP 32 and BIP 39 @@ -183,8 +187,11 @@ app custom path params: (entirely customisable by app under BIP32 standard) app_ ### App keys exposure: wallet.appkeys.enable() + uses the persona selected by the user (not shared with app) + uses the domain ens hash that was resolved to load window + depending on user choice, user will be prompted for signing confirmations or not for those app keys ### Global HD methods: @@ -192,9 +199,13 @@ none ### Ethereum accounts methods: hdSubPath + with uint under 0x80000000, 31 bits + should follow bip32 + can be hardened + can be writen in hex or int * appKey_eth_getPublicKey(hdSubPath) returns 64 bytes @@ -273,10 +284,13 @@ same benefits of privacy could be implemented by add an user provided field in t ==> personas seem better -### Alternatives about domain's authentification +### Alternatives about domain's identification and authentification domain's UID: Alternative spec, eth author address and including a signed message challenge for author for authentication 0x9df77328a2515c6d529bae90edf3d501eaaa268e +However, using ens hashing scheme doesn't restrict us to use ens format for name strings. +For authentication we use ENS resolution, but once first resolution is done we could use some metadata param address for ethereum less authentication. + ## Backwards Compatibility @@ -300,9 +314,14 @@ token contract: https://github.com/ethereum/EIPs/issues/85 ## Acknowledgements -Liam -ricmoo -jeff coleman +MetaMask team + +Liam Horne + +Richard Moore + +Jeff Coleman + for discussions about the domain's hd path ## Copyright From 6fdc47894c3ac02c769e4b8cbf8d0bbda3a4984c Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 11:03:35 +0100 Subject: [PATCH 12/92] draft --- EIPS/eip-draft_app_keys.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 2ee9c07a6ffc4a..8aac0f495e2a6f 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -2,7 +2,7 @@ eip: title: ERC - App Keys: domain specific accounts author: -Vincent Eli @Bunjin vincent.eli@gmail.com +Vincent Eli @Bunjin Dan Finlay @DanFinlay discussions-to: status: Draft @@ -135,7 +135,10 @@ Since each derivation step only has 31 bits we will decompose the domain's hash if we use an `ENS namehash` 32 bytes, 256 bits -0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0 +foo.bar.eth +gives a namehash of: +0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 + ``` x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 @@ -144,11 +147,15 @@ where `x0` to `x7` are 30 bits and `x8` 16 bits equal length would be 16 * 16 bits -or 16 * 2 bytes, cleanest: - -4f5b 8127 89fc 606b e1b3 b169 08db 13fc 7a9a df7c a726 41f8 4d75 b470 69d3 d7f0 - +or 16 * 2 bytes, cleanest and favorite spec: +``` +foo.bar.eth +0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 +6033 644d 673b 47b3 bea0 4e79 bbe0 6d78 ce76 b8be 2fb8 704f 9c2a 80fd 139c 81d3 +6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3' +24627'/25677'/26427'/18355'/48800'/20089'/48096'/28024'/52854'/47294'/12216'/28751'/39978'/33021'/5020'/33235' +``` The same reasoning, if we use an `eth address` of 20 bytes, 160 bits From 4b86b677f0798f378c268b8c457d2ddda08f5adb Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 11:07:25 +0100 Subject: [PATCH 13/92] draft --- EIPS/eip-draft_app_keys.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 8aac0f495e2a6f..8581eb7b96dc8a 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -133,21 +133,25 @@ hardened Since each derivation step only has 31 bits we will decompose the domain's hash as several path indexes, first as hex bytes then parsed as integers -if we use an `ENS namehash` 32 bytes, 256 bits +If for the domain uid we use an `ENS namehash` of 32 bytes, 256 bits -foo.bar.eth -gives a namehash of: -0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 +e.g. `foo.bar.eth` gives namehash +`0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3` + +We can decompose it in several ways, here are 2 ways: +-approach that favors having the least indexes ``` x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 ``` where `x0` to `x7` are 30 bits and `x8` 16 bits -equal length would be 16 * 16 bits - -or 16 * 2 bytes, cleanest and favorite spec: +-approach that favors an homogenous decomposition: +equal length would be 16 * 16 bits or in other words 16 * 2 bytes, cleanest and favorite spec: +``` +x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 || x9 || x10 || x11 || x12 || x13 || x14 || x15 +``` ``` foo.bar.eth From 2727b581b7cfd71edae9b88f2a130abf2f49997c Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 11:11:15 +0100 Subject: [PATCH 14/92] draft --- EIPS/eip-draft_app_keys.md | 29 +++++++++++++++++------------ 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 8581eb7b96dc8a..0a8564cb278495 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -51,9 +51,10 @@ These new app keys should allow to give more power and flexibility to the crypto ## Specification -### Domains +### Apps -A domain is an app that would like to request access to app keys, crypto app, eth but not only. +An app is a website (or other) that would like to request access to app keys, crypto app, eth but not only. +We map uniquely apps to their domains (ens domain but can be other). #### Domain's UID ens domain @@ -117,7 +118,7 @@ eth: `m/44'/60'/a'/0/n` where a is a set of account number and n is the account index -`m/ [EIP#]' / [persona path]' / [domain uid path]' / [domain custom subpath]` +`m/ [EIP#]' / [persona path]' / [app's domain uid path]' / [app's custom subpath]` where EIP#, we use a different path than 44 since it's not bip44, not sure if there is a list of alternative standards @@ -186,6 +187,19 @@ does not seem to really matter which we pick between the 2 decomposition approac Maybe favor the one that leads to less indexes, less computations alternative has the benefit of being much cleaner, especially for the 256 bits decompositions +### App custom sub path + +hdSubPath + +with uint under 0x80000000, 31 bits + +should follow bip32 + +can be hardened + +can be writen in hex or int + + ### Example HD paths for app keys: EIP#: 12345 personaPath: 0 @@ -209,15 +223,6 @@ depending on user choice, user will be prompted for signing confirmations or not none ### Ethereum accounts methods: -hdSubPath - -with uint under 0x80000000, 31 bits - -should follow bip32 - -can be hardened - -can be writen in hex or int * appKey_eth_getPublicKey(hdSubPath) returns 64 bytes 0x80b994e25fb98f69518b1a03e59ddf4494a1a86cc66019131a732ff4a85108fbb86491e2bc423b2cdf6f1f0f4468ec73db0535a1528ca192d975116899289a4b From d4f44b3c84cd5cba567e595bab5df1ecfc440827 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 17:04:18 +0100 Subject: [PATCH 15/92] draft --- EIPS/eip-draft_app_keys.md | 55 ++++++++++++++++++++++++++------------ 1 file changed, 38 insertions(+), 17 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 0a8564cb278495..3c515d7c499225 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -9,7 +9,7 @@ status: Draft type: Standards Track category: ERC created: 2019-02-20 -requires (*optional): BIP32 +requires (*optional): BIP32, EIP137, EIP165, replaces (*optional): --- @@ -86,13 +86,26 @@ keccak256(‘eth’) = 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47 Normalising and validating names Before a name can be converted to a node hash using Namehash, the name must first be normalised and checked for validity - for instance, converting fOO.eth into foo.eth, and prohibiting names containing forbidden characters such as underscores. It is crucial that all applications follow the same set of rules for normalisation and validation, as otherwise two users entering the same name on different systems may resolve the same human-readable name into two different ENS names. ``` +We thus propose to use the node of each app's domain as a unique identifier for each app. + See alternative specs in rationale below. #### Domain's authentication Load window or script through ens resolution -using for instance this resolver. +using for instance this resolver profile defined in EIP 634 that permits the lookup of arbitrary key-value text data. +https://eips.ethereum.org/EIPS/eip-634 + +``` +A new resolver interface is defined, consisting of the following method: + +function text(bytes32 node, string key) constant returns (string text); +The interface ID of this interface is 0x59d1d43c. + +The text data may be any arbitrary UTF-8 string. If the key is not present, the empty string must be returned. +``` + we either point the name to a string or use metadatafields if it points to an address @@ -211,11 +224,12 @@ app custom path params: (entirely customisable by app under BIP32 standard) app_ ## API: ### App keys exposure: -wallet.appkeys.enable() -uses the persona selected by the user (not shared with app) +* `wallet.appkey.enable()` + +uses the persona selected by the user (not known nor shared with app) -uses the domain ens hash that was resolved to load window +uses the domain ens namehash (node) that was resolved to load window (not by app) depending on user choice, user will be prompted for signing confirmations or not for those app keys @@ -224,43 +238,43 @@ none ### Ethereum accounts methods: -* appKey_eth_getPublicKey(hdSubPath) returns 64 bytes +* `appKey_eth_getPublicKey(hdSubPath) returns 64 bytes` 0x80b994e25fb98f69518b1a03e59ddf4494a1a86cc66019131a732ff4a85108fbb86491e2bc423b2cdf6f1f0f4468ec73db0535a1528ca192d975116899289a4b -* appKey_eth_getAddress(hdSubPath) returns 20 bytes +* `appKey_eth_getAddress(hdSubPath) returns 20 bytes` hdSubPath: string "index_i / index_(i+1) '", can use hardening e.g. 0x9df77328a2515c6d529bae90edf3d501eaaa268e -* appKey_eth_derivePublicKeyFromParent(parentPublicKey, hdSubPath) returns 64 bytes +* `appKey_eth_derivePublicKeyFromParent(parentPublicKey, hdSubPath) returns 64 bytes` hdSubPath: string should not be hardened -* appKey_eth_getAddressForPublicKey(publicKey) returns 20 bytes +* `appKey_eth_getAddressForPublicKey(publicKey) returns 20 bytes` publicKey 64 bytes ### Ethereum signing methods: -* appKey_eth_signTransaction(fromAddress, tx) +* `appKey_eth_signTransaction(fromAddress, tx)` tx is ethereum-js tx object -* appKey_eth_sign(fromAddress, message) -* appKey_eth_personalSign(fromAddress, message) -* appKey_eth_signTypedMessage(fromAddress, message) +* `appKey_eth_sign(fromAddress, message)` +* `appKey_eth_personalSign(fromAddress, message)` +* `appKey_eth_signTypedMessage(fromAddress, message)` ### Other potential methods: #### other cryptocurrencies #### other crypto -* **encrypt(uint index, data) return bytes** +* `encrypt() [TBD]` Request Encryption -* **decrypt(uint index, bytes) return data** +* `decrypt() [TBD]` Request Decryption #### cross domain communication / signing #### storage -* **persistInDb(key, data)**: +* `persistInDb(key, data) [TBD] `: Store in MetaMask localdb, specific store for plugin -* **readInDb(key) returns data**: +* `readInDb(key) returns data [TBD] `: ## Rationale @@ -352,6 +366,13 @@ BIP 39 tool: https://iancoleman.io/bip39/#english BIP 44 for eth: https://github.com/ethereum/EIPs/issues/85, https://github.com/ethereum/EIPs/issues/84 ### ENS: +EIP137: Ethereum Domain Name Service - specification +https://github.com/ethereum/EIPs/blob/master/EIPS/eip-137.md +EIP165: Standard Interface Detection +https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md +EIP634: Storage of text record in ENS +https://github.com/ethereum/EIPs/blob/master/EIPS/eip-634.md +ENS docs about namehash: http://docs.ens.domains/en/latest/implementers.html#namehash From 56c8e8d4670a59e6561a896b160216c2a72d485b Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 17:05:45 +0100 Subject: [PATCH 16/92] draft --- EIPS/eip-draft_app_keys.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 3c515d7c499225..0494cb75066569 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -1,6 +1,6 @@ --- eip: -title: ERC - App Keys: domain specific accounts +title: App Keys: app specific accounts author: Vincent Eli @Bunjin Dan Finlay @DanFinlay @@ -18,13 +18,16 @@ replaces (*optional): Among other cryptographic applications, scalability and privacy solutions for ethereum blockchain require that an user performs a significant amount of signing operations and may also require her to watch some state and be ready to take some cryptographic action (e.g. sign a state or contest a withdraw in a state channel). The way wallets currently implement accounts poses several obstacle to the development of a complete web3.0 experience both in terms of UX, security and privacy. + This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given app (domain). We propose to call them `app keys`. These accounts allow to isolate the accounts used for each app, thus increasing privacy. They also allow to give more control to the applications developpers over accounts management and signing delegation. These app keys have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally one can use these to sign transactions without broadcasting them. + This new accounts type should allow to significantly improve UX and to allow for new designs for apps of the crypto permissionned web. ## Abstract In a wallet, an user often holds most of her funds in her main accounts. These accounts require a significant level of security and should not be delegated in any way, this significantly impacts the design of crypto apps if a user has to manually confirm every transaction. Also often an user uses the same accounts accross apps, which is a privacy and potentially also a security issue. We introduce here a new account type, app keys that allow for signing delegation and accounts isolation accross domains for privacy and security. + We specify how to uniquely define each domain, authenticate a request to use a given domain's app keys, how to derive the accounts along an HDpath restricted for the domain and we finally define an API to derive and use these app keys. We propose this EIP as an ERC such that our community can aggree on a standard that would allow for cross wallet and cross app compatibility while fitting most needs. @@ -32,6 +35,7 @@ We propose this EIP as an ERC such that our community can aggree on a standard t Wallets have agreed on a derivation path for eth accounts using BIP32, BIP44, SLIP44, ERC84 (https://github.com/ethereum/EIPs/issues/84) Web3 (browser) wallets have implemented in a roughly similar way the rpc eth api. + EIP 1102 introduced privacy through non automatic opt-in of a wallet account into an app increasing privacy. But several limitations remain to allow for a proper UX of the crypto permissioned web. @@ -54,6 +58,7 @@ These new app keys should allow to give more power and flexibility to the crypto ### Apps An app is a website (or other) that would like to request access to app keys, crypto app, eth but not only. + We map uniquely apps to their domains (ens domain but can be other). #### Domain's UID From 1d391e4d42d55abf9e7b4cb4a91e6f4550c83c54 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 17:28:58 +0100 Subject: [PATCH 17/92] references --- EIPS/eip-draft_app_keys.md | 42 +++++++++++++++++++++++++++++++------- 1 file changed, 35 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 0494cb75066569..e6477361dd4050 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -129,10 +129,14 @@ e.g. `0'` or `0'/1/2'/0` ### HD path requires BIP 32 and BIP 39 derives from BIP44 and EIP -BIP 44 for eth: https://github.com/ethereum/EIPs/issues/84 and https://github.com/ethereum/EIPs/issues/85 +BIP 44 for eth: +https://github.com/ethereum/EIPs/issues/84 +https://github.com/ethereum/EIPs/issues/85 +https://github.com/ethereum/EIPs/pull/600 +https://github.com/ethereum/EIPs/pull/601 not stricly BIP44 because of cointype should be a number between 0 and 2^31. -eth: +most frequently used eth derivation path `m/44'/60'/a'/0/n` where a is a set of account number and n is the account index @@ -327,6 +331,14 @@ However, using ens hashing scheme doesn't restrict us to use ens format for name For authentication we use ENS resolution, but once first resolution is done we could use some metadata param address for ethereum less authentication. +### Allowing app keys to derive any subpath and index, even if preivous ones by enumeration are empty + +problem apps won't be able to restore by enumeration +but if they do that to derive accounts maybe it's on purpose and they may backup this data somewhere +Also maybe wallets wants to include an address gap limit for the derivation by enumeration when importing +https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit + + ## Backwards Compatibility No incompatibity since these are separate accounts @@ -362,13 +374,28 @@ for discussions about the domain's hd path ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -## Sources: +## References: ### HD and mnemonics -BIP 32 specs, Hierarchical Deterministic Wallets: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki -BIP 39 specs, Mnemonic code for generating deterministic keys: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki -BIP 39 tool: https://iancoleman.io/bip39/#english -BIP 44 for eth: https://github.com/ethereum/EIPs/issues/85, https://github.com/ethereum/EIPs/issues/84 +#### BIPS: +BIP 32 specs, Hierarchical Deterministic Wallets: +https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki +BIP 39 specs, Mnemonic code for generating deterministic keys: +https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki +BIP44: Multi-Account Hierarchy for Deterministic Wallets +https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit +SLIP44: Registered coin types for BIP-0044 +https://github.com/satoshilabs/slips/blob/master/slip-0044.md + + +#### Derivation path for eth: +https://github.com/ethereum/EIPs/issues/84 +https://github.com/ethereum/EIPs/issues/85 +https://github.com/ethereum/EIPs/pull/600 +Ethereum hierarchy for deterministic wallets - +https://github.com/ethereum/EIPs/pull/601 + + ### ENS: EIP137: Ethereum Domain Name Service - specification @@ -382,6 +409,7 @@ http://docs.ens.domains/en/latest/implementers.html#namehash # Notes: +BIP 39 tool: https://iancoleman.io/bip39/#english - In Hd Paths, Merge app controlled subset and account index ? From 2d9c904c724b038069db7ee1128799e7d4061a91 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 19:37:22 +0100 Subject: [PATCH 18/92] references --- EIPS/eip-draft_app_keys.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index e6477361dd4050..a442b95024a343 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -10,7 +10,7 @@ type: Standards Track category: ERC created: 2019-02-20 requires (*optional): BIP32, EIP137, EIP165, -replaces (*optional): +replaces (*optional): EIP 1581 --- @@ -330,6 +330,17 @@ domain's UID: Alternative spec, eth author address and including a signed messag However, using ens hashing scheme doesn't restrict us to use ens format for name strings. For authentication we use ENS resolution, but once first resolution is done we could use some metadata param address for ethereum less authentication. +Replaces this EIP 1581: Non-wallet usage of keys derived from BIP-32 trees +https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4 +https://eips.ethereum.org/EIPS/eip-1581 + +Benefit of our approach: +More englobing (personas among other) +Does not require a centrally maintained registry. In our approach every app has already a domain assigned to it. + +One possibility would be to keep only the first xxx bytes of the node + + ### Allowing app keys to derive any subpath and index, even if preivous ones by enumeration are empty From 2d8b73d1aac129fd75881c32aa7525b472256e3e Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 19:49:02 +0100 Subject: [PATCH 19/92] references --- EIPS/eip-draft_app_keys.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index a442b95024a343..369125373613fa 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -17,19 +17,20 @@ replaces (*optional): EIP 1581 ## Simple Summary -Among other cryptographic applications, scalability and privacy solutions for ethereum blockchain require that an user performs a significant amount of signing operations and may also require her to watch some state and be ready to take some cryptographic action (e.g. sign a state or contest a withdraw in a state channel). The way wallets currently implement accounts poses several obstacle to the development of a complete web3.0 experience both in terms of UX, security and privacy. +Among others cryptographic applications, scalability and privacy solutions for ethereum blockchain require that an user performs a significant amount of signing operations. It may also require her to watch some state and be ready to sign data automatically (e.g. sign a state or contest a withdraw in a state channel). The way wallets currently implement accounts poses several obstacles to the development of a complete web3.0 experience both in terms of UX, security and privacy. -This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given app (domain). We propose to call them `app keys`. These accounts allow to isolate the accounts used for each app, thus increasing privacy. They also allow to give more control to the applications developpers over accounts management and signing delegation. These app keys have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally one can use these to sign transactions without broadcasting them. +This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given app. We propose to call them `app keys`. These accounts allow to isolate the accounts used for each app, thus increasing privacy. They also allow to give more control to the applications developpers over accounts management and signing delegation. For these app keys, wallets can have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally wallet can also implement a different behavior such as allowing to sign transactions without broadcasting them. -This new accounts type should allow to significantly improve UX and to allow for new designs for apps of the crypto permissionned web. +This new accounts type can allow to significantly improve UX and permit new designs for apps of the crypto permissionned web. ## Abstract In a wallet, an user often holds most of her funds in her main accounts. These accounts require a significant level of security and should not be delegated in any way, this significantly impacts the design of crypto apps if a user has to manually confirm every transaction. Also often an user uses the same accounts accross apps, which is a privacy and potentially also a security issue. -We introduce here a new account type, app keys that allow for signing delegation and accounts isolation accross domains for privacy and security. -We specify how to uniquely define each domain, authenticate a request to use a given domain's app keys, how to derive the accounts along an HDpath restricted for the domain and we finally define an API to derive and use these app keys. -We propose this EIP as an ERC such that our community can aggree on a standard that would allow for cross wallet and cross app compatibility while fitting most needs. +We introduce here a new account type, app keys, which permits signing delegation and accounts isolation accross apps for privacy and security. + +In this EIP, we provide a proposal how to uniquely identify and authenticate each app, how to derive the accounts along an HDpath restricted for the domain and we finally define an API for apps to derive and use these app keys. +This ERC aims at finding a standard that will fit the needs of wallets and application developers while also allowing app keys to be used across wallets and yield the same accounts for the user for each app. ## Motivation From b84f5641165d2df62cec57d6df4db78c2019b87e Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 20:51:11 +0100 Subject: [PATCH 20/92] draft --- EIPS/eip-draft_app_keys.md | 114 ++++++++++++++++++++++--------------- 1 file changed, 69 insertions(+), 45 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 369125373613fa..bd22bacf6fa7c2 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -34,23 +34,20 @@ This ERC aims at finding a standard that will fit the needs of wallets and appli ## Motivation -Wallets have agreed on a derivation path for eth accounts using BIP32, BIP44, SLIP44, ERC84 (https://github.com/ethereum/EIPs/issues/84) -Web3 (browser) wallets have implemented in a roughly similar way the rpc eth api. +Wallets developers have agreed on an HD derivation path for ethereum accounts using BIP32, BIP44, SLIP44, [ERC84](https://github.com/ethereum/EIPs/issues/84). Web3 wallets have implemented in a roughly similar way the rpc eth api. EIP 1102 introduced privacy through non automatic opt-in of a wallet account into an app increasing privacy. -EIP 1102 introduced privacy through non automatic opt-in of a wallet account into an app increasing privacy. -But several limitations remain to allow for a proper UX of the crypto permissioned web. +However several limitations remain in order to allow for a proper designs and UX for crypto permissioned apps. -Most current wallets don't allow for: - -* offline transaction signing without broadcasting of txes while still being able to perform other transaction signing -* being able to sign without prompting the user -* be able to use throwable keys to improve anonymity -* being able to automatically and effortlessly use different keys / accounts for each apps +Most of UI based current wallets don't allow to: +* being able to automatically and effortlessly use different keys / accounts for each apps, +* being able to sign some app's action without prompting the user with the same level of security as sending funds from their main accounts, +* being able to use throwable keys to improve anonymity, +* effortlessly signing transactions for an app without broadcasting these while still being able to perform other transaction signing as usual from their main accounts, * All this while being fully restorable using the user's mnemonic or hardware wallet and the HD Path determined uniquely by the app's ens name. -We try to solve this by introducing a new account's type, app keys made to be used along side the existing main accounts. +We try to overcome these limitations by introducing a new account's type, app keys, made to be used along side the existing main accounts. -These new app keys should allow to give more power and flexibility to the crypto apps developers. This should allow to improve a lot the UX of crypto dapps and allow to create new designs that were not possible before leveraging on the ability to create and handle many accounts, to presign messages and broadcast them later. These features were not compatible with the level of security we were requesting for main accounts that hold most of an user's funds. +These new app keys can permit to give more power and flexibility to the crypto apps developers. This can allow to improve a lot the UX of crypto dapps and to create new designs that were not possible before leveraging the ability to create and handle many accounts, to presign messages and broadcast them later. These features were not compatible with the level of security we were requesting for main accounts that hold most of an user's funds. ## Specification @@ -58,21 +55,39 @@ These new app keys should allow to give more power and flexibility to the crypto ### Apps -An app is a website (or other) that would like to request access to app keys, crypto app, eth but not only. +An app is a website (or other) that would like to request from a wallet to access app keys. It can be any form of cryptography/identity relying application, ethereum but not only. + +#### Apps' Unique Identifiers -We map uniquely apps to their domains (ens domain but can be other). +We need a way to uniquely identify each App. -#### Domain's UID -ens domain -namehash node +In our favored spec, each app is uniquely defined and authentified by its name, an ens domain string (e.g. foo.bar.eth). +Note that this favored spec does not restrict the apps' names to be following the .eth standard. There are a few restrictions however on the characters used and normalisation, following the [ENS Specs](http://docs.ens.domains/en/latest/implementers.html#namehash), reproduced below for convinience and reference. +In addition there must be a maximum size to the domain string that we need to determine such that the mapping from strings to nodes remains injective. +NamePrep Algorithm: +https://tools.ietf.org/html/rfc3491 + +From ENS specs +``` +Normalising and validating names +Before a name can be converted to a node hash using Namehash, the name must first be normalised and checked for validity - for instance, converting fOO.eth into foo.eth, and prohibiting names containing forbidden characters such as underscores. It is crucial that all applications follow the same set of rules for normalisation and validation, as otherwise two users entering the same name on different systems may resolve the same human-readable name into two different ENS names. +``` + + +The ENS can also allow to register and resolve metadata for the app such as url, parameters, + +Ens defines an hashing scheme to associate a domain to a unique hash, `node`, through the `namehash` function + +This gives an unique identifier (UID) of 32 bytes. + +``` +e.g. for foo.bar.eth +app's uid 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 +``` -Favored spec, ENS name hash and resolving url through ens -bytes32 e.g. 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0 -ENS Specs -http://docs.ens.domains/en/latest/implementers.html#namehash ``` domain - the complete, human-readable form of a name; eg, ‘vitalik.wallet.eth’. @@ -89,19 +104,19 @@ namehash([label, …]) = keccak256(namehash(…), keccak256(label)) keccak256(‘eth’) = 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47069d3d7f0 -Normalising and validating names -Before a name can be converted to a node hash using Namehash, the name must first be normalised and checked for validity - for instance, converting fOO.eth into foo.eth, and prohibiting names containing forbidden characters such as underscores. It is crucial that all applications follow the same set of rules for normalisation and validation, as otherwise two users entering the same name on different systems may resolve the same human-readable name into two different ENS names. ``` -We thus propose to use the node of each app's domain as a unique identifier for each app. -See alternative specs in rationale below. +We thus propose to use the node of each app's domain as a unique identifier for each app but one can think of other UIDs, see the alternative specs mentionned in the `Rationale` section below. + +#### App's authentication + +In the case of the favored apps' UID specs using ENS, we can authenticate the app through ens resolution. -#### Domain's authentication +If we use for instance this resolver profile defined in [EIP 634](https://eips.ethereum.org/EIPS/eip-634) which permits the lookup of arbitrary key-value text data, we can for instance use the keys `url` to point to a website. + +One can think of other authentification methods and use them alongside the url-resolution method through ENS. We mention other methods in the `Rationale` -Load window or script through ens resolution -using for instance this resolver profile defined in EIP 634 that permits the lookup of arbitrary key-value text data. -https://eips.ethereum.org/EIPS/eip-634 ``` A new resolver interface is defined, consisting of the following method: @@ -324,23 +339,33 @@ same benefits of privacy could be implemented by add an user provided field in t ==> personas seem better -### Alternatives about domain's identification and authentification +### Alternatives for App identification + +Current approach uses identification through an ENS name converted to a hash node and sliced fully but one could keep only the first xxx bytes of the node and slice them similarly. This may increase the change of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to bytes32. + domain's UID: Alternative spec, eth author address and including a signed message challenge for author for authentication 0x9df77328a2515c6d529bae90edf3d501eaaa268e -However, using ens hashing scheme doesn't restrict us to use ens format for name strings. -For authentication we use ENS resolution, but once first resolution is done we could use some metadata param address for ethereum less authentication. - -Replaces this EIP 1581: Non-wallet usage of keys derived from BIP-32 trees +Replaces [EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4 -https://eips.ethereum.org/EIPS/eip-1581 - Benefit of our approach: More englobing (personas among other) Does not require a centrally maintained registry. In our approach every app has already a domain assigned to it. -One possibility would be to keep only the first xxx bytes of the node +### Alternatives for App authentification + +For authentication we use ENS resolution, and browsing to a given url resolved +With ENS resolution and authentification homoglyph attack is not a problem since it will not leak kees from one domain to another. + +Caveats +* First connection requires the wallet to connect to ethereum mainnet, but once first resolution is done we could use some metadata param address for ethereum less authentication of the app (eg. app server signs a challenge message with the author address resolved in the ENS metadata) +* ENS resolution can change without the user knowing and then a different app/website may be granted access to his app keys. But this means the ENS name owner address was copromised. This would be similar to using a signing challenge authentified by a known public key. If this known public key is compromised we have a similar problem. +Other metadata resolution through ENS that can be used alongside: +* author address: already mentionned above +* contract address: For app keys that would be designed to interact with a given ethereum contract (for instance app keys for a given token, if one desires to do so), other metadata fields could be used such as contract addresses. + +Alternative specs could ### Allowing app keys to derive any subpath and index, even if preivous ones by enumeration are empty @@ -390,14 +415,10 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ### HD and mnemonics #### BIPS: -BIP 32 specs, Hierarchical Deterministic Wallets: -https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki -BIP 39 specs, Mnemonic code for generating deterministic keys: -https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki -BIP44: Multi-Account Hierarchy for Deterministic Wallets -https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit -SLIP44: Registered coin types for BIP-0044 -https://github.com/satoshilabs/slips/blob/master/slip-0044.md +[BIP 32 specs, Hierarchical Deterministic Wallets:](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) +[BIP 39 specs, Mnemonic code for generating deterministic keys:](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) +[BIP44: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit) +[SLIP44: Registered coin types for BIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) #### Derivation path for eth: @@ -419,6 +440,9 @@ https://github.com/ethereum/EIPs/blob/master/EIPS/eip-634.md ENS docs about namehash: http://docs.ens.domains/en/latest/implementers.html#namehash +### Previous proposals related to app keys +[EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) +https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4 # Notes: BIP 39 tool: https://iancoleman.io/bip39/#english From c8a4313f6b362019e65806726cad8338e04555e7 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 20:53:27 +0100 Subject: [PATCH 21/92] draft --- EIPS/eip-draft_app_keys.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index bd22bacf6fa7c2..4003c09a08fccc 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -312,6 +312,8 @@ Store in MetaMask localdb, specific store for plugin hardening has benefits for security and privacy if parent extended public key is known, public keys of child of hardened indexes can not be computed. hardened indexes in case some extended public key leaks at some previous level of the tree, protects the sub trees (of course this has no impact if private keys leak) +However the app can use non hardened indexes in their custom path part to be able to benefit from guessing child public keys from parent one (for instance for counterfactual state channel interaction accross 2 peers that would like to use new keys every time they counterfactually instantiate a new sub app). + ### API not exposing private keys ### Alternatives about HD derivation path From 5ac3c877f9349912f7a6e697c128b68294e98a02 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 23:06:40 +0100 Subject: [PATCH 22/92] draft --- EIPS/eip-draft_app_keys.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 4003c09a08fccc..c4d4d708a6e819 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -61,18 +61,20 @@ An app is a website (or other) that would like to request from a wallet to acces We need a way to uniquely identify each App. -In our favored spec, each app is uniquely defined and authentified by its name, an ens domain string (e.g. foo.bar.eth). -Note that this favored spec does not restrict the apps' names to be following the .eth standard. There are a few restrictions however on the characters used and normalisation, following the [ENS Specs](http://docs.ens.domains/en/latest/implementers.html#namehash), reproduced below for convinience and reference. -In addition there must be a maximum size to the domain string that we need to determine such that the mapping from strings to nodes remains injective. -NamePrep Algorithm: -https://tools.ietf.org/html/rfc3491 +In our favored spec, each app is uniquely defined and authentified by its name, a domain string. For apps to be resolved through the Ethereum Name Service (ENS), they need to be a using a .eth domain name (e.g. foo.bar.eth). Note that the proposed spec does not restrict the apps' names to be following the .eth standard but they would need to be authentified differently (see below). -From ENS specs +There are a few restrictions however on the characters used and normalisation, each name should be passed through the [NamePrep Algorithm](https://tools.ietf.org/html/rfc3491) + +In addition there must be a maximum size to the domain string that we need to determine such that the mapping from strings to nodes remains injective, to avoid collision. + +We recommand this standard to be following the [ENS Specs](http://docs.ens.domains/en/latest/implementers.html#namehash), reproduced below for convinience and reference. ``` Normalising and validating names Before a name can be converted to a node hash using Namehash, the name must first be normalised and checked for validity - for instance, converting fOO.eth into foo.eth, and prohibiting names containing forbidden characters such as underscores. It is crucial that all applications follow the same set of rules for normalisation and validation, as otherwise two users entering the same name on different systems may resolve the same human-readable name into two different ENS names. ``` +No, TLDs are restricted to only .eth (on mainnet), or .eth and .test (on Ropsten), plus any special purpose TLDs such as those required to permit reverse lookups. There are no immediate plans to invite proposals for additional TLDs. In large part this is to reduce the risk of a namespace collision with the IANA DNS namespace. + The ENS can also allow to register and resolve metadata for the app such as url, parameters, @@ -87,8 +89,6 @@ app's uid 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 - - ``` domain - the complete, human-readable form of a name; eg, ‘vitalik.wallet.eth’. label - a single component of a domain; eg, ‘vitalik’, ‘wallet’, or ‘eth’. A label may not contain a period (‘.’). From 9c53b4c06a71b702e8ca10ea738588ee597b95a7 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 23:16:05 +0100 Subject: [PATCH 23/92] draft --- EIPS/eip-draft_app_keys.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index c4d4d708a6e819..0f9cad0f8fd7ed 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -73,9 +73,6 @@ Normalising and validating names Before a name can be converted to a node hash using Namehash, the name must first be normalised and checked for validity - for instance, converting fOO.eth into foo.eth, and prohibiting names containing forbidden characters such as underscores. It is crucial that all applications follow the same set of rules for normalisation and validation, as otherwise two users entering the same name on different systems may resolve the same human-readable name into two different ENS names. ``` -No, TLDs are restricted to only .eth (on mainnet), or .eth and .test (on Ropsten), plus any special purpose TLDs such as those required to permit reverse lookups. There are no immediate plans to invite proposals for additional TLDs. In large part this is to reduce the risk of a namespace collision with the IANA DNS namespace. - - The ENS can also allow to register and resolve metadata for the app such as url, parameters, Ens defines an hashing scheme to associate a domain to a unique hash, `node`, through the `namehash` function @@ -345,14 +342,20 @@ same benefits of privacy could be implemented by add an user provided field in t Current approach uses identification through an ENS name converted to a hash node and sliced fully but one could keep only the first xxx bytes of the node and slice them similarly. This may increase the change of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to bytes32. +Should we allow names that are not .eth domains? We may want to be able to handle DNS names for instance without using an ENS proxy (ie. a .eth domain point to a DNS url). They would have to be resolved differently because ENS does not allow other TLDs. +``` +No, TLDs are restricted to only .eth (on mainnet), or .eth and .test (on Ropsten), plus any special purpose TLDs such as those required to permit reverse lookups. There are no immediate plans to invite proposals for additional TLDs. In large part this is to reduce the risk of a namespace collision with the IANA DNS namespace. +``` + domain's UID: Alternative spec, eth author address and including a signed message challenge for author for authentication 0x9df77328a2515c6d529bae90edf3d501eaaa268e Replaces [EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4 Benefit of our approach: -More englobing (personas among other) Does not require a centrally maintained registry. In our approach every app has already a domain assigned to it. +Englobing (personas among other) + ### Alternatives for App authentification From ac45d187055e59593569cc7f255795bd598be8d8 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 23:52:29 +0100 Subject: [PATCH 24/92] draft --- EIPS/eip-draft_app_keys.md | 131 ++++++++++++++++++++----------------- 1 file changed, 70 insertions(+), 61 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 0f9cad0f8fd7ed..d2415b210ab071 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -57,6 +57,28 @@ These new app keys can permit to give more power and flexibility to the crypto a An app is a website (or other) that would like to request from a wallet to access app keys. It can be any form of cryptography/identity relying application, ethereum but not only. +Once connected to a wallet, an application can request to access a set of accounts derived exclusively for that application using the hierarchical deterministic (HD) paths. + +### HD path + +requires BIP 32 and BIP 39 +derives from BIP44 and EIP + +We propose to use the following HD path for each app keys: + + +`m/ [EIP#]' / [persona path]' / [application uniquely assigned path]' / [app's custom subpath]` + + +Where: + +`EIP#` is the EIP number that will be assigned to this EIP and we harden it. We use a different path than 44' since it's not bip44 compliant. [At this point, I'm not sure if there is a list of alternative standards to BIP44 codes] +`persona path` allows to use applications with different and isolated personas (or in other words accounts) that are tracable by the application. They will still be fully restorable from the same mnemonic. +`application uniquely assigned path` isolate each application along unique branches of the tree through these unique subPath combination. +`app's custom subPath` give freedom to application to use this BIP32 compliant subPath to manage accounts and other needed parameters. + +Note that we suggest that each of these indexes, except those belonging to the app's custom subpath, must be hardened to fully isolate the public keys across personas and applications. + #### Apps' Unique Identifiers We need a way to uniquely identify each App. @@ -73,9 +95,9 @@ Normalising and validating names Before a name can be converted to a node hash using Namehash, the name must first be normalised and checked for validity - for instance, converting fOO.eth into foo.eth, and prohibiting names containing forbidden characters such as underscores. It is crucial that all applications follow the same set of rules for normalisation and validation, as otherwise two users entering the same name on different systems may resolve the same human-readable name into two different ENS names. ``` -The ENS can also allow to register and resolve metadata for the app such as url, parameters, -Ens defines an hashing scheme to associate a domain to a unique hash, `node`, through the `namehash` function + +The ENS uses an hashing scheme to associate a domain to a unique hash, `node`, through the `namehash` function This gives an unique identifier (UID) of 32 bytes. @@ -84,7 +106,7 @@ e.g. for foo.bar.eth app's uid 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 ``` - +For referenceHere are the specs of ENS: ``` domain - the complete, human-readable form of a name; eg, ‘vitalik.wallet.eth’. @@ -103,15 +125,15 @@ keccak256(‘eth’) = 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47 ``` -We thus propose to use the node of each app's domain as a unique identifier for each app but one can think of other UIDs, see the alternative specs mentionned in the `Rationale` section below. +We thus propose to use the node of each app's domain as a unique identifier for each app but one can think of other UIDs, we include some alternative specs in the `Rationale` section below. #### App's authentication -In the case of the favored apps' UID specs using ENS, we can authenticate the app through ens resolution. +In the case of our favored specification for apps' UIDs using ENS, we can authenticate the app through ens resolution. +The ENS can also allow to register and resolve metadata for the app such as `url`, and other parameters. -If we use for instance this resolver profile defined in [EIP 634](https://eips.ethereum.org/EIPS/eip-634) which permits the lookup of arbitrary key-value text data, we can for instance use the keys `url` to point to a website. +If we use for instance this resolver profile defined in [EIP 634](https://eips.ethereum.org/EIPS/eip-634) which permits the lookup of arbitrary key-value text data, we can for instance use the key `url` to point to a website. -One can think of other authentification methods and use them alongside the url-resolution method through ENS. We mention other methods in the `Rationale` @@ -124,10 +146,9 @@ The interface ID of this interface is 0x59d1d43c. The text data may be any arbitrary UTF-8 string. If the key is not present, the empty string must be returned. ``` +One can think of other authentification methods and even use some of them alongside the url-resolution method through ENS. We mention other methods in the `Rationale` section. -we either point the name to a string or use metadatafields if it points to an address - -we also add a authorEthAddress metadatafield that can be used to authenticate message from the app's dev +We suggest for instance to also add an `authorEthAddress` text metadata field that can be used to authenticate message from the app, with for instance a sign challenge. ### Personas @@ -139,42 +160,18 @@ We use a string following BIP32 format (can be hardened) to define personas e.g. `0'` or `0'/1/2'/0` -### HD path -requires BIP 32 and BIP 39 -derives from BIP44 and EIP -BIP 44 for eth: -https://github.com/ethereum/EIPs/issues/84 -https://github.com/ethereum/EIPs/issues/85 -https://github.com/ethereum/EIPs/pull/600 -https://github.com/ethereum/EIPs/pull/601 -not stricly BIP44 because of cointype should be a number between 0 and 2^31. - -most frequently used eth derivation path -`m/44'/60'/a'/0/n` -where a is a set of account number and n is the account index - -`m/ [EIP#]' / [persona path]' / [app's domain uid path]' / [app's custom subpath]` - -where -EIP#, we use a different path than 44 since it's not bip44, not sure if there is a list of alternative standards - -[persona path] allows to have personas that are not known by apps while having this independant of accounts, thus blockchains keys. -hardened -[domain uid path] -Since each derivation step only has 31 bits we will decompose the domain uid into several indexes -hardened #### domain's uid hash decomposition to get an Hd path -Since each derivation step only has 31 bits we will decompose the domain's hash as several path indexes, first as hex bytes then parsed as integers +Since each child index in an HD path only has 31 bits we will decompose the domain's hash as several child indexes, first as hex bytes then parsed as integers If for the domain uid we use an `ENS namehash` of 32 bytes, 256 bits e.g. `foo.bar.eth` gives namehash `0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3` -We can decompose it in several ways, here are 2 ways: +We can decompose it in several ways, here are 2 potential ways: -approach that favors having the least indexes @@ -184,11 +181,10 @@ x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 where `x0` to `x7` are 30 bits and `x8` 16 bits -approach that favors an homogenous decomposition: -equal length would be 16 * 16 bits or in other words 16 * 2 bytes, cleanest and favorite spec: +equal length would be 16 * 16 bits or in other words 16 * 2 bytes, cleanest and favored spec: ``` x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 || x9 || x10 || x11 || x12 || x13 || x14 || x15 ``` - ``` foo.bar.eth 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 @@ -197,25 +193,6 @@ foo.bar.eth 24627'/25677'/26427'/18355'/48800'/20089'/48096'/28024'/52854'/47294'/12216'/28751'/39978'/33021'/5020'/33235' ``` -The same reasoning, if we use an `eth address` of 20 bytes, 160 bits - -``` -x = x0 || x1 || x2 || x3 || x4 || x5 -``` -where `x0` to `x4` are 30 bits and `x5` is 10 bits. - -which gives the derivation sub path: - -``` -x0'/x1'/x2'/x3'/x4'/x5' -``` - -or alternatively equal length -``` -x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 -``` -where `x0` to `x7` are 20 bits. - does not seem to really matter which we pick between the 2 decomposition approaches, @@ -316,6 +293,18 @@ However the app can use non hardened indexes in their custom path part to be abl ### Alternatives about HD derivation path HD Path: Alternative derivation spec than bip32? HD still but not with hardening? + +BIP 44 for eth: +https://github.com/ethereum/EIPs/issues/84 +https://github.com/ethereum/EIPs/issues/85 +https://github.com/ethereum/EIPs/pull/600 +https://github.com/ethereum/EIPs/pull/601 +not stricly BIP44 because of cointype should be a number between 0 and 2^31. + +most frequently used eth derivation path +`m/44'/60'/a'/0/n` +where a is a set of account number and n is the account index + We won't be using bip44 here since not a crypto and we don't want app keys to be ETH specific @@ -340,22 +329,42 @@ same benefits of privacy could be implemented by add an user provided field in t ### Alternatives for App identification -Current approach uses identification through an ENS name converted to a hash node and sliced fully but one could keep only the first xxx bytes of the node and slice them similarly. This may increase the change of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to bytes32. +#### Shortening the ENS node +Current approach uses identification through an ENS name converted to a hash node and sliced fully but one could keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the change of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to bytes32. +#### Names not restricted to ens domains? Should we allow names that are not .eth domains? We may want to be able to handle DNS names for instance without using an ENS proxy (ie. a .eth domain point to a DNS url). They would have to be resolved differently because ENS does not allow other TLDs. ``` No, TLDs are restricted to only .eth (on mainnet), or .eth and .test (on Ropsten), plus any special purpose TLDs such as those required to permit reverse lookups. There are no immediate plans to invite proposals for additional TLDs. In large part this is to reduce the risk of a namespace collision with the IANA DNS namespace. ``` -domain's UID: Alternative spec, eth author address and including a signed message challenge for author for authentication -0x9df77328a2515c6d529bae90edf3d501eaaa268e - Replaces [EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4 Benefit of our approach: Does not require a centrally maintained registry. In our approach every app has already a domain assigned to it. Englobing (personas among other) +domain's UID: Alternative spec, eth author address and including a signed message challenge for author for authentication +0x9df77328a2515c6d529bae90edf3d501eaaa268e + +The same reasoning, if we use an `eth address` of 20 bytes, 160 bits + +``` +x = x0 || x1 || x2 || x3 || x4 || x5 +``` +where `x0` to `x4` are 30 bits and `x5` is 10 bits. + +which gives the derivation sub path: + +``` +x0'/x1'/x2'/x3'/x4'/x5' +``` + +or alternatively equal length +``` +x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 +``` +where `x0` to `x7` are 20 bits. ### Alternatives for App authentification From 202c438e99af767c4e4ceb3b40eb30cc18f6c6ae Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 23:53:43 +0100 Subject: [PATCH 25/92] draft --- EIPS/eip-draft_app_keys.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index d2415b210ab071..2b86f5e34649e3 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -61,15 +61,10 @@ Once connected to a wallet, an application can request to access a set of accoun ### HD path -requires BIP 32 and BIP 39 -derives from BIP44 and EIP - -We propose to use the following HD path for each app keys: - +Using the BIP 32 and BIP 39 standards, we propose to use the following HD path for each app keys: `m/ [EIP#]' / [persona path]' / [application uniquely assigned path]' / [app's custom subpath]` - Where: `EIP#` is the EIP number that will be assigned to this EIP and we harden it. We use a different path than 44' since it's not bip44 compliant. [At this point, I'm not sure if there is a list of alternative standards to BIP44 codes] From 62178d75dccf61da3a2dddaae7d1b09dffbf4fb2 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 23:54:19 +0100 Subject: [PATCH 26/92] draft --- EIPS/eip-draft_app_keys.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 2b86f5e34649e3..39a01a93d48aa5 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -68,8 +68,11 @@ Using the BIP 32 and BIP 39 standards, we propose to use the following HD path f Where: `EIP#` is the EIP number that will be assigned to this EIP and we harden it. We use a different path than 44' since it's not bip44 compliant. [At this point, I'm not sure if there is a list of alternative standards to BIP44 codes] + `persona path` allows to use applications with different and isolated personas (or in other words accounts) that are tracable by the application. They will still be fully restorable from the same mnemonic. + `application uniquely assigned path` isolate each application along unique branches of the tree through these unique subPath combination. + `app's custom subPath` give freedom to application to use this BIP32 compliant subPath to manage accounts and other needed parameters. Note that we suggest that each of these indexes, except those belonging to the app's custom subpath, must be hardened to fully isolate the public keys across personas and applications. From 765dc0b1af593a61d2d838cbf29296c2243cf88a Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 21 Feb 2019 23:56:30 +0100 Subject: [PATCH 27/92] draft --- EIPS/eip-draft_app_keys.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 39a01a93d48aa5..8de3a7d2f01852 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -123,7 +123,7 @@ keccak256(‘eth’) = 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47 ``` -We thus propose to use the node of each app's domain as a unique identifier for each app but one can think of other UIDs, we include some alternative specs in the `Rationale` section below. +We thus propose to use the node of each app's domain as a unique identifier for each app but one can think of other UIDs, we include some alternative specs in the [Rationale](#Rationale) section below. #### App's authentication @@ -144,7 +144,7 @@ The interface ID of this interface is 0x59d1d43c. The text data may be any arbitrary UTF-8 string. If the key is not present, the empty string must be returned. ``` -One can think of other authentification methods and even use some of them alongside the url-resolution method through ENS. We mention other methods in the `Rationale` section. +One can think of other authentification methods and even use some of them alongside the url-resolution method through ENS. We mention other methods in the [Rationale](#Rationale) section. We suggest for instance to also add an `authorEthAddress` text metadata field that can be used to authenticate message from the app, with for instance a sign challenge. From 05788440ed34d90f5525d2ed642dc1b3ce3bf1f7 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 00:04:38 +0100 Subject: [PATCH 28/92] draft --- EIPS/eip-draft_app_keys.md | 58 ++++++++++++++++++-------------------- 1 file changed, 28 insertions(+), 30 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 8de3a7d2f01852..0ff841deb550da 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -77,6 +77,15 @@ Where: Note that we suggest that each of these indexes, except those belonging to the app's custom subpath, must be hardened to fully isolate the public keys across personas and applications. + +### Personas + +We allow the user to use different personas in combination to her mnemonic to potentially fully isolate her interact with a given app accross personas. One can use this for instance to create a personal and business profile for a given's domain both backup up from the same mnemonic, using 2 different personnas indexes. The app or domain, will not be aware that it is the same person and mnemonic behind both. + +We use a string following BIP32 format (can be hardened) to define personas +with hex under 0x80000000, 31 bits +e.g. `0'` or `0'/1/2'/0` + #### Apps' Unique Identifiers We need a way to uniquely identify each App. @@ -93,8 +102,6 @@ Normalising and validating names Before a name can be converted to a node hash using Namehash, the name must first be normalised and checked for validity - for instance, converting fOO.eth into foo.eth, and prohibiting names containing forbidden characters such as underscores. It is crucial that all applications follow the same set of rules for normalisation and validation, as otherwise two users entering the same name on different systems may resolve the same human-readable name into two different ENS names. ``` - - The ENS uses an hashing scheme to associate a domain to a unique hash, `node`, through the `namehash` function This gives an unique identifier (UID) of 32 bytes. @@ -132,9 +139,6 @@ The ENS can also allow to register and resolve metadata for the app such as `url If we use for instance this resolver profile defined in [EIP 634](https://eips.ethereum.org/EIPS/eip-634) which permits the lookup of arbitrary key-value text data, we can for instance use the key `url` to point to a website. - - - ``` A new resolver interface is defined, consisting of the following method: @@ -148,19 +152,7 @@ One can think of other authentification methods and even use some of them alongs We suggest for instance to also add an `authorEthAddress` text metadata field that can be used to authenticate message from the app, with for instance a sign challenge. - -### Personas - -We allow the user to use different personas in combination to her mnemonic to potentially fully isolate her interact with a given app accross personas. One can use this for instance to create a personal and business profile for a given's domain both backup up from the same mnemonic, using 2 different personnas indexes. The app or domain, will not be aware that it is the same person and mnemonic behind both. - -We use a string following BIP32 format (can be hardened) to define personas - -e.g. `0'` or `0'/1/2'/0` - - - - -#### domain's uid hash decomposition to get an Hd path +#### Application UID decomposition to get a BIP32 HD path Since each child index in an HD path only has 31 bits we will decompose the domain's hash as several child indexes, first as hex bytes then parsed as integers @@ -191,32 +183,38 @@ foo.bar.eth 24627'/25677'/26427'/18355'/48800'/20089'/48096'/28024'/52854'/47294'/12216'/28751'/39978'/33021'/5020'/33235' ``` - - does not seem to really matter which we pick between the 2 decomposition approaches, Maybe favor the one that leads to less indexes, less computations alternative has the benefit of being much cleaner, especially for the 256 bits decompositions -### App custom sub path +### Application custom sub path -hdSubPath +Must follow bip32, with hex under 0x80000000, 31 bits -with uint under 0x80000000, 31 bits +Can be hardened depending on each application's need -should follow bip32 +Can be writen in hex or int -can be hardened - -can be writen in hex or int +Can be extended to several child indexes in order to include the required data such as `version` for instance. ### Example HD paths for app keys: + +--- +Dummy data: + EIP#: 12345 + personaPath: 0 -uid: 4f5b 8127 89fc 606b e1b3 b169 08db 13fc 7a9a df7c a726 41f8 4d75 b470 69d3 d7f0 -app custom path params: (entirely customisable by app under BIP32 standard) app_version set_of_accounts_index, change_index, account_index -`m/0'/12345'/4f5b'/8127'/89fc'/606b'/e1b3'/b169'/08db'/13fc'/7a9a'/df7c'/a726'/41f8'/4d75'/b470'/69d3'/d7f0'/app_version'/a'/0/n` +application's name: foo.bar.eth + +uid: 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 + +app custom path params: app_version set_of_accounts_index, change_index, account_index +--- + +`m/0'/12345'/6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3'/0'/0'/0/0` ## API: From 5991462f1bac6d36bee52477d2d53c3f4d92673b Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 00:05:52 +0100 Subject: [PATCH 29/92] draft --- EIPS/eip-draft_app_keys.md | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 0ff841deb550da..a7e4d848cc14f3 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -200,19 +200,14 @@ Can be extended to several child indexes in order to include the required data s ### Example HD paths for app keys: ---- +``` Dummy data: - EIP#: 12345 - personaPath: 0 - application's name: foo.bar.eth - uid: 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 - app custom path params: app_version set_of_accounts_index, change_index, account_index ---- +``` `m/0'/12345'/6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3'/0'/0'/0/0` From 9be78218d166478fa33ba23ad4c71b6e10b01c31 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 00:12:38 +0100 Subject: [PATCH 30/92] draft --- EIPS/eip-draft_app_keys.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index a7e4d848cc14f3..601bc0d05faa30 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -203,28 +203,29 @@ Can be extended to several child indexes in order to include the required data s ``` Dummy data: EIP#: 12345 -personaPath: 0 +personaPath: 0' application's name: foo.bar.eth uid: 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 app custom path params: app_version set_of_accounts_index, change_index, account_index ``` -`m/0'/12345'/6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3'/0'/0'/0/0` +`m/12345'/0'/6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3'/0'/0'/0/0` ## API: ### App keys exposure: -* `wallet.appkey.enable()` +* `wallet.appkey.enable(options)` -uses the persona selected by the user (not known nor shared with app) +[TBD] where `options` is a javascript object containing the permissions requested for these app keys: +* delegate account creation and signing to application for these keys +* access and use the local storage under these keys -uses the domain ens namehash (node) that was resolved to load window (not by app) +Uses the persona selected by the user (not known nor controllable by application). -depending on user choice, user will be prompted for signing confirmations or not for those app keys +Uses the domain ens namehash (node) that was resolved to load window (not provided by application itself) -### Global HD methods: -none +Depending on user choice, the user will be prompted for signing confirmations or not for those app keys ### Ethereum accounts methods: @@ -259,7 +260,6 @@ Request Encryption * `decrypt() [TBD]` Request Decryption -#### cross domain communication / signing #### storage * `persistInDb(key, data) [TBD] `: Store in MetaMask localdb, specific store for plugin From d08ea5a705ff82b3008ce3543a8c77e28f5e7305 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 00:14:08 +0100 Subject: [PATCH 31/92] draft --- EIPS/eip-draft_app_keys.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 601bc0d05faa30..5fb324af42473c 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -86,7 +86,7 @@ We use a string following BIP32 format (can be hardened) to define personas with hex under 0x80000000, 31 bits e.g. `0'` or `0'/1/2'/0` -#### Apps' Unique Identifiers +### Apps' Unique Identifiers We need a way to uniquely identify each App. @@ -132,7 +132,7 @@ keccak256(‘eth’) = 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47 We thus propose to use the node of each app's domain as a unique identifier for each app but one can think of other UIDs, we include some alternative specs in the [Rationale](#Rationale) section below. -#### App's authentication +### App's authentication In the case of our favored specification for apps' UIDs using ENS, we can authenticate the app through ens resolution. The ENS can also allow to register and resolve metadata for the app such as `url`, and other parameters. @@ -152,7 +152,7 @@ One can think of other authentification methods and even use some of them alongs We suggest for instance to also add an `authorEthAddress` text metadata field that can be used to authenticate message from the app, with for instance a sign challenge. -#### Application UID decomposition to get a BIP32 HD path +### Application UID decomposition to get a BIP32 HD path Since each child index in an HD path only has 31 bits we will decompose the domain's hash as several child indexes, first as hex bytes then parsed as integers From 2845d696ec9efb130f5c7e64fa9ec86b7cd834d0 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 00:28:08 +0100 Subject: [PATCH 32/92] draft --- EIPS/eip-draft_app_keys.md | 37 +++++++++++++++++++------------------ 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 5fb324af42473c..a28a1c205f8d48 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -272,6 +272,25 @@ Store in MetaMask localdb, specific store for plugin ### Isolated paths but customisable ### persona isolation for privacy +Instead of personas, alternative proposal (make them subsets of ETH main accounts) +[Hd Path of an Eth main Account] / [Domain Specific Hd subPath] / [App controlled HD subPath] / [Account index] + +pros: +allows to use isolated app paths for the same app using the same mnemonic. + +can have several accounts fully separated to use the same domain without the domain knowing I'm the same individual. All this with the same mnemonic, I would just use 2 different mainAccounts. + +One question though is how do you handle apps/plugin that would like to interact with several "main accounts", accounts outside of their control? Not sure if this use case really exists tho and we could have. + +Also how does this applies to the plugins if metamask doesn't have a "selected account anymore"? Logging into plugins in the same way as in websites, EIP1102? + +cons: +makes this a subset of an ethereum account or should be eventually generalised to non ETH main accounts? +adds complexity to restore, one should remember which account is which +same benefits of privacy could be implemented by add an user provided field in the HD path, after domain and before app subpath + +==> personas seem better + ### hardening for privacy hardening has benefits for security and privacy if parent extended public key is known, public keys of child of hardened indexes can not be computed. @@ -299,24 +318,6 @@ where a is a set of account number and n is the account index We won't be using bip44 here since not a crypto and we don't want app keys to be ETH specific -Proposal 2 (make them subsets of ETH main accounts) -[Hd Path of an Eth main Account] / [Domain Specific Hd subPath] / [App controlled HD subPath] / [Account index] - -pros: -allows to use isolated app paths for the same app using the same mnemonic. - -can have several accounts fully separated to use the same domain without the domain knowing I'm the same individual. All this with the same mnemonic, I would just use 2 different mainAccounts. - -One question though is how do you handle apps/plugin that would like to interact with several "main accounts", accounts outside of their control? Not sure if this use case really exists tho and we could have. - -Also how does this applies to the plugins if metamask doesn't have a "selected account anymore"? Logging into plugins in the same way as in websites, EIP1102? - -cons: -makes this a subset of an ethereum account or should be eventually generalised to non ETH main accounts? -adds complexity to restore, one should remember which account is which -same benefits of privacy could be implemented by add an user provided field in the HD path, after domain and before app subpath - -==> personas seem better ### Alternatives for App identification From 16eee16d772c0f144bc430b182c0433abfba1dce Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 08:33:19 +0100 Subject: [PATCH 33/92] draft --- EIPS/eip-draft_app_keys.md | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index a28a1c205f8d48..a9e8997c1891b2 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -2,8 +2,8 @@ eip: title: App Keys: app specific accounts author: -Vincent Eli @Bunjin -Dan Finlay @DanFinlay +Vincent Eli [@Bunjin](https://github.com/Bunjin) +Dan Finlay [@DanFinlay](https://github.com/DanFinlay) discussions-to: status: Draft type: Standards Track @@ -111,7 +111,7 @@ e.g. for foo.bar.eth app's uid 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 ``` -For referenceHere are the specs of ENS: +For reference, here are the specs of ENS: ``` domain - the complete, human-readable form of a name; eg, ‘vitalik.wallet.eth’. @@ -163,14 +163,14 @@ e.g. `foo.bar.eth` gives namehash We can decompose it in several ways, here are 2 potential ways: --approach that favors having the least indexes +* approach that favors having the least indexes ``` x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 ``` where `x0` to `x7` are 30 bits and `x8` 16 bits --approach that favors an homogenous decomposition: +* approach that favors an homogenous decomposition: equal length would be 16 * 16 bits or in other words 16 * 2 bytes, cleanest and favored spec: ``` x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 || x9 || x10 || x11 || x12 || x13 || x14 || x15 @@ -183,9 +183,8 @@ foo.bar.eth 24627'/25677'/26427'/18355'/48800'/20089'/48096'/28024'/52854'/47294'/12216'/28751'/39978'/33021'/5020'/33235' ``` -does not seem to really matter which we pick between the 2 decomposition approaches, -Maybe favor the one that leads to less indexes, less computations -alternative has the benefit of being much cleaner, especially for the 256 bits decompositions +It does not seem to really matter which method we pick between these 2 decomposition approaches, there is a trade-off between computational efficiency (having less depth) and having an homegenous decomposition. We tend to favor the second approach with an homogenous decomposition. + ### Application custom sub path @@ -322,7 +321,7 @@ and we don't want app keys to be ETH specific ### Alternatives for App identification #### Shortening the ENS node -Current approach uses identification through an ENS name converted to a hash node and sliced fully but one could keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the change of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to bytes32. +Current approach uses identification through an ENS name converted to a hash node and sliced fully but one could keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the chance of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to bytes32. #### Names not restricted to ens domains? Should we allow names that are not .eth domains? We may want to be able to handle DNS names for instance without using an ENS proxy (ie. a .eth domain point to a DNS url). They would have to be resolved differently because ENS does not allow other TLDs. @@ -385,7 +384,7 @@ https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit ## Backwards Compatibility No incompatibity since these are separate accounts -For apps that registered their user using main accounts eth addresses, they need to have a migration pattern to app keys accounts when desirable +For apps that registered their user using main accounts eth addresses, they need to have a migration pattern to app keys accounts if desirable. @@ -422,15 +421,21 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public ### HD and mnemonics #### BIPS: [BIP 32 specs, Hierarchical Deterministic Wallets:](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) + [BIP 39 specs, Mnemonic code for generating deterministic keys:](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) + [BIP44: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit) + [SLIP44: Registered coin types for BIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) #### Derivation path for eth: https://github.com/ethereum/EIPs/issues/84 + https://github.com/ethereum/EIPs/issues/85 + https://github.com/ethereum/EIPs/pull/600 + Ethereum hierarchy for deterministic wallets - https://github.com/ethereum/EIPs/pull/601 @@ -439,15 +444,19 @@ https://github.com/ethereum/EIPs/pull/601 ### ENS: EIP137: Ethereum Domain Name Service - specification https://github.com/ethereum/EIPs/blob/master/EIPS/eip-137.md + EIP165: Standard Interface Detection https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md + EIP634: Storage of text record in ENS https://github.com/ethereum/EIPs/blob/master/EIPS/eip-634.md + ENS docs about namehash: http://docs.ens.domains/en/latest/implementers.html#namehash ### Previous proposals related to app keys [EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) + https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4 # Notes: From 6c234176a557c19cecb011a6be929f17fbf09031 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 08:58:40 +0100 Subject: [PATCH 34/92] draft --- EIPS/eip-draft_app_keys.md | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index a9e8997c1891b2..ef53bc55be24ad 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -2,8 +2,8 @@ eip: title: App Keys: app specific accounts author: -Vincent Eli [@Bunjin](https://github.com/Bunjin) -Dan Finlay [@DanFinlay](https://github.com/DanFinlay) +Vincent Eli [Bunjin](https://github.com/Bunjin) +Dan Finlay [DanFinlay](https://github.com/DanFinlay) discussions-to: status: Draft type: Standards Track @@ -67,7 +67,7 @@ Using the BIP 32 and BIP 39 standards, we propose to use the following HD path f Where: -`EIP#` is the EIP number that will be assigned to this EIP and we harden it. We use a different path than 44' since it's not bip44 compliant. [At this point, I'm not sure if there is a list of alternative standards to BIP44 codes] +`EIP#` is the EIP number that will be assigned to this EIP and we harden it. We use a different path than 44' since it's not bip44 compliant. At this point, I'm not sure if there is a list of alternative standards to BIP44 codes, following the purpose code spec of [BIP43(https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) `persona path` allows to use applications with different and isolated personas (or in other words accounts) that are tracable by the application. They will still be fully restorable from the same mnemonic. @@ -329,6 +329,7 @@ Should we allow names that are not .eth domains? We may want to be able to hand No, TLDs are restricted to only .eth (on mainnet), or .eth and .test (on Ropsten), plus any special purpose TLDs such as those required to permit reverse lookups. There are no immediate plans to invite proposals for additional TLDs. In large part this is to reduce the risk of a namespace collision with the IANA DNS namespace. ``` +#### Not using a centraly maintened index of application uids Replaces [EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4 Benefit of our approach: @@ -405,6 +406,8 @@ https://github.com/ethereum/EIPs/issues/85 ## Acknowledgements MetaMask team +Christian Lundkvist + Liam Horne Richard Moore @@ -424,6 +427,8 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public [BIP 39 specs, Mnemonic code for generating deterministic keys:](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) +[BIP43: Purpose Field for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) + [BIP44: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit) [SLIP44: Registered coin types for BIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) @@ -434,10 +439,15 @@ https://github.com/ethereum/EIPs/issues/84 https://github.com/ethereum/EIPs/issues/85 -https://github.com/ethereum/EIPs/pull/600 -Ethereum hierarchy for deterministic wallets - -https://github.com/ethereum/EIPs/pull/601 +Draft EIP600 Ethereum purpose allocation for Deterministic Wallets: +https://github.com/ethereum/EIPs/blob/d5e99145d962b0b6b4c66daaabb598b870d9d0ad/eip-600.md + + + + +Draft EIP601 Ethereum hierarchy for deterministic wallets: +https://github.com/ethereum/EIPs/blob/d8476ef1c861eb578bb6e9057ff52a71f3cd10e4/EIPS/eip-601.md From 9835ace4306bcaefc75282436be33dae34c867e5 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 09:00:30 +0100 Subject: [PATCH 35/92] draft --- EIPS/eip-draft_app_keys.md | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index ef53bc55be24ad..819902065f6028 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -336,6 +336,7 @@ Benefit of our approach: Does not require a centrally maintained registry. In our approach every app has already a domain assigned to it. Englobing (personas among other) +#### Alternative application identification specification domain's UID: Alternative spec, eth author address and including a signed message challenge for author for authentication 0x9df77328a2515c6d529bae90edf3d501eaaa268e @@ -358,14 +359,14 @@ x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 ``` where `x0` to `x7` are 20 bits. -### Alternatives for App authentification +### Alternatives for Application authentification For authentication we use ENS resolution, and browsing to a given url resolved With ENS resolution and authentification homoglyph attack is not a problem since it will not leak kees from one domain to another. Caveats -* First connection requires the wallet to connect to ethereum mainnet, but once first resolution is done we could use some metadata param address for ethereum less authentication of the app (eg. app server signs a challenge message with the author address resolved in the ENS metadata) -* ENS resolution can change without the user knowing and then a different app/website may be granted access to his app keys. But this means the ENS name owner address was copromised. This would be similar to using a signing challenge authentified by a known public key. If this known public key is compromised we have a similar problem. +* First connection requires the wallet to connect to ethereum mainnet, but once first resolution is done we could use some metadata param address for ethereum less authentication of the application (eg. application server signs a challenge message with the author address resolved in the ENS metadata) +* ENS resolution can change without the user knowing and then a different application/website may be granted access to his app keys. But this means the ENS name owner address was copromised. This would be similar to using a signing challenge authentified by a known public key. If this known public key is compromised we have a similar problem. Other metadata resolution through ENS that can be used alongside: * author address: already mentionned above @@ -376,7 +377,7 @@ Alternative specs could ### Allowing app keys to derive any subpath and index, even if preivous ones by enumeration are empty -problem apps won't be able to restore by enumeration +problem: applications won't be able to restore by enumeration but if they do that to derive accounts maybe it's on purpose and they may backup this data somewhere Also maybe wallets wants to include an address gap limit for the derivation by enumeration when importing https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit @@ -385,7 +386,7 @@ https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit ## Backwards Compatibility No incompatibity since these are separate accounts -For apps that registered their user using main accounts eth addresses, they need to have a migration pattern to app keys accounts if desirable. +For applications that registered their user using main accounts eth addresses, they need to have a migration pattern to app keys accounts if desirable. @@ -471,10 +472,6 @@ https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-tr # Notes: BIP 39 tool: https://iancoleman.io/bip39/#english -- In Hd Paths, Merge app controlled subset and account index ? - - -- XPubKeys, how do we introduce them? How do we isolate them such that we don't leak a single XPubKey for the whole mnemonic, which would be a big privacy concern and would also remove the benefit of proposal 2 for hd path isolation per main account. json rpc method middleware From 2fc3b9ed1cd34a912c880c45432ac5169b87cbeb Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 11:10:09 +0100 Subject: [PATCH 36/92] draft --- EIPS/eip-draft_app_keys.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 819902065f6028..959921e2937485 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -330,11 +330,10 @@ No, TLDs are restricted to only .eth (on mainnet), or .eth and .test (on Ropsten ``` #### Not using a centraly maintened index of application uids -Replaces [EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) -https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4 -Benefit of our approach: -Does not require a centrally maintained registry. In our approach every app has already a domain assigned to it. -Englobing (personas among other) +This EIP potentially replaces [EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) +also discussed [here](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) + +We think our approach has several benefits, the most important being that it does not require a centrally maintained registry. In our approach every application has already a potential uid assigned to it. Also our EIP is more englobing (personas among other). #### Alternative application identification specification domain's UID: Alternative spec, eth author address and including a signed message challenge for author for authentication From e2293b315a271ab2ba629449a9edeb674449cb56 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 12:13:36 +0100 Subject: [PATCH 37/92] draft --- EIPS/eip-draft_app_keys.md | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 959921e2937485..b71be19fc43b8e 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -53,13 +53,13 @@ These new app keys can permit to give more power and flexibility to the crypto a ## Specification -### Apps +### Applications An app is a website (or other) that would like to request from a wallet to access app keys. It can be any form of cryptography/identity relying application, ethereum but not only. Once connected to a wallet, an application can request to access a set of accounts derived exclusively for that application using the hierarchical deterministic (HD) paths. -### HD path +### Applications' HD path Using the BIP 32 and BIP 39 standards, we propose to use the following HD path for each app keys: @@ -86,7 +86,7 @@ We use a string following BIP32 format (can be hardened) to define personas with hex under 0x80000000, 31 bits e.g. `0'` or `0'/1/2'/0` -### Apps' Unique Identifiers +### Applications' Unique Identifiers We need a way to uniquely identify each App. @@ -96,7 +96,8 @@ There are a few restrictions however on the characters used and normalisation, e In addition there must be a maximum size to the domain string that we need to determine such that the mapping from strings to nodes remains injective, to avoid collision. -We recommand this standard to be following the [ENS Specs](http://docs.ens.domains/en/latest/implementers.html#namehash), reproduced below for convinience and reference. +We recommend this standard to be following the [ENS Specs](http://docs.ens.domains/en/latest/implementers.html#namehash), reproduced below for convinience and reference. + ``` Normalising and validating names Before a name can be converted to a node hash using Namehash, the name must first be normalised and checked for validity - for instance, converting fOO.eth into foo.eth, and prohibiting names containing forbidden characters such as underscores. It is crucial that all applications follow the same set of rules for normalisation and validation, as otherwise two users entering the same name on different systems may resolve the same human-readable name into two different ENS names. @@ -132,7 +133,7 @@ keccak256(‘eth’) = 0x4f5b812789fc606be1b3b16908db13fc7a9adf7ca72641f84d75b47 We thus propose to use the node of each app's domain as a unique identifier for each app but one can think of other UIDs, we include some alternative specs in the [Rationale](#Rationale) section below. -### App's authentication +### Applications' authentication In the case of our favored specification for apps' UIDs using ENS, we can authenticate the app through ens resolution. The ENS can also allow to register and resolve metadata for the app such as `url`, and other parameters. @@ -152,14 +153,13 @@ One can think of other authentification methods and even use some of them alongs We suggest for instance to also add an `authorEthAddress` text metadata field that can be used to authenticate message from the app, with for instance a sign challenge. -### Application UID decomposition to get a BIP32 HD path +### Applications UID decomposition to get a BIP32 HD path -Since each child index in an HD path only has 31 bits we will decompose the domain's hash as several child indexes, first as hex bytes then parsed as integers +Since each child index in an HD path only has 31 bits we will decompose the domain's hash as several child indexes, first as hex bytes then parsed as integers. -If for the domain uid we use an `ENS namehash` of 32 bytes, 256 bits +Let's focus first on the case where for the applications's uid we use an `ENS namehash node` of 32 bytes, 256 bits. -e.g. `foo.bar.eth` gives namehash -`0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3` +e.g. `foo.bar.eth` which gives the following namehash node: `0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3` We can decompose it in several ways, here are 2 potential ways: @@ -270,7 +270,9 @@ Store in MetaMask localdb, specific store for plugin ### Isolated paths but customisable -### persona isolation for privacy + + +### Persona isolation for privacy Instead of personas, alternative proposal (make them subsets of ETH main accounts) [Hd Path of an Eth main Account] / [Domain Specific Hd subPath] / [App controlled HD subPath] / [Account index] @@ -291,7 +293,7 @@ same benefits of privacy could be implemented by add an user provided field in t ==> personas seem better -### hardening for privacy +### Hardening for privacy hardening has benefits for security and privacy if parent extended public key is known, public keys of child of hardened indexes can not be computed. hardened indexes in case some extended public key leaks at some previous level of the tree, protects the sub trees (of course this has no impact if private keys leak) @@ -403,6 +405,12 @@ Link to hdkeyring methods token contract: https://github.com/ethereum/EIPs/issues/85 +default account for dapps +https://ethereum-magicians.org/t/default-accounts-for-dapps/904 + +non wallet/crypto accounts +[EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) + ## Acknowledgements MetaMask team From b35a475dbf06780c1b1f0f4362431d25f227b2e8 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 14:34:49 +0100 Subject: [PATCH 38/92] draft --- EIPS/eip-draft_app_keys.md | 45 +++++++++++++++++++++++--------------- 1 file changed, 27 insertions(+), 18 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index b71be19fc43b8e..a4f60bec73e20d 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -82,15 +82,16 @@ Note that we suggest that each of these indexes, except those belonging to the a We allow the user to use different personas in combination to her mnemonic to potentially fully isolate her interact with a given app accross personas. One can use this for instance to create a personal and business profile for a given's domain both backup up from the same mnemonic, using 2 different personnas indexes. The app or domain, will not be aware that it is the same person and mnemonic behind both. -We use a string following BIP32 format (can be hardened) to define personas -with hex under 0x80000000, 31 bits -e.g. `0'` or `0'/1/2'/0` +We use a string following BIP32 format (can be hardened) to define personas. +The indexes should be hex under 0x80000000, 31 bits. + +E.g. `0'` or `0'/1/2'/0` ### Applications' Unique Identifiers -We need a way to uniquely identify each App. +We need a way to uniquely identify each application. -In our favored spec, each app is uniquely defined and authentified by its name, a domain string. For apps to be resolved through the Ethereum Name Service (ENS), they need to be a using a .eth domain name (e.g. foo.bar.eth). Note that the proposed spec does not restrict the apps' names to be following the .eth standard but they would need to be authentified differently (see below). +In our favored spec, each application is uniquely defined and authentified by its name, a domain string. For applications to be resolved through the Ethereum Name Service (ENS), they need to be a using a .eth domain name (e.g. foo.bar.eth). Note that the proposed spec does not restrict the applications' names to be following the .eth standard but they would need to be authentified differently (see below). There are a few restrictions however on the characters used and normalisation, each name should be passed through the [NamePrep Algorithm](https://tools.ietf.org/html/rfc3491) @@ -135,8 +136,8 @@ We thus propose to use the node of each app's domain as a unique identifier for ### Applications' authentication -In the case of our favored specification for apps' UIDs using ENS, we can authenticate the app through ens resolution. -The ENS can also allow to register and resolve metadata for the app such as `url`, and other parameters. +In the case of our favored specification for applications' UIDs using ENS, we can authenticate the application through ENS resolution. +The ENS can also allow to register and resolve metadata for the application such as `url`, and other parameters. If we use for instance this resolver profile defined in [EIP 634](https://eips.ethereum.org/EIPS/eip-634) which permits the lookup of arbitrary key-value text data, we can for instance use the key `url` to point to a website. @@ -151,31 +152,32 @@ The text data may be any arbitrary UTF-8 string. If the key is not present, the One can think of other authentification methods and even use some of them alongside the url-resolution method through ENS. We mention other methods in the [Rationale](#Rationale) section. -We suggest for instance to also add an `authorEthAddress` text metadata field that can be used to authenticate message from the app, with for instance a sign challenge. +We suggest for instance to also add an `authorEthAddress` text metadata field that can be used to authenticate messages from the application, with for instance a sign challenge. ### Applications UID decomposition to get a BIP32 HD path Since each child index in an HD path only has 31 bits we will decompose the domain's hash as several child indexes, first as hex bytes then parsed as integers. -Let's focus first on the case where for the applications's uid we use an `ENS namehash node` of 32 bytes, 256 bits. +Let's focus first on the case where for the applications's uid we use an `ENS namehash node` of 32 bytes, 256 bits (removing the leading `0x`). e.g. `foo.bar.eth` which gives the following namehash node: `0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3` We can decompose it in several ways, here are 2 potential ways: -* approach that favors having the least indexes +* The first approach favors an homogenous decomposition: -``` -x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 -``` -where `x0` to `x7` are 30 bits and `x8` 16 bits +Equal lenght indexes would be 16 * 16 bits or in other words 16 * 2 bytes, cleanest and favored spec: -* approach that favors an homogenous decomposition: -equal length would be 16 * 16 bits or in other words 16 * 2 bytes, cleanest and favored spec: ``` x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 || x9 || x10 || x11 || x12 || x13 || x14 || x15 + +where || is concatenation ``` + + ``` +E.g. + foo.bar.eth 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 6033 644d 673b 47b3 bea0 4e79 bbe0 6d78 ce76 b8be 2fb8 704f 9c2a 80fd 139c 81d3 @@ -183,10 +185,17 @@ foo.bar.eth 24627'/25677'/26427'/18355'/48800'/20089'/48096'/28024'/52854'/47294'/12216'/28751'/39978'/33021'/5020'/33235' ``` -It does not seem to really matter which method we pick between these 2 decomposition approaches, there is a trade-off between computational efficiency (having less depth) and having an homegenous decomposition. We tend to favor the second approach with an homogenous decomposition. +* An alternative approach could favor having the least indexes: + +``` +x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 +``` +where `x0` to `x7` are 30 bits and `x8` 16 bits + +It does not seem to really matter which method we pick between these 2 decomposition approaches, there is a trade-off between computational efficiency (having less depth) and having an homegenous decomposition. We tend to favor the approach with an homogenous decomposition. -### Application custom sub path +### Application customisable HD sub path Must follow bip32, with hex under 0x80000000, 31 bits From d3ae00a2bbc946dff367721d7054e0b9764e647c Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 16:59:25 +0100 Subject: [PATCH 39/92] draft --- EIPS/eip-draft_app_keys.md | 50 +++++++++++++++++++++++--------------- 1 file changed, 31 insertions(+), 19 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index a4f60bec73e20d..1995aba72d4950 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -63,7 +63,7 @@ Once connected to a wallet, an application can request to access a set of accoun Using the BIP 32 and BIP 39 standards, we propose to use the following HD path for each app keys: -`m/ [EIP#]' / [persona path]' / [application uniquely assigned path]' / [app's custom subpath]` +`m / [EIP#]' / [persona path]' / [application uniquely assigned path]' / [app's custom subpath]` Where: @@ -197,14 +197,14 @@ It does not seem to really matter which method we pick between these 2 decomposi ### Application customisable HD sub path -Must follow bip32, with hex under 0x80000000, 31 bits +Finally, the last part of the hd path is under the application's control. This will allow applications developers to use the HD path structure that best fits their needs. Developers can for instance, among any combination of other parameters they like, choose to include a `version` field if they would like to use different signing accounts when updating to a new version. They can then also manage the user accounts in the way they would like, for instance including or not an index for `sets of accounts` (called `accounts` in BIP44), an index for `change` and an index for `account` (called `address_index` in BIP44). +We consider that a given child on the HD tree should be called an `account` and not an `address` since it is composed of a private key, a public key and an address. -Can be hardened depending on each application's need - -Can be writen in hex or int - -Can be extended to several child indexes in order to include the required data such as `version` for instance. +Similarly to the persona path, this sub path must follow bip32, with hex under 0x80000000, 31 bits. +It can be hardened depending on each application's needs and can be writen as hex or unsigned integers. +It can include a large number of indexes. +Q[Should we set a limit on the persona and application customsable hd path number of indexes?] ### Example HD paths for app keys: @@ -214,7 +214,7 @@ EIP#: 12345 personaPath: 0' application's name: foo.bar.eth uid: 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 -app custom path params: app_version set_of_accounts_index, change_index, account_index +app custom path params: app_version,yy set_of_accounts_index, change_index, account_index ``` `m/12345'/0'/6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3'/0'/0'/0/0` @@ -223,7 +223,10 @@ app custom path params: app_version set_of_accounts_index, change_index, account ### App keys exposure: + + * `wallet.appkey.enable(options)` +This method allows to install app keys (getting user permission to use and allow him to select the persona she would like to use). [TBD] where `options` is a javascript object containing the permissions requested for these app keys: * delegate account creation and signing to application for these keys @@ -261,26 +264,35 @@ tx is ethereum-js tx object * `appKey_eth_signTypedMessage(fromAddress, message)` ### Other potential methods: -#### other cryptocurrencies -#### other crypto -* `encrypt() [TBD]` -Request Encryption -* `decrypt() [TBD]` -Request Decryption -#### storage -* `persistInDb(key, data) [TBD] `: -Store in MetaMask localdb, specific store for plugin +#### Other cryptocurrencies +We defined for now Ethereum accounts and signing methods. However, one could do the same for other cryptocurrencies deriving accounts along their standards. This may open to some very interesting cross-blockchains application designs. + +#### Other cryptographic methods +Similarly, using entropy provided by the HD Path, one could think of other cryptographic methods such as encryption. + +#### Storage +The HD path for each application can also be used as a key to isolate databases for user's persistent data. We could introduce methods that allow to read and write in a database specific to the application. -* `readInDb(key) returns data [TBD] `: +[Benefit of this compared to using classical browser local storage?] ## Rationale ### Isolated paths but customisable +Persona strict isolation and not known nor computable by the applications +Application uid deterministic and common knowledge +### API not exposing private keys + +Applications can derive accounts and request signing from them but they will not get access to the private keys of these accounts. So when the user closes her wallet entirely, the application can not continue signing for the user. +This is of course for control reason. +If there is a strong demand, we could add a method that exposes the private keys for the application accounts but it would be an optional to request upon app keys initial setup. + +We indeed think that writing applications that don't need to manipulate the user private keys is a better pattern. For instance, if one needs the user to sign data while being offline, one should for instance rather implement a delegation method to an external application's controlled account rather than storing the user private key on a server that stays online. + ### Persona isolation for privacy Instead of personas, alternative proposal (make them subsets of ETH main accounts) [Hd Path of an Eth main Account] / [Domain Specific Hd subPath] / [App controlled HD subPath] / [Account index] @@ -308,7 +320,7 @@ hardened indexes in case some extended public key leaks at some previous level o However the app can use non hardened indexes in their custom path part to be able to benefit from guessing child public keys from parent one (for instance for counterfactual state channel interaction accross 2 peers that would like to use new keys every time they counterfactually instantiate a new sub app). -### API not exposing private keys + ### Alternatives about HD derivation path HD Path: Alternative derivation spec than bip32? From 989ca155befbdd577012245f42e94f52593300e7 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 17:19:02 +0100 Subject: [PATCH 40/92] draft --- EIPS/eip-draft_app_keys.md | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 1995aba72d4950..fd10085958ce6d 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -85,7 +85,7 @@ We allow the user to use different personas in combination to her mnemonic to po We use a string following BIP32 format (can be hardened) to define personas. The indexes should be hex under 0x80000000, 31 bits. -E.g. `0'` or `0'/1/2'/0` +E.g. `0'` or `0'/1/2'/0` or `1d7b'/a41c'` ### Applications' Unique Identifiers @@ -204,20 +204,20 @@ Similarly to the persona path, this sub path must follow bip32, with hex under 0 It can be hardened depending on each application's needs and can be writen as hex or unsigned integers. It can include a large number of indexes. -Q[Should we set a limit on the persona and application customsable hd path number of indexes?] +Q [Should we set a limit on the persona and application customsable hd path number of indexes?] ### Example HD paths for app keys: ``` Dummy data: EIP#: 12345 -personaPath: 0' +personaPath: 0'/712' application's name: foo.bar.eth uid: 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 app custom path params: app_version,yy set_of_accounts_index, change_index, account_index ``` -`m/12345'/0'/6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3'/0'/0'/0/0` +`m/12345'/0'/712'/6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3'/0'/0'/0/0` ## API: @@ -274,15 +274,15 @@ Similarly, using entropy provided by the HD Path, one could think of other crypt #### Storage The HD path for each application can also be used as a key to isolate databases for user's persistent data. We could introduce methods that allow to read and write in a database specific to the application. -[Benefit of this compared to using classical browser local storage?] +Q [Benefit of this compared to using classical browser local storage?] ## Rationale ### Isolated paths but customisable -Persona strict isolation and not known nor computable by the applications -Application uid deterministic and common knowledge - +The proposed specifications permit to have isolation between personas and between applications. Each persona / application combination will yield a unique subtree that can be explored by the application using the structure it would like to use. +Personas are known only by the user and its wallet, application' UID based path is computable by everyone from the application's name. And then the application decides and communicates the final levels of the path. +Only the wallet and the user will know the full tree and where we are in the tree (depth, parents). Applications will have knowledge only of the subtree, starting after the persona. ### API not exposing private keys @@ -294,6 +294,7 @@ If there is a strong demand, we could add a method that exposes the private keys We indeed think that writing applications that don't need to manipulate the user private keys is a better pattern. For instance, if one needs the user to sign data while being offline, one should for instance rather implement a delegation method to an external application's controlled account rather than storing the user private key on a server that stays online. ### Persona isolation for privacy +Persona strict isolation and not known nor computable by the applications Instead of personas, alternative proposal (make them subsets of ETH main accounts) [Hd Path of an Eth main Account] / [Domain Specific Hd subPath] / [App controlled HD subPath] / [Account index] @@ -322,7 +323,7 @@ However the app can use non hardened indexes in their custom path part to be abl -### Alternatives about HD derivation path +### Alternatives for the HD derivation path HD Path: Alternative derivation spec than bip32? HD still but not with hardening? @@ -341,7 +342,7 @@ We won't be using bip44 here since not a crypto and we don't want app keys to be ETH specific -### Alternatives for App identification +### Alternatives for application's identification #### Shortening the ENS node Current approach uses identification through an ENS name converted to a hash node and sliced fully but one could keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the chance of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to bytes32. @@ -381,7 +382,7 @@ x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 ``` where `x0` to `x7` are 20 bits. -### Alternatives for Application authentification +### Alternatives for application's authentification For authentication we use ENS resolution, and browsing to a given url resolved With ENS resolution and authentification homoglyph attack is not a problem since it will not leak kees from one domain to another. From 38942e0e69fde17c06fff9f6bcd28be1eb32e8cc Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 17:21:54 +0100 Subject: [PATCH 41/92] draft --- EIPS/eip-draft_app_keys.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index fd10085958ce6d..e52acefc918f35 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -223,8 +223,6 @@ app custom path params: app_version,yy set_of_accounts_index, change_index, acco ### App keys exposure: - - * `wallet.appkey.enable(options)` This method allows to install app keys (getting user permission to use and allow him to select the persona she would like to use). @@ -287,8 +285,8 @@ Only the wallet and the user will know the full tree and where we are in the tre ### API not exposing private keys -Applications can derive accounts and request signing from them but they will not get access to the private keys of these accounts. So when the user closes her wallet entirely, the application can not continue signing for the user. -This is of course for control reason. +Applications can derive accounts and request signing from them but they will not get access to the private keys of these accounts. So when the user closes her wallet entirely, the application can not continue signing for the user. This is of course in order to keep an user's ultimate control over its accounts. + If there is a strong demand, we could add a method that exposes the private keys for the application accounts but it would be an optional to request upon app keys initial setup. We indeed think that writing applications that don't need to manipulate the user private keys is a better pattern. For instance, if one needs the user to sign data while being offline, one should for instance rather implement a delegation method to an external application's controlled account rather than storing the user private key on a server that stays online. From b07e06828b517ef384825430e6ac2d46525a1e2d Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 17:25:48 +0100 Subject: [PATCH 42/92] draft --- EIPS/eip-draft_app_keys.md | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index e52acefc918f35..fe5b825edb1e91 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -279,7 +279,9 @@ Q [Benefit of this compared to using classical browser local storage?] ### Isolated paths but customisable The proposed specifications permit to have isolation between personas and between applications. Each persona / application combination will yield a unique subtree that can be explored by the application using the structure it would like to use. + Personas are known only by the user and its wallet, application' UID based path is computable by everyone from the application's name. And then the application decides and communicates the final levels of the path. + Only the wallet and the user will know the full tree and where we are in the tree (depth, parents). Applications will have knowledge only of the subtree, starting after the persona. @@ -292,9 +294,17 @@ If there is a strong demand, we could add a method that exposes the private keys We indeed think that writing applications that don't need to manipulate the user private keys is a better pattern. For instance, if one needs the user to sign data while being offline, one should for instance rather implement a delegation method to an external application's controlled account rather than storing the user private key on a server that stays online. ### Persona isolation for privacy + Persona strict isolation and not known nor computable by the applications + + Instead of personas, alternative proposal (make them subsets of ETH main accounts) -[Hd Path of an Eth main Account] / [Domain Specific Hd subPath] / [App controlled HD subPath] / [Account index] + +most frequently used eth derivation path +`m/44'/60'/a'/0/n` +where a is a set of account number and n is the account index + +`[Hd Path of an Eth main Account] / [Application UID based path] / [App controlled HD subPath]` pros: allows to use isolated app paths for the same app using the same mnemonic. @@ -314,27 +324,29 @@ same benefits of privacy could be implemented by add an user provided field in t ### Hardening for privacy + hardening has benefits for security and privacy if parent extended public key is known, public keys of child of hardened indexes can not be computed. + hardened indexes in case some extended public key leaks at some previous level of the tree, protects the sub trees (of course this has no impact if private keys leak) However the app can use non hardened indexes in their custom path part to be able to benefit from guessing child public keys from parent one (for instance for counterfactual state channel interaction accross 2 peers that would like to use new keys every time they counterfactually instantiate a new sub app). -### Alternatives for the HD derivation path +### Alternatives for the HD derivation path purpose field + HD Path: Alternative derivation spec than bip32? + HD still but not with hardening? BIP 44 for eth: https://github.com/ethereum/EIPs/issues/84 + https://github.com/ethereum/EIPs/issues/85 https://github.com/ethereum/EIPs/pull/600 https://github.com/ethereum/EIPs/pull/601 not stricly BIP44 because of cointype should be a number between 0 and 2^31. -most frequently used eth derivation path -`m/44'/60'/a'/0/n` -where a is a set of account number and n is the account index We won't be using bip44 here since not a crypto and we don't want app keys to be ETH specific From c8d8a78d0d3def16e6f346796bf6ab6af0d98bc1 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 17:47:00 +0100 Subject: [PATCH 43/92] draft --- EIPS/eip-draft_app_keys.md | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index fe5b825edb1e91..3b2078199166f1 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -67,7 +67,7 @@ Using the BIP 32 and BIP 39 standards, we propose to use the following HD path f Where: -`EIP#` is the EIP number that will be assigned to this EIP and we harden it. We use a different path than 44' since it's not bip44 compliant. At this point, I'm not sure if there is a list of alternative standards to BIP44 codes, following the purpose code spec of [BIP43(https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) +`EIP#` is the EIP number that will be assigned to this EIP and we harden it. We use a different path than 44' since it's not bip44 compliant. At this point, I'm not sure if there is a list of BIP43 codes of standards following the `purpose` field specification of [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki). `persona path` allows to use applications with different and isolated personas (or in other words accounts) that are tracable by the application. They will still be fully restorable from the same mnemonic. @@ -333,23 +333,33 @@ However the app can use non hardened indexes in their custom path part to be abl -### Alternatives for the HD derivation path purpose field +### Alternatives for the HD derivation path +[BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki). +Our proposed specification follows BIP32 and BIP43: +`m / purpose' / *` -HD Path: Alternative derivation spec than bip32? +It is of course not be BIP44 compliant which uses the following tree level structure: +`m / purpose' / coin_type' / account' / change / address_index` -HD still but not with hardening? +One could think of alternatives specification deviating from BIP43 or even BIP32. Or on the contrary, one could try to become BIP44 compliant, although we do not really see the benefit of that for app keys and it would impose serious limitations on how to identify the applications using potentially the `coin_type` field. -BIP 44 for eth: -https://github.com/ethereum/EIPs/issues/84 -https://github.com/ethereum/EIPs/issues/85 -https://github.com/ethereum/EIPs/pull/600 -https://github.com/ethereum/EIPs/pull/601 -not stricly BIP44 because of cointype should be a number between 0 and 2^31. +### Alternatives for the HD derivation path purpose field + +If we agree on not using BIP44 but following BIP32 and BIP43, we need to settle on a purpose field. We proposed to used the number that will be assigned to this EIP and we should research + +current pseudo list of used BIP43 purpose codes: +| 44 | [BIP-0044](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) | Multi-Account Hierarchy for Deterministic Wallets| +| 45 | [BIP-0045](https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki) | Structure for Deterministic P2SH Multisignature Wallets| + +| 48: [SLIP-0048](https://github.com/satoshilabs/slips/issues/49): Deterministic Key Hierarchy for Graphene-based Networks +| 49: [BIP-0049](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki): Derivation scheme for P2WPKH-nested-in-P2SH based accounts +| 80: [BIP-0080](https://github.com/bitcoin/bips/blob/master/bip-0080.mediawiki): Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets +| 84: [BIP-0084](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki): Derivation scheme for P2WPKH based accounts +| 535348: [Ledger app ssh](https://github.com/LedgerHQ/ledger-app-ssh-agent/blob/master/getPublicKey.py#L49) +| 80475047: [GPG/SSH Ledger](https://github.com/LedgerHQ/ledger-app-openpgp-card/blob/master/doc/developper/gpgcard3.0-addon.rst#deterministic-key-derivation) -We won't be using bip44 here since not a crypto -and we don't want app keys to be ETH specific ### Alternatives for application's identification From e1356783224e4ef62f167886cc3dada576ba1f79 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 17:48:27 +0100 Subject: [PATCH 44/92] draft --- EIPS/eip-draft_app_keys.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 3b2078199166f1..eb6b6ccd2b50c4 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -349,7 +349,8 @@ One could think of alternatives specification deviating from BIP43 or even BIP32 If we agree on not using BIP44 but following BIP32 and BIP43, we need to settle on a purpose field. We proposed to used the number that will be assigned to this EIP and we should research current pseudo list of used BIP43 purpose codes: -| 44 | [BIP-0044](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) | Multi-Account Hierarchy for Deterministic Wallets| + +| 44 | [BIP-0044](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) | Multi-Account Hierarchy for Deterministic Wallets | | 45 | [BIP-0045](https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki) | Structure for Deterministic P2SH Multisignature Wallets| | 48: [SLIP-0048](https://github.com/satoshilabs/slips/issues/49): Deterministic Key Hierarchy for Graphene-based Networks From 369612cb7b5b038e86c7aeb8f0f76b4513922490 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 17:50:25 +0100 Subject: [PATCH 45/92] draft --- EIPS/eip-draft_app_keys.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index eb6b6ccd2b50c4..ea79fb8ada549d 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -350,6 +350,9 @@ If we agree on not using BIP44 but following BIP32 and BIP43, we need to settle current pseudo list of used BIP43 purpose codes: + +| code | Reference | Title | +|------|--------------------------------------------------------------------------|-------| | 44 | [BIP-0044](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) | Multi-Account Hierarchy for Deterministic Wallets | | 45 | [BIP-0045](https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki) | Structure for Deterministic P2SH Multisignature Wallets| From 6019d11723aec8ebe9203941fc78860feba40be1 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 17:51:50 +0100 Subject: [PATCH 46/92] draft --- EIPS/eip-draft_app_keys.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index ea79fb8ada549d..a0d3bec23a6594 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -355,13 +355,12 @@ current pseudo list of used BIP43 purpose codes: |------|--------------------------------------------------------------------------|-------| | 44 | [BIP-0044](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) | Multi-Account Hierarchy for Deterministic Wallets | | 45 | [BIP-0045](https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki) | Structure for Deterministic P2SH Multisignature Wallets| - -| 48: [SLIP-0048](https://github.com/satoshilabs/slips/issues/49): Deterministic Key Hierarchy for Graphene-based Networks -| 49: [BIP-0049](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki): Derivation scheme for P2WPKH-nested-in-P2SH based accounts -| 80: [BIP-0080](https://github.com/bitcoin/bips/blob/master/bip-0080.mediawiki): Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets -| 84: [BIP-0084](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki): Derivation scheme for P2WPKH based accounts -| 535348: [Ledger app ssh](https://github.com/LedgerHQ/ledger-app-ssh-agent/blob/master/getPublicKey.py#L49) -| 80475047: [GPG/SSH Ledger](https://github.com/LedgerHQ/ledger-app-openpgp-card/blob/master/doc/developper/gpgcard3.0-addon.rst#deterministic-key-derivation) +| 48 | [SLIP-0048](https://github.com/satoshilabs/slips/issues/49) | Deterministic Key Hierarchy for Graphene-based Networks | +| 49 | [BIP-0049](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki) | Derivation scheme for P2WPKH-nested-in-P2SH based accounts | +| 80 | [BIP-0080](https://github.com/bitcoin/bips/blob/master/bip-0080.mediawiki) | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets | +| 84 | [BIP-0084](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) | Derivation scheme for P2WPKH based accounts | +| 535348 | [Ledger app ssh](https://github.com/LedgerHQ/ledger-app-ssh-agent/blob/master/getPublicKey.py#L49) | | +| 80475047: [GPG/SSH Ledger](https://github.com/LedgerHQ/ledger-app-openpgp-card/blob/master/doc/developper/gpgcard3.0-addon.rst#deterministic-key-derivation)| | From b44b86c4479268217e94923ccaaefc7daaae3c56 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 17:52:16 +0100 Subject: [PATCH 47/92] draft --- EIPS/eip-draft_app_keys.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index a0d3bec23a6594..14be64e0abea63 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -360,7 +360,7 @@ current pseudo list of used BIP43 purpose codes: | 80 | [BIP-0080](https://github.com/bitcoin/bips/blob/master/bip-0080.mediawiki) | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets | | 84 | [BIP-0084](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) | Derivation scheme for P2WPKH based accounts | | 535348 | [Ledger app ssh](https://github.com/LedgerHQ/ledger-app-ssh-agent/blob/master/getPublicKey.py#L49) | | -| 80475047: [GPG/SSH Ledger](https://github.com/LedgerHQ/ledger-app-openpgp-card/blob/master/doc/developper/gpgcard3.0-addon.rst#deterministic-key-derivation)| | +| 80475047| [GPG/SSH Ledger](https://github.com/LedgerHQ/ledger-app-openpgp-card/blob/master/doc/developper/gpgcard3.0-addon.rst#deterministic-key-derivation)| | From 812c32d70e1a0cda5b025fc151840f86b1a87477 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 17:54:18 +0100 Subject: [PATCH 48/92] draft --- EIPS/eip-draft_app_keys.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 14be64e0abea63..507edd7094a703 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -334,14 +334,15 @@ However the app can use non hardened indexes in their custom path part to be abl ### Alternatives for the HD derivation path -[BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki). -Our proposed specification follows BIP32 and BIP43: + +Our proposed specification follows [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) and [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki): + `m / purpose' / *` It is of course not be BIP44 compliant which uses the following tree level structure: `m / purpose' / coin_type' / account' / change / address_index` -One could think of alternatives specification deviating from BIP43 or even BIP32. Or on the contrary, one could try to become BIP44 compliant, although we do not really see the benefit of that for app keys and it would impose serious limitations on how to identify the applications using potentially the `coin_type` field. +One could think of alternative specifications deviating from BIP43 or even BIP32. Or on the contrary, one could try to become BIP44 compliant, although we do not really see the benefit of that for app keys and it would impose serious limitations on how to identify the applications using potentially the `coin_type` field. ### Alternatives for the HD derivation path purpose field From 160a7d9ff1d42372d5f29afeca64f376ed17b7ed Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 17:56:09 +0100 Subject: [PATCH 49/92] draft --- EIPS/eip-draft_app_keys.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 507edd7094a703..8d6fd87c8fe382 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -1,6 +1,6 @@ --- eip: -title: App Keys: app specific accounts +title: App Keys: application specific wallet accounts author: Vincent Eli [Bunjin](https://github.com/Bunjin) Dan Finlay [DanFinlay](https://github.com/DanFinlay) @@ -362,6 +362,7 @@ current pseudo list of used BIP43 purpose codes: | 84 | [BIP-0084](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) | Derivation scheme for P2WPKH based accounts | | 535348 | [Ledger app ssh](https://github.com/LedgerHQ/ledger-app-ssh-agent/blob/master/getPublicKey.py#L49) | | | 80475047| [GPG/SSH Ledger](https://github.com/LedgerHQ/ledger-app-openpgp-card/blob/master/doc/developper/gpgcard3.0-addon.rst#deterministic-key-derivation)| | +| # | [EIP #](#)| App Keys: application specific wallet accounts | From 2dd4aa72a2fbae7e0f9c334c216aac8d266e2103 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 19:20:05 +0100 Subject: [PATCH 50/92] draft --- EIPS/eip-draft_app_keys.md | 61 ++++++++++++++++---------------------- 1 file changed, 25 insertions(+), 36 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 8d6fd87c8fe382..7e8a2850a5247e 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -9,7 +9,7 @@ status: Draft type: Standards Track category: ERC created: 2019-02-20 -requires (*optional): BIP32, EIP137, EIP165, +requires (*optional): BIP32, BIP43, EIP137, EIP165, replaces (*optional): EIP 1581 --- @@ -214,18 +214,21 @@ EIP#: 12345 personaPath: 0'/712' application's name: foo.bar.eth uid: 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 -app custom path params: app_version,yy set_of_accounts_index, change_index, account_index +app custom path params: app_version,yy set_of_accounts_index, account_index ``` -`m/12345'/0'/712'/6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3'/0'/0'/0/0` +`m/12345'/0'/712'/6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3'/0'/0'/0` ## API: +RPC methods ### App keys exposure: * `wallet.appkey.enable(options)` This method allows to install app keys (getting user permission to use and allow him to select the persona she would like to use). +may be merged with EIP1102 enable? + [TBD] where `options` is a javascript object containing the permissions requested for these app keys: * delegate account creation and signing to application for these keys * access and use the local storage under these keys @@ -295,32 +298,25 @@ We indeed think that writing applications that don't need to manipulate the user ### Persona isolation for privacy -Persona strict isolation and not known nor computable by the applications +The persona path is set by the user-wallet interaction and known only by them. There is thus a strict isolation between 2 different persona subpaths as if they were generated by different mnemonics. -Instead of personas, alternative proposal (make them subsets of ETH main accounts) +Instead of personas, an alternative proposal would be to make the `application UID based path` a subset of a user's ethereum main accounts) -most frequently used eth derivation path +Most wallets use the following derivation path for Ether accounts: `m/44'/60'/a'/0/n` where a is a set of account number and n is the account index -`[Hd Path of an Eth main Account] / [Application UID based path] / [App controlled HD subPath]` - -pros: -allows to use isolated app paths for the same app using the same mnemonic. +If we use +`m/44'/60'/a'/0/n / [Application UID based path] / [App controlled HD subPath]` -can have several accounts fully separated to use the same domain without the domain knowing I'm the same individual. All this with the same mnemonic, I would just use 2 different mainAccounts. +This way, we could use accounts as personas. Also if we don't harden the level indexes after the account index, we could compute all public keys -One question though is how do you handle apps/plugin that would like to interact with several "main accounts", accounts outside of their control? Not sure if this use case really exists tho and we could have. +However it does not necessarily make sense to anchor an application to a single main account. Some applications may like to interact with several "main accounts" or allow the user to change the main account they are using to deposit while keeping the same signing `app keys` accounts. -Also how does this applies to the plugins if metamask doesn't have a "selected account anymore"? Logging into plugins in the same way as in websites, EIP1102? - -cons: +Also this alternative specification HD path would not be BIP44 compliant but would be using this purpose field. makes this a subset of an ethereum account or should be eventually generalised to non ETH main accounts? -adds complexity to restore, one should remember which account is which -same benefits of privacy could be implemented by add an user provided field in the HD path, after domain and before app subpath - -==> personas seem better +Also it may add complexity to restore a wallet and the used accounts, one should remember which account is associated with which application and application can not suggest you which account to use because they are not aware of this part of the path. ### Hardening for privacy @@ -331,6 +327,7 @@ hardened indexes in case some extended public key leaks at some previous level o However the app can use non hardened indexes in their custom path part to be able to benefit from guessing child public keys from parent one (for instance for counterfactual state channel interaction accross 2 peers that would like to use new keys every time they counterfactually instantiate a new sub app). +If we don't harden the application path we could get all app keys for every applications from persona key. ### Alternatives for the HD derivation path @@ -488,11 +485,12 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public [SLIP44: Registered coin types for BIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) +[Is there a comprehensive list of registered BIP43 purposes?](https://bitcoin.stackexchange.com/questions/60470/is-there-a-comprehensive-list-of-registered-bip43-purposes) #### Derivation path for eth: -https://github.com/ethereum/EIPs/issues/84 +[ERC84](https://github.com/ethereum/EIPs/issues/84) -https://github.com/ethereum/EIPs/issues/85 +[ERC85](https://github.com/ethereum/EIPs/issues/85) Draft EIP600 Ethereum purpose allocation for Deterministic Wallets: @@ -507,26 +505,17 @@ https://github.com/ethereum/EIPs/blob/d8476ef1c861eb578bb6e9057ff52a71f3cd10e4/E ### ENS: -EIP137: Ethereum Domain Name Service - specification -https://github.com/ethereum/EIPs/blob/master/EIPS/eip-137.md +[EIP137: Ethereum Domain Name Service - specification](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-137.md) -EIP165: Standard Interface Detection -https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md +[EIP165: Standard Interface Detection](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md) -EIP634: Storage of text record in ENS -https://github.com/ethereum/EIPs/blob/master/EIPS/eip-634.md +[EIP634: Storage of text record in ENS](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-634.md) -ENS docs about namehash: -http://docs.ens.domains/en/latest/implementers.html#namehash +[ENS docs about namehash:](http://docs.ens.domains/en/latest/implementers.html#namehash) ### Previous proposals related to app keys [EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) -https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4 - -# Notes: -BIP 39 tool: https://iancoleman.io/bip39/#english - +[EIP 1581: discussion](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) -json rpc method middleware -private RPC methods for app keys +[SLIP-0013: Authentication using deterministic hierarchy](https://github.com/satoshilabs/slips/blob/master/slip-0013.md) From b355f512efc70dc0817426979006a1e874c221af Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 19:55:20 +0100 Subject: [PATCH 51/92] draft --- EIPS/eip-draft_app_keys.md | 54 +++++++++++++++++++++----------------- 1 file changed, 30 insertions(+), 24 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 7e8a2850a5247e..1f51d0938f77b7 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -192,6 +192,9 @@ x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 ``` where `x0` to `x7` are 30 bits and `x8` 16 bits +The derivation sub-path would be: +`x0'/x1'/x2'/x3'/x4'/x5'/x6'/x7'/x8'` + It does not seem to really matter which method we pick between these 2 decomposition approaches, there is a trade-off between computational efficiency (having less depth) and having an homegenous decomposition. We tend to favor the approach with an homogenous decomposition. @@ -296,7 +299,7 @@ If there is a strong demand, we could add a method that exposes the private keys We indeed think that writing applications that don't need to manipulate the user private keys is a better pattern. For instance, if one needs the user to sign data while being offline, one should for instance rather implement a delegation method to an external application's controlled account rather than storing the user private key on a server that stays online. -### Persona isolation for privacy +### Persona isolation accross applications for privacy The persona path is set by the user-wallet interaction and known only by them. There is thus a strict isolation between 2 different persona subpaths as if they were generated by different mnemonics. @@ -307,28 +310,30 @@ Most wallets use the following derivation path for Ether accounts: `m/44'/60'/a'/0/n` where a is a set of account number and n is the account index -If we use +We could use: `m/44'/60'/a'/0/n / [Application UID based path] / [App controlled HD subPath]` -This way, we could use accounts as personas. Also if we don't harden the level indexes after the account index, we could compute all public keys +This way, we could use accounts as personas. However it does not necessarily make sense to anchor an application to a single main account. Some applications may like to interact with several "main accounts" or allow the user to change the main account they are using to deposit while keeping the same signing `app keys` accounts. Also this alternative specification HD path would not be BIP44 compliant but would be using this purpose field. makes this a subset of an ethereum account or should be eventually generalised to non ETH main accounts? + Also it may add complexity to restore a wallet and the used accounts, one should remember which account is associated with which application and application can not suggest you which account to use because they are not aware of this part of the path. +If we don't harden the level indexes after the main account index, we could however enumerate all app keys of an user given a list a applications. We would first enumerate over the main accounts (assuming the wallet uses an [account gap limit](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit)), then over the Applications list and then over the `Application controlled HD subPath` if it allows to do so and has an account gap limit. +For persona this may not be possible, unless we impose some structure on the personas such as using a basic index. +### Hardened and non-hardened indexes: privacy and functionality -### Hardening for privacy +Hardening allows to increase privacy. If the extended public key of a parent level in the HD tree is known, public keys of its childs can not be computed if they are hardened. On the contrary if the child indexes are not hardened one can enumerate the child public keys and use that for the application design or to easily restore a wallet and it increases functionality. -hardening has benefits for security and privacy if parent extended public key is known, public keys of child of hardened indexes can not be computed. +For the first parts of the HD tree, we need isolation and privacy. Thus we use hardened indexes for the persona and application paths in case some extended public key leaks at some previous level of the tree, it would protect the sub trees (of course this has no impact if private keys leak). -hardened indexes in case some extended public key leaks at some previous level of the tree, protects the sub trees (of course this has no impact if private keys leak) +For instance if we don't harden the application path, in case a persona public key is known and the application subpath does not use hardening either, one could get all `app keys` public keys for every application for this persona. However the app can use non hardened indexes in their custom path part to be able to benefit from guessing child public keys from parent one (for instance for counterfactual state channel interaction accross 2 peers that would like to use new keys every time they counterfactually instantiate a new sub app). -If we don't harden the application path we could get all app keys for every applications from persona key. - ### Alternatives for the HD derivation path @@ -346,7 +351,7 @@ One could think of alternative specifications deviating from BIP43 or even BIP32 If we agree on not using BIP44 but following BIP32 and BIP43, we need to settle on a purpose field. We proposed to used the number that will be assigned to this EIP and we should research -current pseudo list of used BIP43 purpose codes: +We did not find a list of BIP43 purpose code so here is what we could gather: | code | Reference | Title | @@ -362,41 +367,41 @@ current pseudo list of used BIP43 purpose codes: | # | [EIP #](#)| App Keys: application specific wallet accounts | - - ### Alternatives for application's identification #### Shortening the ENS node -Current approach uses identification through an ENS name converted to a hash node and sliced fully but one could keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the chance of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to bytes32. + +Our current approach uses identification through an ENS name converted to a hash node and sliced fully but one could keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the chance of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to bytes32. #### Names not restricted to ens domains? + Should we allow names that are not .eth domains? We may want to be able to handle DNS names for instance without using an ENS proxy (ie. a .eth domain point to a DNS url). They would have to be resolved differently because ENS does not allow other TLDs. + ``` No, TLDs are restricted to only .eth (on mainnet), or .eth and .test (on Ropsten), plus any special purpose TLDs such as those required to permit reverse lookups. There are no immediate plans to invite proposals for additional TLDs. In large part this is to reduce the risk of a namespace collision with the IANA DNS namespace. ``` -#### Not using a centraly maintened index of application uids -This EIP potentially replaces [EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) -also discussed [here](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) +#### Using a centraly maintened index of application uids -We think our approach has several benefits, the most important being that it does not require a centrally maintained registry. In our approach every application has already a potential uid assigned to it. Also our EIP is more englobing (personas among other). +[EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) +also discussed [here](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) proposes a scheme that relies on a list of indexes where application should register (similar to SLIP0044 list for instance). + +We think our approach while also being more englobing benefits from not requiring a centrally maintained registry. In our approach every application has already a potential unique identifier assigned to it. #### Alternative application identification specification -domain's UID: Alternative spec, eth author address and including a signed message challenge for author for authentication -0x9df77328a2515c6d529bae90edf3d501eaaa268e -The same reasoning, if we use an `eth address` of 20 bytes, 160 bits +For the application unique identifiers, an alternative specification could favor using an `ethereum author address` and including a signed message challenge for author for authentication. + +It would also need to specify how to decompose this address. +The same reasoning as before would apply, if we use an `eth address` of 20 bytes, 160 bits + +e.g. 0x9df77328a2515c6d529bae90edf3d501eaaa268e ``` x = x0 || x1 || x2 || x3 || x4 || x5 ``` where `x0` to `x4` are 30 bits and `x5` is 10 bits. -which gives the derivation sub path: - -``` -x0'/x1'/x2'/x3'/x4'/x5' -``` or alternatively equal length ``` @@ -404,6 +409,7 @@ x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 ``` where `x0` to `x7` are 20 bits. + ### Alternatives for application's authentification For authentication we use ENS resolution, and browsing to a given url resolved From d4219413cdab4de09766e01a05f1bb9b5f5d9bbf Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 20:17:35 +0100 Subject: [PATCH 52/92] draft --- EIPS/eip-draft_app_keys.md | 40 +++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 1f51d0938f77b7..5a184f32b0f155 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -306,7 +306,7 @@ The persona path is set by the user-wallet interaction and known only by them. T Instead of personas, an alternative proposal would be to make the `application UID based path` a subset of a user's ethereum main accounts) -Most wallets use the following derivation path for Ether accounts: +Most wallets use the following derivation path for ethereum accounts: `m/44'/60'/a'/0/n` where a is a set of account number and n is the account index @@ -315,14 +315,14 @@ We could use: This way, we could use accounts as personas. -However it does not necessarily make sense to anchor an application to a single main account. Some applications may like to interact with several "main accounts" or allow the user to change the main account they are using to deposit while keeping the same signing `app keys` accounts. +However it does not necessarily make sense to anchor an application to a single main account. Some applications may like to interact with several "main accounts" or allow the user to change the main account they are using to deposit while keeping the same signing `app keys` accounts. Some applications may even like to use non ethereum accounts. Also this alternative specification HD path would not be BIP44 compliant but would be using this purpose field. -makes this a subset of an ethereum account or should be eventually generalised to non ETH main accounts? Also it may add complexity to restore a wallet and the used accounts, one should remember which account is associated with which application and application can not suggest you which account to use because they are not aware of this part of the path. If we don't harden the level indexes after the main account index, we could however enumerate all app keys of an user given a list a applications. We would first enumerate over the main accounts (assuming the wallet uses an [account gap limit](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit)), then over the Applications list and then over the `Application controlled HD subPath` if it allows to do so and has an account gap limit. -For persona this may not be possible, unless we impose some structure on the personas such as using a basic index. + +For the persona specification this may not be possible, unless we impose some structure on the personas such as using a basic index. ### Hardened and non-hardened indexes: privacy and functionality @@ -410,34 +410,34 @@ x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 where `x0` to `x7` are 20 bits. +Another alternative could be to use the plain website url and get rid of ens altogether but it would require another way to authenticate applications. See for instance [SLIP-0013](https://github.com/satoshilabs/slips/blob/master/slip-0013.md) for such a proposal. + ### Alternatives for application's authentification -For authentication we use ENS resolution, and browsing to a given url resolved -With ENS resolution and authentification homoglyph attack is not a problem since it will not leak kees from one domain to another. +For authentication we use ENS resolution, and browsing to a given url resolved. A few comments on this: -Caveats -* First connection requires the wallet to connect to ethereum mainnet, but once first resolution is done we could use some metadata param address for ethereum less authentication of the application (eg. application server signs a challenge message with the author address resolved in the ENS metadata) -* ENS resolution can change without the user knowing and then a different application/website may be granted access to his app keys. But this means the ENS name owner address was copromised. This would be similar to using a signing challenge authentified by a known public key. If this known public key is compromised we have a similar problem. +* First connection requires the wallet to connect to ethereum mainnet, but once first resolution is done we could use some metadata paramater such as `author address` for a blockchain less authentication of the application (e.g. application server signs a challenge message with the author address resolved in the ENS metadata). -Other metadata resolution through ENS that can be used alongside: -* author address: already mentionned above -* contract address: For app keys that would be designed to interact with a given ethereum contract (for instance app keys for a given token, if one desires to do so), other metadata fields could be used such as contract addresses. +* The url the name resolves to through ENS can change without the user knowing and then a different application/website may be granted access to his app keys. But this means the ENS name owner address was copromised. This would be similar to using a signing challenge authentified by a known public key. If this known public key is compromised we have a similar problem. -Alternative specs could +* Homoglyph attacks are not a bigger problem for `app keys` than it is for ENS since it will not grant access to `app keys` from the real domain (they would be derived along a different path). However homoglyph applications may lure the user to send funds from her main account to an `app key` of a malicious homoglyphic domain. +Other metadata resolution through ENS that can be used alongside: +* `author address`: already mentionned above +* `contract address`: For app keys that would be designed to interact with a given ethereum contract (for instance app keys for a given token, if one desires to do so), other metadata fields could be used such as contract addresses. +* [TBD] -### Allowing app keys to derive any subpath and index, even if preivous ones by enumeration are empty +In relation to the SLIP-0013 proposal mentionned above, one could think of alternative specifications that would use some certificate for authentification similar to https. -problem: applications won't be able to restore by enumeration -but if they do that to derive accounts maybe it's on purpose and they may backup this data somewhere -Also maybe wallets wants to include an address gap limit for the derivation by enumeration when importing -https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit +### An Account gap limit standard for application controlled hd sub-path? +If applications don't enumerate through their hd sub-path structure, we won't be able to restore `app keys` accounts by enumeration. However it has benefits to give total freedom to applications over the way they create accounts and use their sub-path. Also, it may be safe to assume that the part of the restoring procedure will be carried by the application itself and not by the wallets. The application will need a way to remember what accounts were derived for each user. ## Backwards Compatibility -No incompatibity since these are separate accounts -For applications that registered their user using main accounts eth addresses, they need to have a migration pattern to app keys accounts if desirable. +From a wallet point of view, there does not seem to be incompatibities since these are separate accounts from those that were used previously by wallets and they are supposed to be used along-side in synergy. + +However, for applications that associated in some way their users to their main accounts ethereum addresses may want to reflect on if and how they would like to leverage the power offered by `app keys` to migrate to them and increase their user's privacy, security and potentially also user-flow. From b23f54899a7c79f455b3eb29f9f0870bc6cd78a4 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 20:25:07 +0100 Subject: [PATCH 53/92] draft --- EIPS/eip-draft_app_keys.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 5a184f32b0f155..f2d839d85e1eb4 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -443,7 +443,9 @@ However, for applications that associated in some way their users to their main ## Test Cases +[TBD] +Provide some examples of accounts derived from a given mnemonic, persona, application and application's custom subpath. ## Implementation From e11bf88fee6109a102884f8cebb1ff89cfdf5a15 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 20:26:34 +0100 Subject: [PATCH 54/92] draft --- EIPS/eip-draft_app_keys.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index f2d839d85e1eb4..e1e185a3c1f090 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -449,9 +449,8 @@ Provide some examples of accounts derived from a given mnemonic, persona, applic ## Implementation -WIP -Link to hdkeyring methods - +[WIP] +[See here for an early implementation of the HD methods](https://github.com/MetaMask/KeyringController/blob/plugin-system/index.js) ## Examples: token contract: From 01ca7763366163f7aa9dec14d800a2e34afd2361 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 20:27:53 +0100 Subject: [PATCH 55/92] draft --- EIPS/eip-draft_app_keys.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index e1e185a3c1f090..dade0f64dd4a60 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -452,16 +452,23 @@ Provide some examples of accounts derived from a given mnemonic, persona, applic [WIP] [See here for an early implementation of the HD methods](https://github.com/MetaMask/KeyringController/blob/plugin-system/index.js) -## Examples: -token contract: +## Example use cases: + +* token contract: https://github.com/ethereum/EIPs/issues/85 -default account for dapps +* default account for dapps https://ethereum-magicians.org/t/default-accounts-for-dapps/904 -non wallet/crypto accounts +* non wallet/crypto accounts [EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) +* state channel application + +* privacy solution + +* ... + ## Acknowledgements MetaMask team From 8657ff45564fc3e5357920f471b79f226cd27c60 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 20:28:31 +0100 Subject: [PATCH 56/92] draft --- EIPS/eip-draft_app_keys.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index dade0f64dd4a60..6981636c0a86bd 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -480,8 +480,6 @@ Richard Moore Jeff Coleman -for discussions about the domain's hd path - ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From e2b4566821092fd1ff71416c5b021ad073d343fe Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 20:41:14 +0100 Subject: [PATCH 57/92] draft --- EIPS/eip-draft_app_keys.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 6981636c0a86bd..7d71ca8804bcd7 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -36,9 +36,9 @@ This ERC aims at finding a standard that will fit the needs of wallets and appli Wallets developers have agreed on an HD derivation path for ethereum accounts using BIP32, BIP44, SLIP44, [ERC84](https://github.com/ethereum/EIPs/issues/84). Web3 wallets have implemented in a roughly similar way the rpc eth api. EIP 1102 introduced privacy through non automatic opt-in of a wallet account into an app increasing privacy. -However several limitations remain in order to allow for a proper designs and UX for crypto permissioned apps. +However several limitations remain in order to allow for proper design and UX for crypto permissioned apps. -Most of UI based current wallets don't allow to: +Most of GUI based current wallets don't allow to: * being able to automatically and effortlessly use different keys / accounts for each apps, * being able to sign some app's action without prompting the user with the same level of security as sending funds from their main accounts, * being able to use throwable keys to improve anonymity, From 0f921097ca219fbad01e567085afb8bf20951198 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Fri, 22 Feb 2019 21:00:51 +0100 Subject: [PATCH 58/92] typo --- EIPS/eip-draft_app_keys.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 7d71ca8804bcd7..9e2691d4128611 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -19,7 +19,7 @@ replaces (*optional): EIP 1581 Among others cryptographic applications, scalability and privacy solutions for ethereum blockchain require that an user performs a significant amount of signing operations. It may also require her to watch some state and be ready to sign data automatically (e.g. sign a state or contest a withdraw in a state channel). The way wallets currently implement accounts poses several obstacles to the development of a complete web3.0 experience both in terms of UX, security and privacy. -This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given app. We propose to call them `app keys`. These accounts allow to isolate the accounts used for each app, thus increasing privacy. They also allow to give more control to the applications developpers over accounts management and signing delegation. For these app keys, wallets can have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally wallet can also implement a different behavior such as allowing to sign transactions without broadcasting them. +This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given app. We propose to call them `app keys`. They allow to isolate the accounts used for each application, thus increasing privacy. They also allow to give more control to the applications developpers over account management and signing delegation. For these app keys, wallets can have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally wallet can also implement a different behavior such as allowing to sign transactions without broadcasting them. This new accounts type can allow to significantly improve UX and permit new designs for apps of the crypto permissionned web. From fbf39eb677aa69ca99bceb2219c791cd3e103db2 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Mon, 25 Feb 2019 07:44:24 +0100 Subject: [PATCH 59/92] draft --- EIPS/eip-draft_app_keys.md | 34 ++++++++++++++++++++-------------- 1 file changed, 20 insertions(+), 14 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index 9e2691d4128611..b44c0ff00a228a 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -17,11 +17,11 @@ replaces (*optional): EIP 1581 ## Simple Summary -Among others cryptographic applications, scalability and privacy solutions for ethereum blockchain require that an user performs a significant amount of signing operations. It may also require her to watch some state and be ready to sign data automatically (e.g. sign a state or contest a withdraw in a state channel). The way wallets currently implement accounts poses several obstacles to the development of a complete web3.0 experience both in terms of UX, security and privacy. +Among others cryptographic applications, scalability and privacy solutions for ethereum blockchain require that an user performs a significant amount of signing operations. It may also require her to watch some state and be ready to sign data automatically (e.g. sign a state or contest a withdraw). The way wallets currently implement accounts poses several obstacles to the development of a complete web3.0 experience both in terms of UX, security and privacy. -This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given app. We propose to call them `app keys`. They allow to isolate the accounts used for each application, thus increasing privacy. They also allow to give more control to the applications developpers over account management and signing delegation. For these app keys, wallets can have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally wallet can also implement a different behavior such as allowing to sign transactions without broadcasting them. +This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given application. We propose to call them `app keys`. They allow to isolate the accounts used for each application, thus increasing privacy. They also allow to give more control to the applications developpers over account management and signing delegation. For these app keys, wallets can have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally wallets can also implement a different behavior such as allowing to sign transactions without broadcasting them. -This new accounts type can allow to significantly improve UX and permit new designs for apps of the crypto permissionned web. +This new accounts type can allow to significantly improve UX and permit new designs for applications of the crypto permissionned web. ## Abstract @@ -244,19 +244,25 @@ Depending on user choice, the user will be prompted for signing confirmations or ### Ethereum accounts methods: -* `appKey_eth_getPublicKey(hdSubPath) returns 64 bytes` -0x80b994e25fb98f69518b1a03e59ddf4494a1a86cc66019131a732ff4a85108fbb86491e2bc423b2cdf6f1f0f4468ec73db0535a1528ca192d975116899289a4b +* `appKey_eth_getPublicKey(hdSubPath) returns publicKey 64 bytes`: -* `appKey_eth_getAddress(hdSubPath) returns 20 bytes` -hdSubPath: string -"index_i / index_(i+1) '", can use hardening -e.g. 0x9df77328a2515c6d529bae90edf3d501eaaa268e +`hdSubPath` string with BIP32 format, "index_i / index_(i+1) '", can use hardening -* `appKey_eth_derivePublicKeyFromParent(parentPublicKey, hdSubPath) returns 64 bytes` -hdSubPath: string should not be hardened +`publicKey` returns e.g. 0x80b994e25fb98f69518b1a03e59ddf4494a1a86cc66019131a732ff4a85108fbb86491e2bc423b2cdf6f1f0f4468ec73db0535a1528ca192d975116899289a4b -* `appKey_eth_getAddressForPublicKey(publicKey) returns 20 bytes` -publicKey 64 bytes +* `appKey_eth_getAddress(hdSubPath) returns address 20 bytes`: + +`hdSubPath`: string with BIP32 format, "index_i / index_(i+1) '", can use hardening + +`address` e.g. 0x9df77328a2515c6d529bae90edf3d501eaaa268e + +* `appKey_eth_derivePublicKeyFromParent(parentPublicKey, hdSubPath) returns publicKey 64 bytes` + +`hdSubPath`: string with BIP32 format, "index_i / index_(i+1) '", should not use hardening here. + +* `appKey_eth_getAddressForPublicKey(publicKey) returns address 20 bytes` + +`publicKey` 64 bytes ### Ethereum signing methods: @@ -467,7 +473,7 @@ https://ethereum-magicians.org/t/default-accounts-for-dapps/904 * privacy solution -* ... +* non custodian cross cryptocurrency exchange... ## Acknowledgements MetaMask team From 0a2faf4217745c85e22963b63bc4f2f26040d1fa Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Mon, 25 Feb 2019 11:29:41 +0100 Subject: [PATCH 60/92] eips urls --- EIPS/eip-draft_app_keys.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index b44c0ff00a228a..b4b988aa515da4 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -523,11 +523,11 @@ https://github.com/ethereum/EIPs/blob/d8476ef1c861eb578bb6e9057ff52a71f3cd10e4/E ### ENS: -[EIP137: Ethereum Domain Name Service - specification](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-137.md) +[EIP137: Ethereum Domain Name Service - specification](https://eips.ethereum.org/EIPS/eip-137) -[EIP165: Standard Interface Detection](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-165.md) +[EIP165: Standard Interface Detection](https://eips.ethereum.org/EIPS/eip-165) -[EIP634: Storage of text record in ENS](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-634.md) +[EIP634: Storage of text record in ENS](https://eips.ethereum.org/EIPS/eip-634) [ENS docs about namehash:](http://docs.ens.domains/en/latest/implementers.html#namehash) From 8f4b13d9f49c819ad70273ce137c9b28bf0b4e53 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Mon, 25 Feb 2019 12:26:32 +0100 Subject: [PATCH 61/92] polish --- EIPS/eip-draft_app_keys.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft_app_keys.md index b4b988aa515da4..08c7bcbf8ba4b9 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft_app_keys.md @@ -25,12 +25,11 @@ This new accounts type can allow to significantly improve UX and permit new desi ## Abstract -In a wallet, an user often holds most of her funds in her main accounts. These accounts require a significant level of security and should not be delegated in any way, this significantly impacts the design of crypto apps if a user has to manually confirm every transaction. Also often an user uses the same accounts accross apps, which is a privacy and potentially also a security issue. +In a wallet, an user often holds most of her funds in her main accounts. These accounts require a significant level of security and should not be delegated in any way, this significantly impacts the design of cryptographic applications if a user has to manually confirm every action. Also often an user uses the same accounts across apps, which is a privacy and potentially also a security issue. -We introduce here a new account type, app keys, which permits signing delegation and accounts isolation accross apps for privacy and security. +We introduce here a new account type, app keys, which permits signing delegation and accounts isolation across applications for privacy and security. -In this EIP, we provide a proposal how to uniquely identify and authenticate each app, how to derive the accounts along an HDpath restricted for the domain and we finally define an API for apps to derive and use these app keys. -This ERC aims at finding a standard that will fit the needs of wallets and application developers while also allowing app keys to be used across wallets and yield the same accounts for the user for each app. +In this EIP, we provide a proposal how to uniquely identify and authenticate each application, how to derive the accounts along an Hierachical Deterministic (HD) path restricted for the domain and we finally define an API for applications to derive and use these app keys. This ERC aims at finding a standard that will fit the needs of wallets and application developers while also allowing app keys to be used across wallets and yield the same accounts for the user for each application. ## Motivation From c0608fbcfa9c541431e6ed2efd1c3160ded49c1a Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Mon, 25 Feb 2019 14:19:57 +0100 Subject: [PATCH 62/92] renamed and fixed typo --- EIPS/{eip-draft_app_keys.md => eip-draft-app-keys.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename EIPS/{eip-draft_app_keys.md => eip-draft-app-keys.md} (99%) diff --git a/EIPS/eip-draft_app_keys.md b/EIPS/eip-draft-app-keys.md similarity index 99% rename from EIPS/eip-draft_app_keys.md rename to EIPS/eip-draft-app-keys.md index 08c7bcbf8ba4b9..9e53a87e5f5fd5 100644 --- a/EIPS/eip-draft_app_keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -369,7 +369,7 @@ We did not find a list of BIP43 purpose code so here is what we could gather: | 84 | [BIP-0084](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) | Derivation scheme for P2WPKH based accounts | | 535348 | [Ledger app ssh](https://github.com/LedgerHQ/ledger-app-ssh-agent/blob/master/getPublicKey.py#L49) | | | 80475047| [GPG/SSH Ledger](https://github.com/LedgerHQ/ledger-app-openpgp-card/blob/master/doc/developper/gpgcard3.0-addon.rst#deterministic-key-derivation)| | -| # | [EIP #](#)| App Keys: application specific wallet accounts | +| ??? | EIP Number| App Keys: application specific wallet accounts | ### Alternatives for application's identification From 98664e1e601171404cdcd4b396ad7dd7942f8b44 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Tue, 26 Feb 2019 07:34:37 +0100 Subject: [PATCH 63/92] discussion link --- EIPS/eip-draft-app-keys.md | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index 9e53a87e5f5fd5..e8dba5e6d4e7f8 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -2,9 +2,9 @@ eip: title: App Keys: application specific wallet accounts author: -Vincent Eli [Bunjin](https://github.com/Bunjin) -Dan Finlay [DanFinlay](https://github.com/DanFinlay) -discussions-to: +Vincent Eli (@Bunjin) +Dan Finlay (@DanFinlay) +discussions-to: https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742 status: Draft type: Standards Track category: ERC @@ -475,15 +475,7 @@ https://ethereum-magicians.org/t/default-accounts-for-dapps/904 * non custodian cross cryptocurrency exchange... ## Acknowledgements -MetaMask team - -Christian Lundkvist - -Liam Horne - -Richard Moore - -Jeff Coleman +MetaMask team, Christian Lundkvist, Counterfactual team, Liam Horne, Richard Moore, Jeff Coleman. ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From cdb9b92ce99fdeae9f3057a7094b2d27f45f540e Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Tue, 26 Feb 2019 09:36:27 +0100 Subject: [PATCH 64/92] formating --- EIPS/eip-draft-app-keys.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index e8dba5e6d4e7f8..d87a61cce4d0a7 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -4,7 +4,7 @@ title: App Keys: application specific wallet accounts author: Vincent Eli (@Bunjin) Dan Finlay (@DanFinlay) -discussions-to: https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742 +discussions-to:[Fellowship of Ethereum Magicians](https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742) status: Draft type: Standards Track category: ERC From ef93e0911608e98722238f9fd830ab68dd699e62 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 27 Feb 2019 08:54:39 +0100 Subject: [PATCH 65/92] reference to Vitalik's meta discussion about privacy, introduce paranoia mode for api, acknowledgements --- EIPS/eip-draft-app-keys.md | 67 +++++++++++++++++++++++++------------- 1 file changed, 45 insertions(+), 22 deletions(-) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index d87a61cce4d0a7..2141e0052ae3aa 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -62,11 +62,11 @@ Once connected to a wallet, an application can request to access a set of accoun Using the BIP 32 and BIP 39 standards, we propose to use the following HD path for each app keys: -`m / [EIP#]' / [persona path]' / [application uniquely assigned path]' / [app's custom subpath]` +`m / [EIP Number]' / [persona path]' / [application uniquely assigned path]' / [app's custom subpath]` Where: -`EIP#` is the EIP number that will be assigned to this EIP and we harden it. We use a different path than 44' since it's not bip44 compliant. At this point, I'm not sure if there is a list of BIP43 codes of standards following the `purpose` field specification of [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki). +`EIP Number` is the EIP number that will be assigned to this EIP and we harden it. We use a different path than 44' since it's not bip44 compliant. At this point, I'm not sure if there is a list of BIP43 codes of standards following the `purpose` field specification of [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki). `persona path` allows to use applications with different and isolated personas (or in other words accounts) that are tracable by the application. They will still be fully restorable from the same mnemonic. @@ -197,7 +197,7 @@ The derivation sub-path would be: It does not seem to really matter which method we pick between these 2 decomposition approaches, there is a trade-off between computational efficiency (having less depth) and having an homegenous decomposition. We tend to favor the approach with an homogenous decomposition. -### Application customisable HD sub path +### Application customisable HD sub path Finally, the last part of the hd path is under the application's control. This will allow applications developers to use the HD path structure that best fits their needs. Developers can for instance, among any combination of other parameters they like, choose to include a `version` field if they would like to use different signing accounts when updating to a new version. They can then also manage the user accounts in the way they would like, for instance including or not an index for `sets of accounts` (called `accounts` in BIP44), an index for `change` and an index for `account` (called `address_index` in BIP44). We consider that a given child on the HD tree should be called an `account` and not an `address` since it is composed of a private key, a public key and an address. @@ -212,7 +212,7 @@ Q [Should we set a limit on the persona and application customsable hd path numb ``` Dummy data: -EIP#: 12345 +EIP Number: 12345 personaPath: 0'/712' application's name: foo.bar.eth uid: 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 @@ -223,7 +223,8 @@ app custom path params: app_version,yy set_of_accounts_index, account_index ## API: -RPC methods +We propose to introduce new RPC methods but they should be restricted and wrapped such that some parameters (e.g. domain name) are imposed by the wallet on the caller depending on the caller's authentification. + ### App keys exposure: * `wallet.appkey.enable(options)` @@ -274,17 +275,27 @@ tx is ethereum-js tx object ### Other potential methods: -#### Other cryptocurrencies +#### Other cryptocurrencies: We defined for now Ethereum accounts and signing methods. However, one could do the same for other cryptocurrencies deriving accounts along their standards. This may open to some very interesting cross-blockchains application designs. -#### Other cryptographic methods -Similarly, using entropy provided by the HD Path, one could think of other cryptographic methods such as encryption. +#### Other cryptographic methods: +Similarly, using entropy provided by the HD Path, one could think of other cryptographic methods such as encryption and also other curve types. + -#### Storage +#### Storage: The HD path for each application can also be used as a key to isolate databases for user's persistent data. We could introduce methods that allow to read and write in a database specific to the application. Q [Benefit of this compared to using classical browser local storage?] +### API permissions and confirmations from users: + +#### Initial permission request and full access afterwards: + +Each wallet has freedom in the way they implement their permission system along with this EIP and this API. We tend to favor a design where the applications would request once and for all full access to the applications keys (for their domain) and that the user has to confirm this once. From then on, any account derivation or signing for those applications keys will not prompt a confirmation request on the wallet side. +However applications themselves are free to reproduce some confirmation at their own level if they would like the users to double check the transactions or signatures they are making at the application level. This will be of course dependent on trusting the application code. + +#### Paranoia mode: +However, we would like to give users the option to monitor at any point applications keys and how applications user them. We therefore encourage wallets to introduce a `paranoia mode` that users can activate (for instance in the wallet advanced settings) to force confirmations request for all the applications keys actions. ## Rationale @@ -372,26 +383,36 @@ We did not find a list of BIP43 purpose code so here is what we could gather: | ??? | EIP Number| App Keys: application specific wallet accounts | -### Alternatives for application's identification +### Application's identification -#### Shortening the ENS node +#### On using a centraly maintened index of application uids -Our current approach uses identification through an ENS name converted to a hash node and sliced fully but one could keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the chance of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to bytes32. +[EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) +also discussed [here](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) proposes a scheme that relies on a list of indexes where application should register (similar to SLIP0044 list for instance). + +We think our approach while also being more englobing benefits from not requiring a centrally maintained registry. In our approach every application has already a potential unique identifier assigned to it. -#### Names not restricted to ens domains? +#### Favoring a deterministic scheme for application uids -Should we allow names that are not .eth domains? We may want to be able to handle DNS names for instance without using an ENS proxy (ie. a .eth domain point to a DNS url). They would have to be resolved differently because ENS does not allow other TLDs. +Quoting Vitalik in his post [Meta: we should value privacy more](https://ethereum-magicians.org/t/meta-we-should-value-privacy-more/2475), we indeed favor a deterministic scheme for applications specific accounts generation: ``` -No, TLDs are restricted to only .eth (on mainnet), or .eth and .test (on Ropsten), plus any special purpose TLDs such as those required to permit reverse lookups. There are no immediate plans to invite proposals for additional TLDs. In large part this is to reduce the risk of a namespace collision with the IANA DNS namespace. +It would be nice to keep wallet software stateless, so users can easily export and import their keys between wallets; this implies using some deterministic scheme like privkey_for_dapp = hash(master_key + dapp_id). But then what is the dapp_id? How would that work for multi-contract dapps? ``` -#### Using a centraly maintened index of application uids +And we proposed to use the ENS domain hash, or node, as the dapp_id and to use a BIP32 structure instead to derive the private keys. -[EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) -also discussed [here](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) proposes a scheme that relies on a list of indexes where application should register (similar to SLIP0044 list for instance). +#### Shortening the ENS node -We think our approach while also being more englobing benefits from not requiring a centrally maintained registry. In our approach every application has already a potential unique identifier assigned to it. +Our current approach uses identification through an ENS name converted to a hash node and sliced fully but one could potentially keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the chance of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to hashes. + +#### Names not restricted to ENS domains? + +Should we allow names that are not .eth domains? We may want to be able to handle DNS names for instance without using an ENS proxy (ie. a .eth domain point to a DNS url). They would have to be resolved differently because ENS does not allow other TLDs. + +``` +No, TLDs are restricted to only .eth (on mainnet), or .eth and .test (on Ropsten), plus any special purpose TLDs such as those required to permit reverse lookups. There are no immediate plans to invite proposals for additional TLDs. In large part this is to reduce the risk of a namespace collision with the IANA DNS namespace. +``` #### Alternative application identification specification @@ -417,7 +438,7 @@ where `x0` to `x7` are 20 bits. Another alternative could be to use the plain website url and get rid of ens altogether but it would require another way to authenticate applications. See for instance [SLIP-0013](https://github.com/satoshilabs/slips/blob/master/slip-0013.md) for such a proposal. -### Alternatives for application's authentification +### Application's authentification For authentication we use ENS resolution, and browsing to a given url resolved. A few comments on this: @@ -475,7 +496,7 @@ https://ethereum-magicians.org/t/default-accounts-for-dapps/904 * non custodian cross cryptocurrency exchange... ## Acknowledgements -MetaMask team, Christian Lundkvist, Counterfactual team, Liam Horne, Richard Moore, Jeff Coleman. +MetaMask team, Christian Lundkvist, Counterfactual team, Liam Horne, Erik Bryn, Richard Moore, Jeff Coleman. ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). @@ -522,7 +543,9 @@ https://github.com/ethereum/EIPs/blob/d8476ef1c861eb578bb6e9057ff52a71f3cd10e4/E [ENS docs about namehash:](http://docs.ens.domains/en/latest/implementers.html#namehash) -### Previous proposals related to app keys +### Previous proposals and discussions related to app keys +[Meta: we should value privacy more](https://ethereum-magicians.org/t/meta-we-should-value-privacy-more/2475) + [EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) [EIP 1581: discussion](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) From 690e6d46f368ce1d5e79d7ea88ebcff35c2aafe0 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 27 Feb 2019 08:57:01 +0100 Subject: [PATCH 66/92] formatting --- EIPS/eip-draft-app-keys.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index 2141e0052ae3aa..9a16f2e9d89de8 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -1,16 +1,14 @@ --- eip: title: App Keys: application specific wallet accounts -author: -Vincent Eli (@Bunjin) -Dan Finlay (@DanFinlay) -discussions-to:[Fellowship of Ethereum Magicians](https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742) +author: Vincent Eli (@Bunjin), Dan Finlay (@DanFinlay) +discussions-to: https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742 status: Draft type: Standards Track category: ERC created: 2019-02-20 -requires (*optional): BIP32, BIP43, EIP137, EIP165, -replaces (*optional): EIP 1581 +requires: BIP32, BIP43, EIP137, EIP165 +replaces: EIP 1581 --- From 4325bb6e20c8110ac063c10f4bc98bd7bd04bd4b Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 27 Feb 2019 09:02:11 +0100 Subject: [PATCH 67/92] refactor --- EIPS/eip-draft-app-keys.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index 9a16f2e9d89de8..f3217d8b18acca 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -383,13 +383,6 @@ We did not find a list of BIP43 purpose code so here is what we could gather: ### Application's identification -#### On using a centraly maintened index of application uids - -[EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) -also discussed [here](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) proposes a scheme that relies on a list of indexes where application should register (similar to SLIP0044 list for instance). - -We think our approach while also being more englobing benefits from not requiring a centrally maintained registry. In our approach every application has already a potential unique identifier assigned to it. - #### Favoring a deterministic scheme for application uids Quoting Vitalik in his post [Meta: we should value privacy more](https://ethereum-magicians.org/t/meta-we-should-value-privacy-more/2475), we indeed favor a deterministic scheme for applications specific accounts generation: @@ -397,9 +390,16 @@ Quoting Vitalik in his post [Meta: we should value privacy more](https://ethereu ``` It would be nice to keep wallet software stateless, so users can easily export and import their keys between wallets; this implies using some deterministic scheme like privkey_for_dapp = hash(master_key + dapp_id). But then what is the dapp_id? How would that work for multi-contract dapps? ``` - And we proposed to use the ENS domain hash, or node, as the dapp_id and to use a BIP32 structure instead to derive the private keys. +#### Alternative: using a centraly maintened index of application uids + +[EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) +also discussed [here](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) proposes a scheme that relies on a list of indexes where application should register (similar to SLIP0044 list for instance). + +We think our approach while also being more englobing benefits from not requiring a centrally maintained registry. In our approach every application has already a potential unique identifier assigned to it. + + #### Shortening the ENS node Our current approach uses identification through an ENS name converted to a hash node and sliced fully but one could potentially keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the chance of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to hashes. From 528a3787e4fa9c5f830c475e6bb1f0471fcf4c1d Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 27 Feb 2019 09:49:56 +0100 Subject: [PATCH 68/92] mention DNS certs --- EIPS/eip-draft-app-keys.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index f3217d8b18acca..d6da1f57952a77 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -88,7 +88,7 @@ E.g. `0'` or `0'/1/2'/0` or `1d7b'/a41c'` We need a way to uniquely identify each application. -In our favored spec, each application is uniquely defined and authentified by its name, a domain string. For applications to be resolved through the Ethereum Name Service (ENS), they need to be a using a .eth domain name (e.g. foo.bar.eth). Note that the proposed spec does not restrict the applications' names to be following the .eth standard but they would need to be authentified differently (see below). +In our favored spec, each application is uniquely defined and authenticated by its name, a domain string. For applications to be resolved through the Ethereum Name Service (ENS), they need to be a using a .eth domain name (e.g. foo.bar.eth). Note that the proposed spec does not restrict the applications' names to be following the .eth standard but they would need to be authenticated differently (see below). There are a few restrictions however on the characters used and normalisation, each name should be passed through the [NamePrep Algorithm](https://tools.ietf.org/html/rfc3491) @@ -147,7 +147,7 @@ The interface ID of this interface is 0x59d1d43c. The text data may be any arbitrary UTF-8 string. If the key is not present, the empty string must be returned. ``` -One can think of other authentification methods and even use some of them alongside the url-resolution method through ENS. We mention other methods in the [Rationale](#Rationale) section. +One can think of other authentication methods and even use some of them alongside the url-resolution method through ENS. We mention other methods in the [Rationale](#Rationale) section. We suggest for instance to also add an `authorEthAddress` text metadata field that can be used to authenticate messages from the application, with for instance a sign challenge. @@ -221,7 +221,7 @@ app custom path params: app_version,yy set_of_accounts_index, account_index ## API: -We propose to introduce new RPC methods but they should be restricted and wrapped such that some parameters (e.g. domain name) are imposed by the wallet on the caller depending on the caller's authentification. +We propose to introduce new RPC methods but they should be restricted and wrapped such that some parameters (e.g. domain name) are imposed by the wallet on the caller depending on the caller's authentication. ### App keys exposure: @@ -406,7 +406,7 @@ Our current approach uses identification through an ENS name converted to a hash #### Names not restricted to ENS domains? -Should we allow names that are not .eth domains? We may want to be able to handle DNS names for instance without using an ENS proxy (ie. a .eth domain point to a DNS url). They would have to be resolved differently because ENS does not allow other TLDs. +Should we allow names that are not .eth domains? We may want to be able to handle DNS names for instance without using an ENS proxy (ie. a .eth domain point to a DNS url). They would have to be resolved and authenticated differently because ENS does not allow other TLDs. We can probably design an authentication scheme based on DNS certificates. ``` No, TLDs are restricted to only .eth (on mainnet), or .eth and .test (on Ropsten), plus any special purpose TLDs such as those required to permit reverse lookups. There are no immediate plans to invite proposals for additional TLDs. In large part this is to reduce the risk of a namespace collision with the IANA DNS namespace. @@ -436,7 +436,7 @@ where `x0` to `x7` are 20 bits. Another alternative could be to use the plain website url and get rid of ens altogether but it would require another way to authenticate applications. See for instance [SLIP-0013](https://github.com/satoshilabs/slips/blob/master/slip-0013.md) for such a proposal. -### Application's authentification +### Application's authentication For authentication we use ENS resolution, and browsing to a given url resolved. A few comments on this: @@ -451,7 +451,7 @@ Other metadata resolution through ENS that can be used alongside: * `contract address`: For app keys that would be designed to interact with a given ethereum contract (for instance app keys for a given token, if one desires to do so), other metadata fields could be used such as contract addresses. * [TBD] -In relation to the SLIP-0013 proposal mentionned above, one could think of alternative specifications that would use some certificate for authentification similar to https. +In relation to the SLIP-0013 proposal mentionned above, one could think of alternative specifications that would use some certificate for authentication similar to https. ### An Account gap limit standard for application controlled hd sub-path? From a6667e55564af5fc1466d3bb0caf41113f9294fc Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 27 Feb 2019 09:59:54 +0100 Subject: [PATCH 69/92] adding use case --- EIPS/eip-draft-app-keys.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index d6da1f57952a77..6338af56d86593 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -478,6 +478,9 @@ Provide some examples of accounts derived from a given mnemonic, persona, applic ## Example use cases: +* signing transactions without broadcasting them: +https://github.com/MetaMask/metamask-extension/issues/3475 + * token contract: https://github.com/ethereum/EIPs/issues/85 From 0e5e9481dc0f6308fdd4ad3601e1793806f85d2e Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 27 Feb 2019 13:15:08 +0100 Subject: [PATCH 70/92] typo --- EIPS/eip-draft-app-keys.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index 6338af56d86593..205ef5ab2f2730 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -77,7 +77,7 @@ Note that we suggest that each of these indexes, except those belonging to the a ### Personas -We allow the user to use different personas in combination to her mnemonic to potentially fully isolate her interact with a given app accross personas. One can use this for instance to create a personal and business profile for a given's domain both backup up from the same mnemonic, using 2 different personnas indexes. The app or domain, will not be aware that it is the same person and mnemonic behind both. +We allow the user to use different personas in combination to her mnemonic to potentially fully isolate her interaction with a given app accross personas. One can use this for instance to create a personal and business profile for a given's domain both backup up from the same mnemonic, using 2 different personnas indexes. The app or domain, will not be aware that it is the same person and mnemonic behind both. We use a string following BIP32 format (can be hardened) to define personas. The indexes should be hex under 0x80000000, 31 bits. From fd56cc3363f1a4b48ba85cf1c54524a1ed5eb0fc Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 27 Feb 2019 19:20:52 +0100 Subject: [PATCH 71/92] typo --- EIPS/eip-draft-app-keys.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index 205ef5ab2f2730..a8c4e920c00f00 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -214,7 +214,7 @@ EIP Number: 12345 personaPath: 0'/712' application's name: foo.bar.eth uid: 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 -app custom path params: app_version,yy set_of_accounts_index, account_index +app custom path params: app_version, set_of_accounts_index, account_index ``` `m/12345'/0'/712'/6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3'/0'/0'/0` From 0552fabe528df6785bb03b191fb788aaa34e7ba9 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Wed, 27 Feb 2019 19:39:12 +0100 Subject: [PATCH 72/92] small refactor on options for enable --- EIPS/eip-draft-app-keys.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index a8c4e920c00f00..6499911c09e4ae 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -230,16 +230,12 @@ This method allows to install app keys (getting user permission to use and allow may be merged with EIP1102 enable? -[TBD] where `options` is a javascript object containing the permissions requested for these app keys: -* delegate account creation and signing to application for these keys -* access and use the local storage under these keys +[TBD] where `options` is a javascript object containing the permissions requested for these app keys. Uses the persona selected by the user (not known nor controllable by application). Uses the domain ens namehash (node) that was resolved to load window (not provided by application itself) -Depending on user choice, the user will be prompted for signing confirmations or not for those app keys - ### Ethereum accounts methods: * `appKey_eth_getPublicKey(hdSubPath) returns publicKey 64 bytes`: From 60293cea1b3d20b896f3f0e3de90fd4aecfb5cca Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 28 Feb 2019 16:04:25 +0100 Subject: [PATCH 73/92] improve .enable() --- EIPS/eip-draft-app-keys.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index 6499911c09e4ae..333ef80b791986 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -17,7 +17,7 @@ replaces: EIP 1581 Among others cryptographic applications, scalability and privacy solutions for ethereum blockchain require that an user performs a significant amount of signing operations. It may also require her to watch some state and be ready to sign data automatically (e.g. sign a state or contest a withdraw). The way wallets currently implement accounts poses several obstacles to the development of a complete web3.0 experience both in terms of UX, security and privacy. -This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given application. We propose to call them `app keys`. They allow to isolate the accounts used for each application, thus increasing privacy. They also allow to give more control to the applications developpers over account management and signing delegation. For these app keys, wallets can have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally wallets can also implement a different behavior such as allowing to sign transactions without broadcasting them. +This proposal describes a standard and api for a new type of wallet accounts that are derived specifically for a each given application. We propose to call them `app keys`. They allow to isolate the accounts used for each application, thus potentially increasing privacy. They also allow to give more control to the applications developpers over account management and signing delegation. For these app keys, wallets can have a more permissive level of security (e.g. not requesting user's confirmation) while keeping main accounts secure. Finally wallets can also implement a different behavior such as allowing to sign transactions without broadcasting them. This new accounts type can allow to significantly improve UX and permit new designs for applications of the crypto permissionned web. @@ -58,7 +58,7 @@ Once connected to a wallet, an application can request to access a set of accoun ### Applications' HD path -Using the BIP 32 and BIP 39 standards, we propose to use the following HD path for each app keys: +Using the BIP 32 and BIP 43 standards, we propose to use the following HD path for each app keys: `m / [EIP Number]' / [persona path]' / [application uniquely assigned path]' / [app's custom subpath]` @@ -226,11 +226,11 @@ We propose to introduce new RPC methods but they should be restricted and wrappe ### App keys exposure: * `wallet.appkey.enable(options)` -This method allows to install app keys (getting user permission to use and allow him to select the persona she would like to use). - -may be merged with EIP1102 enable? +This method allows to enable app keys (getting user permission to use and allow him to select the persona she would like to use). +[TBD] Could return the root account public key from the path without the application's subPath. Hence from this one could derive all non hardened childs public keys of the app's keys. [TBD] where `options` is a javascript object containing the permissions requested for these app keys. +Options could also include a challenge to be signed by the app's root account (would serve as authentication of the users from the app's perspective) Uses the persona selected by the user (not known nor controllable by application). @@ -266,6 +266,7 @@ tx is ethereum-js tx object * `appKey_eth_sign(fromAddress, message)` * `appKey_eth_personalSign(fromAddress, message)` * `appKey_eth_signTypedMessage(fromAddress, message)` +EIP712 ### Other potential methods: From 3dbdf58686108c38b926c3ec979aba67c52b8584 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Thu, 28 Feb 2019 16:06:28 +0100 Subject: [PATCH 74/92] improve .enable() --- EIPS/eip-draft-app-keys.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index 333ef80b791986..3ba4cde1ef30d9 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -228,7 +228,7 @@ We propose to introduce new RPC methods but they should be restricted and wrappe * `wallet.appkey.enable(options)` This method allows to enable app keys (getting user permission to use and allow him to select the persona she would like to use). -[TBD] Could return the root account public key from the path without the application's subPath. Hence from this one could derive all non hardened childs public keys of the app's keys. +[TBD] Could return the account public key from the HD path before `the app's custom subPath`. Hence from this app's root account, one could derive all non hardened childs public keys of the app's keys. [TBD] where `options` is a javascript object containing the permissions requested for these app keys. Options could also include a challenge to be signed by the app's root account (would serve as authentication of the users from the app's perspective) From d69b5d101639ff01a9ec1e2ce50116e331020c5f Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Sun, 3 Mar 2019 09:28:17 +0100 Subject: [PATCH 75/92] added support for DNS, options for .enable, signing challenge --- EIPS/eip-draft-app-keys.md | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index 3ba4cde1ef30d9..01eac4ae4ef7c1 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -86,9 +86,11 @@ E.g. `0'` or `0'/1/2'/0` or `1d7b'/a41c'` ### Applications' Unique Identifiers -We need a way to uniquely identify each application. +#### Applications Names -In our favored spec, each application is uniquely defined and authenticated by its name, a domain string. For applications to be resolved through the Ethereum Name Service (ENS), they need to be a using a .eth domain name (e.g. foo.bar.eth). Note that the proposed spec does not restrict the applications' names to be following the .eth standard but they would need to be authenticated differently (see below). +We need a way to uniquely identify each application. We will use a naming and a hashing scheme. + +In our favored spec, each application is uniquely defined and authenticated by its name, a domain string. It can be a Domain Name Service DNS name or and Ethereum Name Service ENS name. There are a few restrictions however on the characters used and normalisation, each name should be passed through the [NamePrep Algorithm](https://tools.ietf.org/html/rfc3491) @@ -101,7 +103,9 @@ Normalising and validating names Before a name can be converted to a node hash using Namehash, the name must first be normalised and checked for validity - for instance, converting fOO.eth into foo.eth, and prohibiting names containing forbidden characters such as underscores. It is crucial that all applications follow the same set of rules for normalisation and validation, as otherwise two users entering the same name on different systems may resolve the same human-readable name into two different ENS names. ``` -The ENS uses an hashing scheme to associate a domain to a unique hash, `node`, through the `namehash` function +#### Hashing and Applications UIDs + +The ENS uses an hashing scheme to associate a domain to a unique hash, `node`, through the `namehash` function. We will use this hashing scheme both for ENS and for DNS names. This gives an unique identifier (UID) of 32 bytes. @@ -133,7 +137,9 @@ We thus propose to use the node of each app's domain as a unique identifier for ### Applications' authentication -In the case of our favored specification for applications' UIDs using ENS, we can authenticate the application through ENS resolution. +If the application is using a DNS name then we simply authenticate the application by using the url of the loaded browser webpage. + +For applications using ENS, we can authenticate the application through ENS resolution. The ENS can also allow to register and resolve metadata for the application such as `url`, and other parameters. If we use for instance this resolver profile defined in [EIP 634](https://eips.ethereum.org/EIPS/eip-634) which permits the lookup of arbitrary key-value text data, we can for instance use the key `url` to point to a website. @@ -229,8 +235,11 @@ We propose to introduce new RPC methods but they should be restricted and wrappe This method allows to enable app keys (getting user permission to use and allow him to select the persona she would like to use). [TBD] Could return the account public key from the HD path before `the app's custom subPath`. Hence from this app's root account, one could derive all non hardened childs public keys of the app's keys. + [TBD] where `options` is a javascript object containing the permissions requested for these app keys. -Options could also include a challenge to be signed by the app's root account (would serve as authentication of the users from the app's perspective) +Options could also include a challenge to be signed by the app's root account (would serve as authentication of the users from the app's perspective). The signature should then be also returned. + +Options should also include a parameter for the application to indicate which name should be used to compute the domain's HD path. That's required for applications that are loaded through ENS. They could be authenticated either through ENS or through DNS. These applications may like to use the DNS name even when they are resolved through ENS. (e.g. an application that just upgraded to ENS may like to continue using DNS paths to be retro-compatible for its former users). Uses the persona selected by the user (not known nor controllable by application). @@ -345,6 +354,9 @@ For instance if we don't harden the application path, in case a persona public k However the app can use non hardened indexes in their custom path part to be able to benefit from guessing child public keys from parent one (for instance for counterfactual state channel interaction accross 2 peers that would like to use new keys every time they counterfactually instantiate a new sub app). +### Privacy and the funding trail: + + ### Alternatives for the HD derivation path @@ -358,7 +370,7 @@ It is of course not be BIP44 compliant which uses the following tree level struc One could think of alternative specifications deviating from BIP43 or even BIP32. Or on the contrary, one could try to become BIP44 compliant, although we do not really see the benefit of that for app keys and it would impose serious limitations on how to identify the applications using potentially the `coin_type` field. -### Alternatives for the HD derivation path purpose field +### HD derivation path purpose field If we agree on not using BIP44 but following BIP32 and BIP43, we need to settle on a purpose field. We proposed to used the number that will be assigned to this EIP and we should research @@ -401,14 +413,6 @@ We think our approach while also being more englobing benefits from not requirin Our current approach uses identification through an ENS name converted to a hash node and sliced fully but one could potentially keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the chance of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to hashes. -#### Names not restricted to ENS domains? - -Should we allow names that are not .eth domains? We may want to be able to handle DNS names for instance without using an ENS proxy (ie. a .eth domain point to a DNS url). They would have to be resolved and authenticated differently because ENS does not allow other TLDs. We can probably design an authentication scheme based on DNS certificates. - -``` -No, TLDs are restricted to only .eth (on mainnet), or .eth and .test (on Ropsten), plus any special purpose TLDs such as those required to permit reverse lookups. There are no immediate plans to invite proposals for additional TLDs. In large part this is to reduce the risk of a namespace collision with the IANA DNS namespace. -``` - #### Alternative application identification specification For the application unique identifiers, an alternative specification could favor using an `ethereum author address` and including a signed message challenge for author for authentication. From ccceceb9d932a78a308559b3c9a61b697aee17a8 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Sun, 3 Mar 2019 09:32:54 +0100 Subject: [PATCH 76/92] notes about funding trail and privacy --- EIPS/eip-draft-app-keys.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index 01eac4ae4ef7c1..334050b72957e3 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -356,6 +356,13 @@ However the app can use non hardened indexes in their custom path part to be abl ### Privacy and the funding trail: +If all an application needs to do with its keys is to sign messages and it does not require funding, then this EIP allows for privacy through the use of distinct keys for each application with a simple deterministic standard compatible across wallets. + +However if these application keys require funding, there can be trail and the use of app keys would not fully solve the privacy problem there. + +Mixers or anonymous ways of funding an ethereum address (ring signatures) along with this proposal would guarantee privacy. + +Even if privacy is not solved fully without this anonymous funding method, we still need a way to easily create and restore different accounts/addresses for each application ### Alternatives for the HD derivation path From d93ca01381a581d637543f3b7ab6720a6d6c7fa5 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Sun, 3 Mar 2019 09:38:13 +0100 Subject: [PATCH 77/92] small refactor --- EIPS/eip-draft-app-keys.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index 334050b72957e3..2901b81c99fc65 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -354,17 +354,6 @@ For instance if we don't harden the application path, in case a persona public k However the app can use non hardened indexes in their custom path part to be able to benefit from guessing child public keys from parent one (for instance for counterfactual state channel interaction accross 2 peers that would like to use new keys every time they counterfactually instantiate a new sub app). -### Privacy and the funding trail: - -If all an application needs to do with its keys is to sign messages and it does not require funding, then this EIP allows for privacy through the use of distinct keys for each application with a simple deterministic standard compatible across wallets. - -However if these application keys require funding, there can be trail and the use of app keys would not fully solve the privacy problem there. - -Mixers or anonymous ways of funding an ethereum address (ring signatures) along with this proposal would guarantee privacy. - -Even if privacy is not solved fully without this anonymous funding method, we still need a way to easily create and restore different accounts/addresses for each application - - ### Alternatives for the HD derivation path Our proposed specification follows [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) and [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki): @@ -416,7 +405,7 @@ also discussed [here](https://ethereum-magicians.org/t/non-wallet-usage-of-keys- We think our approach while also being more englobing benefits from not requiring a centrally maintained registry. In our approach every application has already a potential unique identifier assigned to it. -#### Shortening the ENS node +#### Shortening the Hash node Our current approach uses identification through an ENS name converted to a hash node and sliced fully but one could potentially keep only the first 16 bytes of the node for instance and slice them similarly. This may increase the chance of app collision but we probably can reduce the lenght while retaining an injective mapping from strings to hashes. @@ -446,8 +435,9 @@ Another alternative could be to use the plain website url and get rid of ens alt ### Application's authentication -For authentication we use ENS resolution, and browsing to a given url resolved. A few comments on this: +For authentication we use DNS and ENS resolution, and browsing to a given url resolved. A few comments on this: +A few comments in case of ENS resolution: * First connection requires the wallet to connect to ethereum mainnet, but once first resolution is done we could use some metadata paramater such as `author address` for a blockchain less authentication of the application (e.g. application server signs a challenge message with the author address resolved in the ENS metadata). * The url the name resolves to through ENS can change without the user knowing and then a different application/website may be granted access to his app keys. But this means the ENS name owner address was copromised. This would be similar to using a signing challenge authentified by a known public key. If this known public key is compromised we have a similar problem. @@ -465,6 +455,17 @@ In relation to the SLIP-0013 proposal mentionned above, one could think of alter If applications don't enumerate through their hd sub-path structure, we won't be able to restore `app keys` accounts by enumeration. However it has benefits to give total freedom to applications over the way they create accounts and use their sub-path. Also, it may be safe to assume that the part of the restoring procedure will be carried by the application itself and not by the wallets. The application will need a way to remember what accounts were derived for each user. + +### Privacy and the funding trail: + +If all an application needs to do with its keys is to sign messages and it does not require funding, then this EIP allows for privacy through the use of distinct keys for each application with a simple deterministic standard compatible across wallets. + +However if these application keys require funding, there can be trail and the use of app keys would not fully solve the privacy problem there. + +Mixers or anonymous ways of funding an ethereum address (ring signatures) along with this proposal would guarantee privacy. + +Even if privacy is not solved fully without this anonymous funding method, we still need a way to easily create and restore different accounts/addresses for each application + ## Backwards Compatibility From a wallet point of view, there does not seem to be incompatibities since these are separate accounts from those that were used previously by wallets and they are supposed to be used along-side in synergy. From a59513fc14464d3010719a30ef16a495d411ddce Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Sun, 3 Mar 2019 09:40:16 +0100 Subject: [PATCH 78/92] comment about RPC / Web3 --- EIPS/eip-draft-app-keys.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-draft-app-keys.md index 2901b81c99fc65..78371a145722dd 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-draft-app-keys.md @@ -229,6 +229,8 @@ app custom path params: app_version, set_of_accounts_index, account_index We propose to introduce new RPC methods but they should be restricted and wrapped such that some parameters (e.g. domain name) are imposed by the wallet on the caller depending on the caller's authentication. +[TBD] Specify scope of RPC methods (some params should be forced to the authenticated domain value) and how to integrate them into web3 api. + ### App keys exposure: * `wallet.appkey.enable(options)` From 157689f2262bb57a3e2046fa2d67daf49541c357 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Mon, 11 Mar 2019 09:40:30 +0100 Subject: [PATCH 79/92] renamed eip file to 1775 --- EIPS/{eip-draft-app-keys.md => eip-1775.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename EIPS/{eip-draft-app-keys.md => eip-1775.md} (99%) diff --git a/EIPS/eip-draft-app-keys.md b/EIPS/eip-1775.md similarity index 99% rename from EIPS/eip-draft-app-keys.md rename to EIPS/eip-1775.md index 78371a145722dd..c8b08edd654f43 100644 --- a/EIPS/eip-draft-app-keys.md +++ b/EIPS/eip-1775.md @@ -1,5 +1,5 @@ --- -eip: +eip: 1775 title: App Keys: application specific wallet accounts author: Vincent Eli (@Bunjin), Dan Finlay (@DanFinlay) discussions-to: https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742 From 60b1a33892c0e48d1d1a1d6c725691782b8b7e36 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Mon, 11 Mar 2019 09:52:04 +0100 Subject: [PATCH 80/92] added broadcasting method --- EIPS/eip-1775.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index c8b08edd654f43..be68add6fb7100 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -279,6 +279,12 @@ tx is ethereum-js tx object * `appKey_eth_signTypedMessage(fromAddress, message)` EIP712 +### Ethereum broadcasting methods: + +* `appKey_eth_broadcastTransaction(tx, signedTx)` +tx is ethereum-js tx object + + ### Other potential methods: #### Other cryptocurrencies: @@ -385,7 +391,7 @@ We did not find a list of BIP43 purpose code so here is what we could gather: | 84 | [BIP-0084](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) | Derivation scheme for P2WPKH based accounts | | 535348 | [Ledger app ssh](https://github.com/LedgerHQ/ledger-app-ssh-agent/blob/master/getPublicKey.py#L49) | | | 80475047| [GPG/SSH Ledger](https://github.com/LedgerHQ/ledger-app-openpgp-card/blob/master/doc/developper/gpgcard3.0-addon.rst#deterministic-key-derivation)| | -| ??? | EIP Number| App Keys: application specific wallet accounts | +| 1775 | EIP 1775 | App Keys: application specific wallet accounts | ### Application's identification From 00b58cfbca009d74746ba83c03d9c01528fe8a36 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Sun, 17 Mar 2019 08:28:59 +0100 Subject: [PATCH 81/92] broadcasting method and formating --- EIPS/eip-1775.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index be68add6fb7100..76f089a49bf910 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -7,8 +7,8 @@ status: Draft type: Standards Track category: ERC created: 2019-02-20 -requires: BIP32, BIP43, EIP137, EIP165 -replaces: EIP 1581 +requires: EIP137, EIP165 +replaces: EIP1581 --- From c265304a88536cdaea1deebb9b2a0d1b54141332 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Sun, 17 Mar 2019 09:50:25 +0100 Subject: [PATCH 82/92] remove require and replace fields --- EIPS/eip-1775.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index 76f089a49bf910..885abe306189d6 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -7,8 +7,6 @@ status: Draft type: Standards Track category: ERC created: 2019-02-20 -requires: EIP137, EIP165 -replaces: EIP1581 --- From 5584afa64043a8a67af040b48bb8be2fed9fe926 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Sun, 17 Mar 2019 09:55:24 +0100 Subject: [PATCH 83/92] blank requires and replaces fields --- EIPS/eip-1775.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index 885abe306189d6..99c6ed28189518 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -7,6 +7,8 @@ status: Draft type: Standards Track category: ERC created: 2019-02-20 +requires: +replaces: --- From d333a1c9a59aa29574a18ecbffe8abd5e7a6d5f7 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Mon, 18 Mar 2019 13:20:49 +0100 Subject: [PATCH 84/92] requires and replaces fields as numbers only --- EIPS/eip-1775.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index 99c6ed28189518..500f819890359e 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -7,8 +7,8 @@ status: Draft type: Standards Track category: ERC created: 2019-02-20 -requires: -replaces: +requires: 137, 165 +replaces: 1581 --- From 6e45b26d210aa54bc340dc6b63c82363a447d268 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Mon, 18 Mar 2019 13:23:44 +0100 Subject: [PATCH 85/92] remove eip 165 --- EIPS/eip-1775.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index 500f819890359e..75361335552fbf 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -7,7 +7,7 @@ status: Draft type: Standards Track category: ERC created: 2019-02-20 -requires: 137, 165 +requires: 137 replaces: 1581 --- From 1ae40193625ddaf9f1ac1c28d661fbce5ed5feac Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Mon, 18 Mar 2019 13:37:18 +0100 Subject: [PATCH 86/92] remove : from title --- EIPS/eip-1775.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index 75361335552fbf..f999ff08af9afe 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -1,6 +1,6 @@ --- eip: 1775 -title: App Keys: application specific wallet accounts +title: App Keys, application specific wallet accounts author: Vincent Eli (@Bunjin), Dan Finlay (@DanFinlay) discussions-to: https://ethereum-magicians.org/t/eip-erc-app-keys-application-specific-wallet-accounts/2742 status: Draft From 6671145ef6561a79e4e484fb26629ad2dd8b18a9 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Tue, 19 Mar 2019 09:41:56 +0100 Subject: [PATCH 87/92] formating and a few changes after getting reviews --- EIPS/eip-1775.md | 92 ++++++++++++++++++++++++------------------------ 1 file changed, 46 insertions(+), 46 deletions(-) diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index f999ff08af9afe..9a7b5292db5da9 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -31,7 +31,7 @@ In this EIP, we provide a proposal how to uniquely identify and authenticate eac ## Motivation -Wallets developers have agreed on an HD derivation path for ethereum accounts using BIP32, BIP44, SLIP44, [ERC84](https://github.com/ethereum/EIPs/issues/84). Web3 wallets have implemented in a roughly similar way the rpc eth api. EIP 1102 introduced privacy through non automatic opt-in of a wallet account into an app increasing privacy. +Wallets developers have agreed on an HD derivation path for ethereum accounts using BIP32, BIP44, SLIP44, [(see the discussion here)](https://github.com/ethereum/EIPs/issues/84). Web3 wallets have implemented in a roughly similar way the rpc eth api. [EIP1102](https://eips.ethereum.org/EIPS/eip-1102) introduced privacy through non automatic opt-in of a wallet account into an app increasing privacy. However several limitations remain in order to allow for proper design and UX for crypto permissioned apps. @@ -58,7 +58,7 @@ Once connected to a wallet, an application can request to access a set of accoun ### Applications' HD path -Using the BIP 32 and BIP 43 standards, we propose to use the following HD path for each app keys: +Using the BIP32 and BIP43 standards, we propose to use the following HD path for each app keys: `m / [EIP Number]' / [persona path]' / [application uniquely assigned path]' / [app's custom subpath]` @@ -142,7 +142,7 @@ If the application is using a DNS name then we simply authenticate the applicati For applications using ENS, we can authenticate the application through ENS resolution. The ENS can also allow to register and resolve metadata for the application such as `url`, and other parameters. -If we use for instance this resolver profile defined in [EIP 634](https://eips.ethereum.org/EIPS/eip-634) which permits the lookup of arbitrary key-value text data, we can for instance use the key `url` to point to a website. +If we use for instance this resolver profile defined in [EIP634](https://eips.ethereum.org/EIPS/eip-634) which permits the lookup of arbitrary key-value text data, we can for instance use the key `url` to point to a website. ``` A new resolver interface is defined, consisting of the following method: @@ -383,15 +383,15 @@ We did not find a list of BIP43 purpose code so here is what we could gather: | code | Reference | Title | |------|--------------------------------------------------------------------------|-------| -| 44 | [BIP-0044](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) | Multi-Account Hierarchy for Deterministic Wallets | -| 45 | [BIP-0045](https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki) | Structure for Deterministic P2SH Multisignature Wallets| -| 48 | [SLIP-0048](https://github.com/satoshilabs/slips/issues/49) | Deterministic Key Hierarchy for Graphene-based Networks | -| 49 | [BIP-0049](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki) | Derivation scheme for P2WPKH-nested-in-P2SH based accounts | -| 80 | [BIP-0080](https://github.com/bitcoin/bips/blob/master/bip-0080.mediawiki) | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets | -| 84 | [BIP-0084](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) | Derivation scheme for P2WPKH based accounts | +| 44 | [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) | Multi-Account Hierarchy for Deterministic Wallets | +| 45 | [BIP45](https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki) | Structure for Deterministic P2SH Multisignature Wallets| +| 48 | [SLIP48](https://github.com/satoshilabs/slips/issues/49) | Deterministic Key Hierarchy for Graphene-based Networks | +| 49 | [BIP49](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki) | Derivation scheme for P2WPKH-nested-in-P2SH based accounts | +| 80 | [BIP80](https://github.com/bitcoin/bips/blob/master/bip-0080.mediawiki) | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets | +| 84 | [BIP84](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki) | Derivation scheme for P2WPKH based accounts | | 535348 | [Ledger app ssh](https://github.com/LedgerHQ/ledger-app-ssh-agent/blob/master/getPublicKey.py#L49) | | | 80475047| [GPG/SSH Ledger](https://github.com/LedgerHQ/ledger-app-openpgp-card/blob/master/doc/developper/gpgcard3.0-addon.rst#deterministic-key-derivation)| | -| 1775 | EIP 1775 | App Keys: application specific wallet accounts | +| 1775 | EIP1775 | App Keys: application specific wallet accounts | ### Application's identification @@ -407,8 +407,8 @@ And we proposed to use the ENS domain hash, or node, as the dapp_id and to use a #### Alternative: using a centraly maintened index of application uids -[EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) -also discussed [here](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) proposes a scheme that relies on a list of indexes where application should register (similar to SLIP0044 list for instance). +[EIP1581: Non-wallet usage of keys derived from BIP32 trees](https://eips.ethereum.org/EIPS/eip-1581) +also discussed [here](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) proposes a scheme that relies on a list of indexes where application should register (similar to SLIP44 list for instance). We think our approach while also being more englobing benefits from not requiring a centrally maintained registry. In our approach every application has already a potential unique identifier assigned to it. @@ -439,7 +439,7 @@ x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 where `x0` to `x7` are 20 bits. -Another alternative could be to use the plain website url and get rid of ens altogether but it would require another way to authenticate applications. See for instance [SLIP-0013](https://github.com/satoshilabs/slips/blob/master/slip-0013.md) for such a proposal. +Another alternative could be to use the plain website url and get rid of ens altogether but it would require another way to authenticate applications. See for instance [SLIP13](https://github.com/satoshilabs/slips/blob/master/slip-0013.md) for such a proposal. ### Application's authentication @@ -457,14 +457,14 @@ Other metadata resolution through ENS that can be used alongside: * `contract address`: For app keys that would be designed to interact with a given ethereum contract (for instance app keys for a given token, if one desires to do so), other metadata fields could be used such as contract addresses. * [TBD] -In relation to the SLIP-0013 proposal mentionned above, one could think of alternative specifications that would use some certificate for authentication similar to https. +In relation to the SLIP13 proposal mentionned above, one could think of alternative specifications that would use some certificate for authentication similar to https. ### An Account gap limit standard for application controlled hd sub-path? If applications don't enumerate through their hd sub-path structure, we won't be able to restore `app keys` accounts by enumeration. However it has benefits to give total freedom to applications over the way they create accounts and use their sub-path. Also, it may be safe to assume that the part of the restoring procedure will be carried by the application itself and not by the wallets. The application will need a way to remember what accounts were derived for each user. -### Privacy and the funding trail: +### Privacy and the funding trail If all an application needs to do with its keys is to sign messages and it does not require funding, then this EIP allows for privacy through the use of distinct keys for each application with a simple deterministic standard compatible across wallets. @@ -493,19 +493,19 @@ Provide some examples of accounts derived from a given mnemonic, persona, applic [WIP] [See here for an early implementation of the HD methods](https://github.com/MetaMask/KeyringController/blob/plugin-system/index.js) -## Example use cases: +## Example use cases -* signing transactions without broadcasting them: +* signing transactions without broadcasting them https://github.com/MetaMask/metamask-extension/issues/3475 -* token contract: +* token contract https://github.com/ethereum/EIPs/issues/85 * default account for dapps https://ethereum-magicians.org/t/default-accounts-for-dapps/904 * non wallet/crypto accounts -[EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) +[EIP1581: Non-wallet usage of keys derived from BIP32 trees](https://eips.ethereum.org/EIPS/eip-1581) * state channel application @@ -516,56 +516,56 @@ https://ethereum-magicians.org/t/default-accounts-for-dapps/904 ## Acknowledgements MetaMask team, Christian Lundkvist, Counterfactual team, Liam Horne, Erik Bryn, Richard Moore, Jeff Coleman. -## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -## References: +## References ### HD and mnemonics -#### BIPS: -[BIP 32 specs, Hierarchical Deterministic Wallets:](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) +#### BIPs +* [BIP32: Hierarchical Deterministic Wallets:](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) -[BIP 39 specs, Mnemonic code for generating deterministic keys:](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) +* [BIP39: Mnemonic code for generating deterministic keys:](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) -[BIP43: Purpose Field for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) +* [BIP43: Purpose Field for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki) -[BIP44: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit) +* [BIP44: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Address_gap_limit) -[SLIP44: Registered coin types for BIP-0044](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) +* [SLIP44: Registered coin types for BIP44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md) -[Is there a comprehensive list of registered BIP43 purposes?](https://bitcoin.stackexchange.com/questions/60470/is-there-a-comprehensive-list-of-registered-bip43-purposes) +* [Is there a comprehensive list of registered BIP43 purposes?](https://bitcoin.stackexchange.com/questions/60470/is-there-a-comprehensive-list-of-registered-bip43-purposes) -#### Derivation path for eth: -[ERC84](https://github.com/ethereum/EIPs/issues/84) +#### Derivation path for eth +* [Issue 84](https://github.com/ethereum/EIPs/issues/84) -[ERC85](https://github.com/ethereum/EIPs/issues/85) +* [Issue 85](https://github.com/ethereum/EIPs/issues/85) +* [EIP600 Ethereum purpose allocation for Deterministic Wallets](https://github.com/ethereum/EIPs/pull/600) -Draft EIP600 Ethereum purpose allocation for Deterministic Wallets: -https://github.com/ethereum/EIPs/blob/d5e99145d962b0b6b4c66daaabb598b870d9d0ad/eip-600.md +* [EIP601 Ethereum hierarchy for deterministic wallets](https://github.com/ethereum/EIPs/pull/601) +#### Accounts Privacy -Draft EIP601 Ethereum hierarchy for deterministic wallets: -https://github.com/ethereum/EIPs/blob/d8476ef1c861eb578bb6e9057ff52a71f3cd10e4/EIPS/eip-601.md +### ENS +* [EIP137: Ethereum Domain Name Service - specification](https://eips.ethereum.org/EIPS/eip-137) +* [EIP165: Standard Interface Detection](https://eips.ethereum.org/EIPS/eip-165) +* [EIP634: Storage of text record in ENS](https://eips.ethereum.org/EIPS/eip-634) -### ENS: -[EIP137: Ethereum Domain Name Service - specification](https://eips.ethereum.org/EIPS/eip-137) +* [ENS docs about namehash:](http://docs.ens.domains/en/latest/implementers.html#namehash) -[EIP165: Standard Interface Detection](https://eips.ethereum.org/EIPS/eip-165) +### Previous proposals and discussions related to app keys +* [Meta: we should value privacy more](https://ethereum-magicians.org/t/meta-we-should-value-privacy-more/2475) -[EIP634: Storage of text record in ENS](https://eips.ethereum.org/EIPS/eip-634) +* [EIP1102: Opt-in account exposure](https://eips.ethereum.org/EIPS/eip-1102) -[ENS docs about namehash:](http://docs.ens.domains/en/latest/implementers.html#namehash) +* [EIP1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) -### Previous proposals and discussions related to app keys -[Meta: we should value privacy more](https://ethereum-magicians.org/t/meta-we-should-value-privacy-more/2475) +* [EIP1581: discussion](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) -[EIP 1581: Non-wallet usage of keys derived from BIP-32 trees](https://eips.ethereum.org/EIPS/eip-1581) +* [SLIP13: Authentication using deterministic hierarchy](https://github.com/satoshilabs/slips/blob/master/slip-0013.md) -[EIP 1581: discussion](https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817/4) -[SLIP-0013: Authentication using deterministic hierarchy](https://github.com/satoshilabs/slips/blob/master/slip-0013.md) +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). From 14743409a854bb5dc9ff44a5b120fadfe8309b24 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Mon, 1 Apr 2019 12:03:53 +0200 Subject: [PATCH 88/92] change hd path composition to favor least indexes --- EIPS/eip-1775.md | 96 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 79 insertions(+), 17 deletions(-) diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index 9a7b5292db5da9..29b00253eb80c0 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -27,7 +27,7 @@ In a wallet, an user often holds most of her funds in her main accounts. These a We introduce here a new account type, app keys, which permits signing delegation and accounts isolation across applications for privacy and security. -In this EIP, we provide a proposal how to uniquely identify and authenticate each application, how to derive the accounts along an Hierachical Deterministic (HD) path restricted for the domain and we finally define an API for applications to derive and use these app keys. This ERC aims at finding a standard that will fit the needs of wallets and application developers while also allowing app keys to be used across wallets and yield the same accounts for the user for each application. +In this EIP, we provide a proposal on how to uniquely identify and authenticate each application, how to derive the accounts along an Hierachical Deterministic (HD) path restricted for the domain and we finally define an API for applications to derive and use these app keys. This ERC aims at finding a standard that will fit the needs of wallets and application developers while also allowing app keys to be used across wallets and yield the same accounts for the user for each application. ## Motivation @@ -60,11 +60,11 @@ Once connected to a wallet, an application can request to access a set of accoun Using the BIP32 and BIP43 standards, we propose to use the following HD path for each app keys: -`m / [EIP Number]' / [persona path]' / [application uniquely assigned path]' / [app's custom subpath]` +`m / [standardized Path Beginning]' / [persona path]' / [application uniquely assigned path]' / [app's custom subpath]` Where: -`EIP Number` is the EIP number that will be assigned to this EIP and we harden it. We use a different path than 44' since it's not bip44 compliant. At this point, I'm not sure if there is a list of BIP43 codes of standards following the `purpose` field specification of [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki). +`standardized HD Path Beginning` is based on the EIP number that will be assigned to this EIP and we harden it. We use a different path than 44' since it's not bip44 compliant. At this point, I'm not sure if there is a list of BIP43 codes of standards following the `purpose` field specification of [BIP43](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki). `persona path` allows to use applications with different and isolated personas (or in other words accounts) that are tracable by the application. They will still be fully restorable from the same mnemonic. @@ -74,6 +74,14 @@ Where: Note that we suggest that each of these indexes, except those belonging to the app's custom subpath, must be hardened to fully isolate the public keys across personas and applications. +### Standardized HD Path Beginning + +` 43' / 60' / 1775 ' ` + +or + +` BIP Number' ` + ### Personas @@ -161,13 +169,76 @@ We suggest for instance to also add an `authorEthAddress` text metadata field th Since each child index in an HD path only has 31 bits we will decompose the domain's hash as several child indexes, first as hex bytes then parsed as integers. -Let's focus first on the case where for the applications's uid we use an `ENS namehash node` of 32 bytes, 256 bits (removing the leading `0x`). +For the applications's uid we use an `ENS namehash node` of 32 bytes, 256 bits (removing the leading `0x`). e.g. `foo.bar.eth` which gives the following namehash node: `0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3` We can decompose it in several ways, here are 2 potential ways: -* The first approach favors an homogenous decomposition: +* First approach could favor having the least indexes: + +This requires to first convert the hex uid to 256 bits then decompose it as 8 * 31 bits + 8 bits + +``` +x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 +``` +where `x0` to `x7` are 31 bits and `x8` is 8 bits + +then we convert the `x_i` to uints. + +The derivation sub-path would be: +`x0'/x1'/x2'/x3'/x4'/x5'/x6'/x7'/x8'` + + +``` +E.g. + +foo.bar.eth + + +0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 + +converted to binary (256 bits) + +6033644d673b +011000000011001101100100010011010110011100111011 +47b3bea04e79 +010001111011001110111110101000000100111001111001 +bbe06d78ce76 +101110111110000001101101011110001100111001110110 +b8be2fb8704f +101110001011111000101111101110000111000001001111 +9c2a80fd139c +100111000010101010000000111111010001001110011100 +81d3 +1000000111010011 + +256 bits: +0110000000110011011001000100110101100111001110110100011110110011101111101010000001001110011110011011101111100000011011010111100011001110011101101011100010111110001011111011100001110000010011111001110000101010100000001111110100010011100111001000000111010011 + +converted to less than or equal to 31 bits indexes: + +8 * 31 bits + 1 * 8 bits + +0110000000110011011001000100110 +1011001110011101101000111101100 +1110111110101000000100111001111 +0011011101111100000011011010111 +1000110011100111011010111000101 +1111000101111101110000111000001 +0011111001110000101010100000001 +1111101000100111001110010000001 +11010011 + +and converted to uints + +806990374'/1506726380'/2010384847'/465438423'/1181988293'/2025775553'/523785473'/2098437249'/211' + + +``` + + +* Second approach favors an homogenous decomposition: Equal lenght indexes would be 16 * 16 bits or in other words 16 * 2 bytes, cleanest and favored spec: @@ -188,17 +259,8 @@ foo.bar.eth 24627'/25677'/26427'/18355'/48800'/20089'/48096'/28024'/52854'/47294'/12216'/28751'/39978'/33021'/5020'/33235' ``` -* An alternative approach could favor having the least indexes: - -``` -x = x0 || x1 || x2 || x3 || x4 || x5 || x6 || x7 || x8 -``` -where `x0` to `x7` are 30 bits and `x8` 16 bits - -The derivation sub-path would be: -`x0'/x1'/x2'/x3'/x4'/x5'/x6'/x7'/x8'` -It does not seem to really matter which method we pick between these 2 decomposition approaches, there is a trade-off between computational efficiency (having less depth) and having an homegenous decomposition. We tend to favor the approach with an homogenous decomposition. +Between these 2 decomposition approaches, there is a trade-off between computational efficiency (having less depth) and having an homegenous decomposition. We tend to favor the first approach with least indexes. ### Application customisable HD sub path @@ -216,14 +278,14 @@ Q [Should we set a limit on the persona and application customsable hd path numb ``` Dummy data: -EIP Number: 12345 +EIP Number: 1775 personaPath: 0'/712' application's name: foo.bar.eth uid: 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 app custom path params: app_version, set_of_accounts_index, account_index ``` -`m/12345'/0'/712'/6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3'/0'/0'/0` +`m/1775'/0'/712'/6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3'/0'/0'/0` ## API: From ebe0f74fe7931dab9a38509f5fe9765a6fe0db8d Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Mon, 1 Apr 2019 12:21:41 +0200 Subject: [PATCH 89/92] change hd path example --- EIPS/eip-1775.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index 29b00253eb80c0..00c715af1ad030 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -285,7 +285,7 @@ uid: 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 app custom path params: app_version, set_of_accounts_index, account_index ``` -`m/1775'/0'/712'/6033'/644d'/673b'/47b3'/bea0'/4e79'/bbe0'/6d78'/ce76'/b8be'/2fb8'/704f'/9c2a'/80fd'/139c'/81d3'/0'/0'/0` +`m/1775'/0'/712'/806990374'/1506726380'/2010384847'/465438423'/1181988293'/2025775553'/523785473'/2098437249'/211'/0'/0'/0` ## API: From f1226209f1f073571121c92c31c9dd599df22344 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Tue, 2 Apr 2019 15:21:56 +0200 Subject: [PATCH 90/92] change implementation link --- EIPS/eip-1775.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index 00c715af1ad030..7db518e726c617 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -553,7 +553,7 @@ Provide some examples of accounts derived from a given mnemonic, persona, applic ## Implementation [WIP] -[See here for an early implementation of the HD methods](https://github.com/MetaMask/KeyringController/blob/plugin-system/index.js) +[See here for an early implementation of the HD methods](https://github.com/Bunjin/appKeys) ## Example use cases From f889a34ad545f3dbba6cdefd7a8ee30421c5ff39 Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Sun, 28 Apr 2019 16:59:09 +0200 Subject: [PATCH 91/92] resolving the purpose field issues --- EIPS/eip-1775.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index 7db518e726c617..436e3a6b86ddee 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -8,7 +8,6 @@ type: Standards Track category: ERC created: 2019-02-20 requires: 137 -replaces: 1581 --- @@ -76,11 +75,13 @@ Note that we suggest that each of these indexes, except those belonging to the a ### Standardized HD Path Beginning -` 43' / 60' / 1775 ' ` +For the path header, several alternative are possible depending on what the cryptocommunities agree upon. + +The least contentious is the following one (as suggested [here in the BIP repository](https://github.com/bitcoin/bips/pull/523)): -or +` 43' / 60' / 1775 ' ` -` BIP Number' ` +However, there may be benefits to use only one depth instead of 3. We could use the `EIP Number'` (ie. 1775) or a ` BIP Number'` if we attain some cross crypto agreement that would avoid collision. ### Personas @@ -285,7 +286,7 @@ uid: 0x6033644d673b47b3bea04e79bbe06d78ce76b8be2fb8704f9c2a80fd139c81d3 app custom path params: app_version, set_of_accounts_index, account_index ``` -`m/1775'/0'/712'/806990374'/1506726380'/2010384847'/465438423'/1181988293'/2025775553'/523785473'/2098437249'/211'/0'/0'/0` +`m/43'/60'/1775'/0'/712'/806990374'/1506726380'/2010384847'/465438423'/1181988293'/2025775553'/523785473'/2098437249'/211'/0'/0'/0` ## API: @@ -438,7 +439,7 @@ One could think of alternative specifications deviating from BIP43 or even BIP32 ### HD derivation path purpose field -If we agree on not using BIP44 but following BIP32 and BIP43, we need to settle on a purpose field. We proposed to used the number that will be assigned to this EIP and we should research +If we agree on not using BIP44 but following BIP32 and BIP43, we need to settle on a purpose field. We can either use the 3 depth path proposed here (https://github.com/bitcoin/bips/pull/523) or try to rech agreement on a one depth path. A one depth path should however avoid collision. This can be achieves by either submitting a BIP or by maintening a list of BIP 43 purpose fields. We did not find a list of BIP43 purpose code so here is what we could gather: From f4fb98001d6188d23180ea970d01ab8edd3001db Mon Sep 17 00:00:00 2001 From: WhySoS3rious Date: Sun, 28 Apr 2019 17:04:11 +0200 Subject: [PATCH 92/92] EIP links --- EIPS/eip-1775.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-1775.md b/EIPS/eip-1775.md index 436e3a6b86ddee..1c623887562991 100644 --- a/EIPS/eip-1775.md +++ b/EIPS/eip-1775.md @@ -601,10 +601,10 @@ MetaMask team, Christian Lundkvist, Counterfactual team, Liam Horne, Erik Bryn, * [Issue 85](https://github.com/ethereum/EIPs/issues/85) -* [EIP600 Ethereum purpose allocation for Deterministic Wallets](https://github.com/ethereum/EIPs/pull/600) +* [EIP600 Ethereum purpose allocation for Deterministic Wallets](https://eips.ethereum.org/EIPS/eip-600) -* [EIP601 Ethereum hierarchy for deterministic wallets](https://github.com/ethereum/EIPs/pull/601) +* [EIP601 Ethereum hierarchy for deterministic wallets](https://eips.ethereum.org/EIPS/eip-601) #### Accounts Privacy