From 2f4f0d54f496281aaa6aa9a854812cb79d26cbd2 Mon Sep 17 00:00:00 2001 From: joachimlebrun Date: Tue, 13 Jun 2023 02:30:23 +0700 Subject: [PATCH 1/6] :sparkles: (eip OID) start EIP --- EIPS/eip-7xxx.md | 176 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 176 insertions(+) create mode 100644 EIPS/eip-7xxx.md diff --git a/EIPS/eip-7xxx.md b/EIPS/eip-7xxx.md new file mode 100644 index 00000000000000..7f957d47526b94 --- /dev/null +++ b/EIPS/eip-7xxx.md @@ -0,0 +1,176 @@ +--- +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), Fabian Vogelsteller (@frozeman), Tony Malghem (@TonyMalghem), Luc Falempin(@lfalempin) +discussions-to: //TBD +status: Draft +type: Standards Track +category: ERC +created: 2023-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, known as IIdentity, integrates these functionalities, providing a comprehensive solution for individuals and organizations to enforce compliance and access digital assets. + +## 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 associated with this identity. +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. Initially, we propose three purposes: + +- `1`: MANAGEMENT keys, which can manage the identity +- `2`: EXECUTION keys, which perform executions in this identity's name (signing, logins, transactions, etc.) +- `3`: CLAIM keys, which can add, remove and update claims on the ONCHAINID + +**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); +``` + +### Identity usage + +#### 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 `replaceKey` 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` + +**Triggers on successful claim addition Event**: `ClaimAdded` + +```solidity +function approve(uint256 _id, bool _approve) returns (bool success); +``` + +### Events + +#### `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` +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); +``` + +#### `KeysRequiredChanged` +MUST be triggered when `changeKeysRequired` was successfully called. + +```solidity +event KeysRequiredChanged(uint256 purpose, uint256 number); +``` + +## Rationale + + +## Backwards Compatibility + + +## Security Considerations + + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From 3c787da87b4369b9b3fa6726a8816fa335b6936f Mon Sep 17 00:00:00 2001 From: Nakasar Date: Fri, 18 Aug 2023 10:23:59 +0200 Subject: [PATCH 2/6] Update eip-7xxx.md --- EIPS/eip-7xxx.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-7xxx.md b/EIPS/eip-7xxx.md index 7f957d47526b94..7639b4534e9032 100644 --- a/EIPS/eip-7xxx.md +++ b/EIPS/eip-7xxx.md @@ -12,7 +12,7 @@ created: 2023-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, known as IIdentity, integrates these functionalities, providing a comprehensive solution for individuals and organizations to enforce compliance and access digital assets. +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. ## Motivation @@ -23,7 +23,14 @@ ONCHAINID aims to provide a self-sovereign identity system on the blockchain tha ## Specification ### Key Management -Keys are cryptographic public keys, or contract addresses associated with this identity. +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 @@ -60,11 +67,7 @@ function getKeysByPurpose(uint256 _purpose) constant returns(bytes32[] keys); ``` #### addKey -Adds a `_key` to the identity. The `_purpose` specifies the purpose of the key. Initially, we propose three purposes: - -- `1`: MANAGEMENT keys, which can manage the identity -- `2`: EXECUTION keys, which perform executions in this identity's name (signing, logins, transactions, etc.) -- `3`: CLAIM keys, which can add, remove and update claims on the ONCHAINID +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. From b1689722f65fa46db5a1227805d0d5209218f5c2 Mon Sep 17 00:00:00 2001 From: "kevin.thizy" Date: Fri, 6 Oct 2023 11:21:33 +0200 Subject: [PATCH 3/6] =?UTF-8?q?=F0=9F=93=9D(OID)=20Add=20claims=20details?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- EIPS/eip-7xxx.md | 196 +++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 189 insertions(+), 7 deletions(-) diff --git a/EIPS/eip-7xxx.md b/EIPS/eip-7xxx.md index 7639b4534e9032..96e7e613b490f0 100644 --- a/EIPS/eip-7xxx.md +++ b/EIPS/eip-7xxx.md @@ -1,6 +1,6 @@ --- eip: 7xxx -title: ONCHAINID: An Onchain Identity System +title: ONCHAINID - An Onchain Identity System description: Formalizing ONCHAINID, a self-sovereign identity system on Ethereum. author: Joachim Lebrun (@Joachim-Lebrun), Kevin Thizy (@Nakasar), Fabian Vogelsteller (@frozeman), Tony Malghem (@TonyMalghem), Luc Falempin(@lfalempin) discussions-to: //TBD @@ -12,13 +12,25 @@ created: 2023-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. +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. +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. +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 @@ -88,13 +100,158 @@ Removes `_key` from the identity. 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. + ### 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 `replaceKey` and `removeClaim`. +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. @@ -115,15 +272,17 @@ And **COULD** require the approval of key purpose `2`, if the `_to` of the execu **Triggers on successful execution Event**: `Executed` -**Triggers on successful claim addition Event**: `ClaimAdded` - ```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 @@ -131,6 +290,7 @@ event KeyAdded(bytes32 indexed key, uint256 indexed purpose, uint256 indexed key ``` #### `KeyRemoved` + MUST be triggered when `removeKey` was successfully called. ```solidity @@ -138,6 +298,10 @@ event KeyRemoved(bytes32 indexed key, uint256 indexed purpose, uint256 indexed k ``` #### `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 @@ -145,6 +309,7 @@ event ExecutionRequested(uint256 indexed executionId, address indexed to, uint25 ``` #### `Executed` + MUST be triggered when `approve` was called and the execution was successfully approved. ```solidity @@ -152,6 +317,7 @@ event Executed(uint256 indexed executionId, address indexed to, uint256 indexed ``` #### `Approved` + MUST be triggered when `approve` was successfully called. ```solidity @@ -159,6 +325,7 @@ event Approved(uint256 indexed executionId, bool approved); ``` #### `KeysRequiredChanged` + MUST be triggered when `changeKeysRequired` was successfully called. ```solidity @@ -170,9 +337,24 @@ event KeysRequiredChanged(uint256 purpose, uint256 number); ## Backwards Compatibility +There are no known standard using the previous KeyHolder and ClaimHolder proposals. ## 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 From 845c98e76748d4d58ab25d6f7208d4d0c9166f78 Mon Sep 17 00:00:00 2001 From: "kevin.thizy" Date: Fri, 6 Oct 2023 11:27:52 +0200 Subject: [PATCH 4/6] =?UTF-8?q?=F0=9F=93=9D(OID)=20Add=20claims=20details?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- EIPS/eip-7xxx.md | 8 -------- 1 file changed, 8 deletions(-) diff --git a/EIPS/eip-7xxx.md b/EIPS/eip-7xxx.md index 96e7e613b490f0..569c9371b4a0c6 100644 --- a/EIPS/eip-7xxx.md +++ b/EIPS/eip-7xxx.md @@ -324,14 +324,6 @@ MUST be triggered when `approve` was successfully called. event Approved(uint256 indexed executionId, bool approved); ``` -#### `KeysRequiredChanged` - -MUST be triggered when `changeKeysRequired` was successfully called. - -```solidity -event KeysRequiredChanged(uint256 purpose, uint256 number); -``` - ## Rationale From ef093cc5f398bc84e7da62ab4fb38eb076a3da1d Mon Sep 17 00:00:00 2001 From: "kevin.thizy" Date: Fri, 6 Oct 2023 13:52:57 +0200 Subject: [PATCH 5/6] =?UTF-8?q?=F0=9F=93=9D(OID)=20Add=20claims=20self=20a?= =?UTF-8?q?ttested=20claims?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- EIPS/eip-7xxx.md | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) diff --git a/EIPS/eip-7xxx.md b/EIPS/eip-7xxx.md index 569c9371b4a0c6..6ecb6a1a9646f6 100644 --- a/EIPS/eip-7xxx.md +++ b/EIPS/eip-7xxx.md @@ -236,6 +236,38 @@ function getClaimIdsByTopic(uint256 _topic) external view returns(bytes32[] memo > 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 @@ -253,7 +285,7 @@ Passes an execution instruction to the Key Manager. 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. +Returns `executionId`: SHOULD be sent to the `approve ` function, to approve or reject this execution. **Triggers Event**: `ExecutionRequested` @@ -326,6 +358,7 @@ event Approved(uint256 indexed executionId, bool approved); ## Rationale +Identities are meant to work alongside the OnchainID Claim Issuer specification. ## Backwards Compatibility From 691d00cc451e5f55e25a89ce499bb3de47f5fca3 Mon Sep 17 00:00:00 2001 From: "kevin.thizy" Date: Fri, 6 Oct 2023 14:31:13 +0200 Subject: [PATCH 6/6] =?UTF-8?q?=F0=9F=93=9D(OID)=20Add=20mention=20of=20pr?= =?UTF-8?q?evious=20standards?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- EIPS/eip-7xxx.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-7xxx.md b/EIPS/eip-7xxx.md index 6ecb6a1a9646f6..7c408178dc817c 100644 --- a/EIPS/eip-7xxx.md +++ b/EIPS/eip-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), Fabian Vogelsteller (@frozeman), Tony Malghem (@TonyMalghem), Luc Falempin(@lfalempin) +author: Joachim Lebrun (@Joachim-Lebrun), Kevin Thizy (@Nakasar), Tony Malghem (@TonyMalghem), Luc Falempin(@lfalempin) discussions-to: //TBD status: Draft type: Standards Track @@ -358,11 +358,13 @@ event Approved(uint256 indexed executionId, bool approved); ## Rationale -Identities are meant to work alongside the OnchainID Claim Issuer specification. + ## Backwards Compatibility -There are no known standard using the previous KeyHolder and ClaimHolder proposals. +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