Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update ERC-4527: Move to Review #694

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Update ERC-4527: Move to Review #694

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
3e91a72
add new fields on the sign request and change status
aaronisme Oct 31, 2024
e63af65
Update erc-4527.md
SamWilsn Dec 9, 2024
5d01f97
Merge branch 'ethereum:master' into master
aaronisme Dec 12, 2024
4a0eba0
fix the review comments
aaronisme Dec 12, 2024
50caa50
Update erc-4527.md
SamWilsn Dec 23, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 20 additions & 27 deletions ERCS/erc-4527.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ title: QR Code transmission protocol for wallets
description: QR Code data transmission protocol between wallets and offline signers.
author: Aaron Chen (@aaronisme), Sora Lee (@soralit), ligi (@ligi), Dan Miller (@danjm), AndreasGassmann (@andreasgassmann), xardass (@xardass), Lixin Liu (@BitcoinLixin)
discussions-to: https://ethereum-magicians.org/t/add-qr-code-scanning-between-software-wallet-cold-signer-hardware-wallet/6568
status: Stagnant
status: Review
type: Standards Track
category: ERC
created: 2021-12-07
Expand Down Expand Up @@ -43,20 +43,20 @@ In order to work with offline signers, the watch-only wallet should follow the f

### Data Transmission Protocol

Since a single QR Code can only contain a limited amount of data, animated QR Codes should be utilized for data transmission. The `BlockchainCommons` have published a series of data transmission protocol called Uniform Resources (UR). It provides a basic method to encode data into animated QR Codes. This EIP will use UR and extend its current definition.
Since a single QR Code can only contain a limited amount of data, animated QR Codes should be utilized for data transmission. The BlockchainCommons have published a series of data transmission protocol called Uniform Resources (UR). It provides a basic method to encode data into animated QR Codes. This EIP will use UR and extend its current definition.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph is still an external link (even though it lacks an explicit hyperlink.) ERC-4527 isn't implementable without also reading the Uniform Resources standard.

We require that such information fulfill any one of the following:

  • It is included in the EIP or its assets directory (license permitting);
  • It is hosted on a source permitted in EIP-1 (eg. IETF or W3C); or
  • It has been assigned a DOI.

We have these requirements in place to ensure that external information doesn't disappear or change once the EIP is finalized. BlockchainCommons hasn't been approved as an external origin.

I'll draft up a pull request copying the relevant standards here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, as it turns out, these are deeply interlinked and would be a pain in the ass to rehost here. I'll figure something else out.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @SamWilsn anything to do for moving the PR forward?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing on your end. I'll make sure this moves along on mine.


