From 62d4fc8cd0de84556a9ba7aa28f006fb956ee4de Mon Sep 17 00:00:00 2001 From: Joachim Date: Wed, 25 Sep 2024 15:05:43 +0800 Subject: [PATCH 1/2] Create eip-7xxx.md --- ERCS/eip-7xxx.md | 388 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 388 insertions(+) create mode 100644 ERCS/eip-7xxx.md diff --git a/ERCS/eip-7xxx.md b/ERCS/eip-7xxx.md new file mode 100644 index 0000000000..3e3d32640b --- /dev/null +++ b/ERCS/eip-7xxx.md @@ -0,0 +1,388 @@ +--- +eip: 7xxx +title: ONCHAINID - An Onchain Identity System +description: Formalizing ONCHAINID, a self-sovereign identity system on Ethereum. +author: Joachim Lebrun (@Joachim-Lebrun), Kevin Thizy (@Nakasar), Matthew Pinnock (@AureliusEth) +discussions-to: //TBD +status: Draft +type: Standards Track +category: ERC +created: 2024-xx-xx +--- + +## Abstract + +ONCHAINID is a blockchain-based identity system that combines the functionalities of a key manager and a claim holder. +The key manager holds keys to sign actions and execute instructions, while the claim holder manages claims that can be +attested by third parties or self-attested. The identity contract defined by ONCHAINID `IIdentity` integrates these +functionalities, providing a comprehensive solution for individuals and organizations to enforce compliance and +access digital assets or protocols with permission mechanisms. + +## Motivation + +The motivation behind ONCHAINID is to address the inadequacies of the existing Ethereum protocol in managing complex +account structures and verifying onchain claims about an identity. The current protocol lacks a standardized way for +DApps and smart contracts to check the claims about an identity, and there is no formalized way to manage these claims +onchain. Moreover, the protocol does not provide a comprehensive solution for managing keys associated with an account. + +ONCHAINID aims to provide a self-sovereign identity system on the blockchain that allows users to create and manage +their own identities. This identification solution enables compliance and identity verifications within the +pseudonymous framework of public blockchain networks. It integrates the functionalities of a key manager and a +claim holder, as proposed in the Key Manager and Claim Holder proposals by Fabian Vogelsteller. However, these +proposals were never formalized as EIPs, remaining at the issue state. This EIP aims to formalize these proposals and +integrate them into the ONCHAINID system. + +## Specification + +### Key Management +Keys are cryptographic public keys, or contract addresses that have permission to operate the identity or to interact with services in its behalf. + +Those permissions are represented by the purposes they key is associated with. The list of purposes is an array of `uint256` and the following purposes are introduced: + +- `1`: MANAGEMENT keys, which can manage the identity (considered an Owner of the identity, a MANAGEMENT key have all permissions). +- `2`: EXECUTION keys, which can call the approve method on the identity to execute transaction sent by the identity to other contracts. +- `3`: CLAIM keys, which can add, remove and update claims on the ONCHAINID. + +The structure should be as follows: + +- `key`: A public key owned by this identity + - `purpose`: `uint256[]` Array of the key types, like 1 = MANAGEMENT, 2 = EXECUTION, 3 = CLAIM + - `keyType`: The type of key used, which would be a `uint256` for different key types. e.g. 1 = ECDSA, 2 = RSA, etc. + - `key`: `bytes32` The public key. // for non-hex and long keys, its the Keccak256 hash of the key + + ```solidity + struct Key { + uint256[] purposes; + uint256 keyType; + bytes32 key; + } + ``` +#### getKey +Returns the full key data, if present in the identity. + +```solidity +function getKey(bytes32 _key) constant returns(uint256[] purposes, uint256 keyType, bytes32 key); +``` + +#### keyHasPurpose +Returns `TRUE` if a key is present and has the given purpose. If the key is not present it returns `FALSE`. + +```solidity +function keyHasPurpose(bytes32 _key, uint256 purpose) constant returns(bool exists); +``` + +#### getKeysByPurpose +Returns an array of public key `bytes32` held by this identity. + +```solidity +function getKeysByPurpose(uint256 _purpose) constant returns(bytes32[] keys); +``` + +#### addKey +Adds a `_key` to the identity. The `_purpose` specifies the purpose of the key. + +**MUST** only be done by keys of purpose `1`, or the identity itself. If it's the identity itself, the approval process will determine its approval. + +**Triggers Event**: `KeyAdded` + +```solidity +function addKey(bytes32 _key, uint256 _purpose, uint256 _keyType) returns (bool success); +``` + +#### removeKey +Removes `_key` from the identity. + +**MUST** only be done by keys of purpose `1`, or the identity itself. If it's the identity itself, the approval process will determine its approval. + +**Triggers Event**: `KeyRemoved` + +```solidity +function removeKey(bytes32 _key, uint256 _purpose) returns (bool success); +``` + +### Claim Management + +#### Claim storage + +An identity contract can hold claims. Claims are structured data that bear information, being by the content of +the `data` property or by its sole existence. + +A claim is structured as follow: +```solidity +struct claim { + uint256 topic; + uint256 scheme; + address issuer; + bytes signature; + bytes data; + string uri; +} +``` + +| Field | Description | +|-------------|-------------------------------------------------------------------------------------------------------------------------------------------| +| `topic` | An integer representing the subject of the claim. | +| `scheme` | An integer specifying the format of the claim data property. | +| `issuer` | The contract address of the Claim Issuer that issued the claim (for self-attested claims, this will be the identity contract address). | +| `signature` | The signature of the claim by the claim issuer (signature method is not standardized). | +| `data` | Data property of the claim (digest of the data is included in the signature). The content is formatted according to the specified scheme. | +| `uri` | Claims may reference an external storage (IPFS, API, etc) for additional content. | + +> This specification does not cover the algorithm and methods for claim signature. Each claim issuer may use different keys format. + +##### Adding a claim + +To store or update a claim on the Identity, the method `addClaim()` is called. + +This method MUST emit a `ClaimAdded` event when a claim is stored, and `ClaimChanged` when a claim is updated. + +```solidity +/** + * @dev Emitted when a claim was added. + * + * Specification: MUST be triggered when a claim was successfully added. + */ +event ClaimAdded( + bytes32 indexed claimId, + uint256 indexed topic, + uint256 scheme, + address indexed issuer, + bytes signature, + bytes data, + string uri +); +``` + +```solidity +/** + * @dev Emitted when a claim was changed. + * + * Specification: MUST be triggered when addClaim was successfully called on an existing claimId. + */ +event ClaimChanged( + bytes32 indexed claimId, + uint256 indexed topic, + uint256 scheme, + address indexed issuer, + bytes signature, + bytes data, + string uri +); +``` + +An Identity must store only one claim of a given topic for a claim issuer. Attempting to add another claim with the +same pair of topic and issuer MUST result in replacing the existing claim with the new one (and emits the +`ClaimChanged` instead of the `ClaimAdded`). + +##### Removing a claim + +To remove a claim from the Identity, the method `removeClaim()` is called. + +The method MUST emit a `ClaimRemoved` event. + +```solidity +/** + * @dev Emitted when a claim was removed. + * + * Specification: MUST be triggered when removeClaim was successfully called. + */ +event ClaimRemoved( + bytes32 indexed claimId, + uint256 indexed topic, + uint256 scheme, + address indexed issuer, + bytes signature, + bytes data, + string uri +); +``` + +##### Accessing claims + +Identity contracts MUST expose methods to retrieve claims. + +To retrieve a claim by its ID, the method `getClaim()` is called. +The ID of the claim is computed with `keccak256(abi.encode(issuer, topic))`. One issuer can have at most one active +claim of a given topic for an identity. +This method MUST return the complete claim structure: + +```solidity +/** + * @dev Get a claim by its ID. + * + * Claim IDs are generated using `keccak256(abi.encode(address issuer_address, uint256 topic))`. + */ +function getClaim(bytes32 _claimId) +external view returns( + uint256 topic, + uint256 scheme, + address issuer, + bytes memory signature, + bytes memory data, + string memory uri +); +``` + +For convenience, the method `getClaimIdsByTopic()` is introduced as a mandatory implementation. +This method MUST return an array of claim IDs for a given topic. + +```solidity +/** + * @dev Returns an array of claim IDs by topic. + */ +function getClaimIdsByTopic(uint256 _topic) external view returns(bytes32[] memory claimIds); +``` + +> An identity MAY not send all claims of a given topics but only a subset of them. An implementation COULD let the +> identity owner select only a few claims to be presented each time. + +#### Self-attested claims + +Claims are usually issued by third parties about an identity, but some claims are intended to be created by the +identity owner themselves. These claims are called self-attested claims. + +Self-attested claims addition, updates and removals MUST trigger the `ClaimAdded`, `ClaimChanged` and `ClaimRemoved` +events, and they SHOULD be managed by the same methods `addClaim` and `removeClaim`. + +Self-attested claims uses the same validity check regarding signatures (algorithms are left to the appreciation of +implementers). Specifications does not include a revoke mechanism, however the Identity contract exposes +a `isClaimValid` method that MUST verify the claim signature and return true if it is valid, or false otherwise. + +The `isClaimValid` method MAY implement a revocation behavior based on timestamp, revocation lists or any other +method deemed necessary by the implementer, returning true or false depending on the claim validity status. + +```solidity +/** + * @dev Checks if a claim is valid. + * @param identity the identity contract related to the claim. + * @param claimTopic the claim topic of the claim + * @param sig the signature of the claim + * @param data the data field of the claim + * @return claimValid true if the claim is valid, false otherwise + */ +function isClaimValid( + address identity, + uint256 claimTopic, + bytes calldata sig, + bytes calldata data) +external view returns (bool); +``` + +### Identity usage + +Apart from keys and claims management, the Identity contract specified in ONCHAINID allows for execution requests and +approvals. A contract (or a signer) may create a new execution request by calling the `execute()` method. +Execute may be native transfers of value from the identity contract balance to another address, or execution of methods +on other contracts. When an execution request is created, it awaits approval from authorized key. Upon validation, the +operation is performed. + +This behavior allows Identity to hold tokens or to act as signers or simplified "smart wallets". The complexity and +details of the approval process are left to the discretion of implementers. + +#### execute +Passes an execution instruction to the Key Manager. +**SHOULD** require approve to be called with one or more keys of purpose `1` or `2` to approve this execution. + +Execute **COULD** be used as the only accessor for `addKey`, `removeKey` and `addClaim` and `removeClaim`. + +Returns `executionId`: SHOULD be sent to the `approve ` function, to approve or reject this execution. + +**Triggers Event**: `ExecutionRequested` + +**Triggers on direct execution Event**: `Executed` + +```solidity +function execute(address _to, uint256 _value, bytes _data) returns (uint256 executionId); +``` + +#### approve +Approves an execution or claim addition. +This **SHOULD** require the approval of key purpose `1`, if the `_to` of the execution is the identity contract itself, to successfully approve an execution. +And **COULD** require the approval of key purpose `2`, if the `_to` of the execution is another contract, to successfully approve an execution. + +**Triggers Event**: `Approved` + +**Triggers on successful execution Event**: `Executed` + +```solidity +function approve(uint256 _id, bool _approve) returns (bool success); +``` + +### Events + +Events are very important because most Identity management application will need these to display appropriate +information about the identity state. + +#### `KeyAdded` + +MUST be triggered when `addKey` was successfully called. + +```solidity +event KeyAdded(bytes32 indexed key, uint256 indexed purpose, uint256 indexed keyType); +``` + +#### `KeyRemoved` + +MUST be triggered when `removeKey` was successfully called. + +```solidity +event KeyRemoved(bytes32 indexed key, uint256 indexed purpose, uint256 indexed keyType); +``` + +#### `ExecutionRequested` + +This events means an execution request was created and is awaiting approval (note: if the execution was immediately +approved and then performed, the ExecutionRequest would be followed by an Executed event in the same transaction). + +MUST be triggered when `execute` was successfully called. + +```solidity +event ExecutionRequested(uint256 indexed executionId, address indexed to, uint256 indexed value, bytes data); +``` + +#### `Executed` + +MUST be triggered when `approve` was called and the execution was successfully approved. + +```solidity +event Executed(uint256 indexed executionId, address indexed to, uint256 indexed value, bytes data); +``` + +#### `Approved` + +MUST be triggered when `approve` was successfully called. + +```solidity +event Approved(uint256 indexed executionId, bool approved); +``` + +## Rationale + + + +## Backwards Compatibility + +There are no known standard using the previous KeyHolder and ClaimHolder proposals. Most methods used are inspired by +specifications of KeyHolder and ClaimHolder introduces by Fabian Vogelsteller (@frozeman), hence application leveraging +claims and keys functionalities should still be compatible. + +## Security Considerations + +### Privacy + +Because claims may be related to personal information, developers and especially claim issuers are expected to consider +the privacy implications of the claims they issue. Especially: +- The content of the claim `data` property are to be considered public and should never contain sensitive information, +even encrypted. For such information, it is recommended to use an integrity hash of information stored offchain +combined with a random string and to include the hash in the claim data. Digest algorithms choice is left to claim +issuers and they may differ from one to another. +- The existence of a claim with a given topic could reveal information about the identity. Claim issuers should not +issue claims too specific and avoid claims when not necessary. + +When using an Identity, identity owners (and services managing identities) should keep in mind that: +- identity information should as much as possible be kept off-chain. On-chain claims should only be added to the +identity when they are necessary (usually to interact with permission smart contracts). + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From 4ad0c9cfb8cd76e44618c3e4ce1c84543a018997 Mon Sep 17 00:00:00 2001 From: Joachim Date: Thu, 26 Sep 2024 14:40:41 +0800 Subject: [PATCH 2/2] Update and rename eip-7xxx.md to erc-7xxx.md --- ERCS/{eip-7xxx.md => erc-7xxx.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename ERCS/{eip-7xxx.md => erc-7xxx.md} (99%) diff --git a/ERCS/eip-7xxx.md b/ERCS/erc-7xxx.md similarity index 99% rename from ERCS/eip-7xxx.md rename to ERCS/erc-7xxx.md index 3e3d32640b..1542830f2f 100644 --- a/ERCS/eip-7xxx.md +++ b/ERCS/erc-7xxx.md @@ -2,7 +2,7 @@ eip: 7xxx title: ONCHAINID - An Onchain Identity System description: Formalizing ONCHAINID, a self-sovereign identity system on Ethereum. -author: Joachim Lebrun (@Joachim-Lebrun), Kevin Thizy (@Nakasar), Matthew Pinnock (@AureliusEth) +author: Joachim Lebrun (@Joachim-Lebrun), Kevin Thizy (@Nakasar), Matthew Pinnock (@AureliusEth), Luc Falempin (@lfalempin), Tony Malghem (@TonyMalghem) discussions-to: //TBD status: Draft type: Standards Track