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.
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
Add EIP: AA Account Metadata For Authentication #6662
Merged
Merged
Changes from all commits
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
9f0bc12
add eip-6602.md
dongshu2013 187dcc6
add discussion link
dongshu2013 ce5597a
change status to draft
dongshu2013 99b3671
fix lint
dongshu2013 847fa6e
fix lint
dongshu2013 42f2b73
fix lint
dongshu2013 0417e92
better wording
dongshu2013 4a53a24
update author and fix lint
dongshu2013 32d5c68
fix lint
dongshu2013 2c14a1f
support mult-sig and multi-relay
dongshu2013 940c510
address comments
dongshu2013 5f10adf
address comments
dongshu2013 File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,112 @@ | ||
--- | ||
eip: 6662 | ||
title: AA Account Metadata For Authentication | ||
description: An ERC-4337 extension to define a new authentication model | ||
author: Shu Dong (@dongshu2013), Zihao Chen (@zihaoccc), Peter Chen (@pette1999) | ||
discussions-to: https://ethereum-magicians.org/t/eip-6662-account-metadata-for-aa-account-authentication/13232 | ||
status: Draft | ||
type: Standards Track | ||
category: ERC | ||
created: 2023-03-09 | ||
requires: 4337, 4804 | ||
--- | ||
|
||
## Abstract | ||
|
||
This ERC proposes a new **IAccountMetadata** interface as an extension for [ERC-4337](./eip-4337.md) to store authentication data on-chain to support a more user-friendly authentication model. | ||
|
||
## Motivation | ||
|
||
In this proposal, we propose a new **IAccountMetadata** interface as an extension for ERC-4337 **IAccount** interface. With this new interface, users can store authentication data on-chain through one-time publishing, allowing dApps to proactively fetch it from the chain to support a more flexible and user-friendly authentication model. This will serve as an alternative to the current authentication model where users need to log in with a wallet every time and push account-related information to dApps by connecting the wallet in advance. | ||
|
||
## Specification | ||
|
||
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. | ||
|
||
### Authentication Flow | ||
|
||
![Authentication Flow](../assets/eip-6662/auth-flow.png) | ||
|
||
In the new authentication workflow, users use AA compatible smart contract accounts as their wallet addresses. **Authenticator** could be anything but holding the private key to sign users' operations. For example, it can be an offline authenticator mobile app or an online cloud service. **Relay** is an online service responsible for forwarding requests from dApps to the Authenticator. If the authenticator is online, it can play the role of Relay service and listen to dApps directly. | ||
|
||
### Interface | ||
|
||
To support the new authentication workflow, this ERC proposes a new **IAccountMetadata** interface as an extension of **IAccount** interface defined by ERC-4337. | ||
|
||
``` | ||
interface IAccountMetadata { | ||
struct AuthenticatorInfo { | ||
// a list of service URIs to relay message from dApps to authenticators | ||
string[] relayURI; | ||
// a JSON string or URI pointing to a JSON file describing the | ||
// schema of AuthenticationRequest. The URI should follow ERC-4804 | ||
// if the schema file is stored on-chain | ||
string schema; | ||
} | ||
|
||
function getAuthenticationInfo() external view returns(AuthenticatorInfo[] memory); | ||
} | ||
``` | ||
|
||
The relay endpoint should accept an AuthenticationRequest object as input. The format of the AuthenticationRequest object is defined by the schema field at AuthenticationInfo. | ||
|
||
Following is a schema example which supports end to end encryption, where we pack all encrypted fields into an encryptedData field. Here we only list basic fields but there may be more fields per schema definition. A special symbol, such as "$e2ee", could be used to indicate the field is encrypted. | ||
|
||
```json | ||
{ | ||
"title": "AuthenticationRequest", | ||
"type": "object", | ||
"properties": { | ||
"entrypoint": { | ||
"type": "string", | ||
"description": "the entrypoint contract address", | ||
}, | ||
"chainId": { | ||
"type": "string", | ||
"description": "the chain id represented as hex string, e.g. 0x5 for goerli testnet", | ||
}, | ||
"userOp": { | ||
"type": "object", | ||
"description": "UserOp struct defined by ERC-4337 without signature", | ||
}, | ||
"encryptedData": { | ||
"type": "string", | ||
"description": "contains all encrypted fields" | ||
}, | ||
} | ||
} | ||
``` | ||
|
||
## Rationale | ||
|
||
To enable the new authentication workflow we described above, dApp needs to know two things: | ||
|
||
1. **Where is the authenticator?** This is solved by the **relayURI** field in struct **AuthenticationInfo**. Users can publish the uri as the account metadata which will be pulled by dApp to do service discovery. | ||
|
||
2. **What’s the format of AuthenticationRequest?** This is solved by the **schema** field in struct **AuthenticationInfo**. The schema defines the structure of the AuthenticationRequest object which is consumed by the authenticator. It can also be used to define extra fields for the relay service to enable flexible access control. | ||
|
||
### Relay Service Selection | ||
|
||
Each authenticator can provide a list of relay services. dApp should pull through the list of relay services in order to find the first workable one. All relay services under each authenticator must follow the same schema. | ||
|
||
### Signature Aggregation | ||
|
||
Multisig authentication could be enabled if multiple AuthenticatorInfos are provided under each smart contract account. Each authenticator can sign and submit signed user operations to bundler independently. These signatures will be aggregated by the Aggregator defined in ERC-4337. | ||
|
||
### Future Extension | ||
|
||
The **IAccountMetadata** interface could be extended per different requirements. For example, a new alias or avatar field could be defined for profile displaying. | ||
|
||
## Backwards Compatibility | ||
|
||
The new interface is fully backward compatible with ERC-4337. | ||
|
||
## Security Considerations | ||
|
||
### End to End Encryption | ||
|
||
To protect the user’s privacy and prevent front-running attacks, it's better to keep the data from dApps to authenticators encrypted during transmission. This could be done by adopting the JWE (JSON Web Encryption, RFC-7516) method. Before sending out AuthenticationRequest, a symmetric CEK(Content Encryption Key) is generated to encrypt fields with end to end encryption enabled, then the CEK is encrypted with the signer's public key. dApp will pack the request into a JWE object and send it to the authenticator through the relay service. Relay service has no access to the end to end encrypted data since only the authenticator has the key to decrypt the CEK. | ||
|
||
## Copyright | ||
|
||
Copyright and related rights waived via [CC0](../LICENSE.md). |
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See https://eips.ethereum.org/EIPS/eip-2294 chainId boundary is underfined as of today. If it ends up being defined as uint256 it will be a string and this JSON schema shall specify how chainId is represented, e.g. 0x...
If it ends up being bounded at uint32 it can be represented as number, which is what EIP-695 is doing https://eips.ethereum.org/EIPS/eip-695
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated the description to specify the "0x" format