`Concise Binary Object Representation(CBOR)` will be used for binary data encoding. `Concise Data Definition Language(CDDL)` will be used for expressing the CBOR.
Concise Binary Object Representation (CBOR) (see [RFC 8949](https://www.rfc-editor.org/rfc/rfc8949.html)) will be used for binary data encoding. Concise Data Definition Language (CDDL) (see [RFC 8610](https://www.rfc-editor.org/rfc/rfc8610)) will be used for expressing the CBOR.

### Setting up the watch-only wallet with the offline signer

In order to allow a watch-only wallet to collect information from the Ethereum blockchain, the offline signer would need to provide the public keys to the watch-only wallet in which the wallet will use them to query the necessary information from the Ethereum blockchain.

In such a case, offline signers should provide the extended public keys and derivation path. The UR Type called `crypto-hdkey` will be used to encode this data and the derivation path will be encoded as `crypto-keypath`.
In such a case, offline signers should provide the extended public keys and derivation path. The UR Type called **crypto-hdkey** will be used to encode this data and the derivation path will be encoded as **crypto-keypath**.


#### CDDL for Key Path

The `crypto-keypath` will be used to specify the key path.The following specification is written in Concise Data Definition Language(CDDL) for `crypto-key-path`
The **crypto-keypath** will be used to specify the key path.The following specification is written in Concise Data Definition Language (CDDL) for **crypto-key-path**

```
; Metadata for the derivation path of a key.
Expand Down Expand Up @@ -92,9 +92,9 @@ The `crypto-keypath` will be used to specify the key path.The following specific

#### CDDL for Extended Public Keys

Since the purpose is to transfer public key data, the definition of `crypto-hdkey` will be kept only for public key usage purposes.
Since the purpose is to transfer public key data, the definition of **crypto-hdkey** will be kept only for public key usage purposes.

The following specification is written in Concise Data Definition Language `CDDL` and includes the crypto-keypath spec above.
The following specification is written in Concise Data Definition Language (CDDL) and includes the crypto-keypath spec above.

```
; An hd-key must be a derived key.
Expand Down Expand Up @@ -127,16 +127,15 @@ chain-code-bytes = bytes .size 32

If the chain-code is provided, then it can be used to derive child keys but if it isn’t provided, it is simply a solo key and the origin can be provided to indicate the derivation key path.

If the signer would like to provide multiple public keys instead of the extended public key for any reason, the signer can use `crypto-account` for that.
If the signer would like to provide multiple public keys instead of the extended public key for any reason, the signer can use **crypto-account** for that.

### Sending the unsigned data from the watch-only wallet to the offline signer

To send the unsigned data from a watch-only wallet to an offline signer, the new UR type `eth-sign-request` will be introduced to encode the signing request.
To send the unsigned data from a watch-only wallet to an offline signer, the new UR type **eth-sign-request** will be introduced to encode the signing request.

#### CDDL for Eth Sign Request.

The following specification is written in Concise Data Definition Language `CDDL`.
UUIDs in this specification notated UUID are CBOR binary strings tagged with #6.37, per the IANA `CBOR Tags Registry`.
The following specification is written in Concise Data Definition Language (CDDL).

```
; Metadata for the signing request for Ethereum.
Expand Down Expand Up @@ -166,6 +165,7 @@ eth-sign-request = (
?request-id: uuid, ; the uuid for this signing request
?address: eth-address-bytes, ;verification purpose for the address of the signing key
?origin: text ;the origin of this sign request, like wallet name
?addons: text; the add-ons data can be used by signer to decode the signing request
)
request-id = 1
sign-data = 2
Expand All @@ -174,17 +174,18 @@ chain-id = 4 ;it will be the chain id of ethereum related blockchain
derivation-path = 5
address = 6
origin = 7
addons = 8
eth-address-bytes = bytes .size 20
sign-data-bytes = bytes ; for unsigned transactions it will be the rlp encoding for unsigned transaction data and ERC 712 typed data it will be the bytes of json string.
sign-data-bytes = bytes ; for unsigned transactions it will be the rlp encoding for unsigned transaction data and ERC-712 typed data it will be the bytes of json string.
```

### The signature provided by offline signers to watch-only wallets

After the data is signed, the offline signer should send the signature back to the watch-only wallet. The new UR type called `eth-signature` is introduced here to encode this data.
After the data is signed, the offline signer should send the signature back to the watch-only wallet. The new UR type called **eth-signature** is introduced here to encode this data.

#### CDDL for Eth Signature.

The following specification is written in Concise Data Definition Language `CDDL`.
The following specification is written in Concise Data Definition Language (CDDL).

```
eth-signature = (
Expand All @@ -202,37 +203,29 @@ eth-signature-bytes = bytes .size 65; the signature of the signing request (r,s,

## Rationale

This EIP uses some existing UR types like `crypto-keypath` and `crypto-hdkey` and also introduces some new UR types like `eth-sign-request` and `eth-signature`. Here are the reasons we choose UR for the QR Code data transmission protocol:
This EIP uses some existing UR types like **crypto-keypath** and **crypto-hdkey** and also introduces some new UR types like **eth-sign-request** and **eth-signature**. Here are the reasons we choose UR for the QR Code data transmission protocol:

### UR provides a solid foundation for QR Code data transmission

- Uses the alphanumeric QR code mode for efficiency.
- Includes a CRC32 checksum of the entire message in each part to tie the different parts of the QR code together and ensure the transmitted message has been reconstructed.
- uses `Fountain Code` for the arbitrary amount of data which can be both a minimal, finite sequence of parts and an indefinite sequence of parts. The Fountain Code can ultimately help the receiver to make the data extraction easier.
- uses "Fountain Code" for the arbitrary amount of data which can be both a minimal, finite sequence of parts and an indefinite sequence of parts. The Fountain Code can ultimately help the receiver to make the data extraction easier.

### UR provides existing helpful types and scalability for new usages

Currently, UR has provided some existing types like `crypto-keypath` and `crypto-hdkey` so it is quite easy to add a new type and definitions for new usages.
Currently, UR has provided some existing types like **crypto-keypath** and **crypto-hdkey** so it is quite easy to add a new type and definitions for new usages.

### UR has an active air-gapped wallet community.

Currently, the UR has an active `airgapped wallet community` which continues to improve the UR forward.
Currently, the UR has an active **airgapped wallet community** which continues to improve the UR forward.

## Backwards Compatibility

Currently, there is no existing protocol to define data transmissions via QR Codes so there are no backward compatibility issues that needs to be addressed now.

## Test Cases

The test cases can be found on the `ur-registry-eth` package released by the Keystone team.

## Reference Implementation

The reference implementation can be found on the `ur-registry-eth` package released by the Keystone team.

## Security Considerations

The offline signer should decode all the data from `eth-sign-request` and show them to the user for confirmation prior to signing. It is recommended to provide an address field in the `eth-sign-request`. If provided, the offline signer should verify the address being the same one as the address associated with the signing key.
The offline signer should decode all the data from **eth-sign-request** and show them to the user for confirmation prior to signing. It is recommended to provide an address field in the **eth-sign-request**. If provided, the offline signer should verify the address being the same one as the address associated with the signing key.

## Copyright

Expand Down
Loading