From ff7c1d4e76d27287e76ddfc39ef086cc89d74d1d Mon Sep 17 00:00:00 2001 From: siyovush-hamidov Date: Fri, 27 Feb 2026 13:19:33 +0100 Subject: [PATCH 1/6] Draft EVES-008: On-Chain Identity & Revocation Management --- EVES/EVES-008/EVES-008.md | 78 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 EVES/EVES-008/EVES-008.md diff --git a/EVES/EVES-008/EVES-008.md b/EVES/EVES-008/EVES-008.md new file mode 100644 index 0000000..635d158 --- /dev/null +++ b/EVES/EVES-008/EVES-008.md @@ -0,0 +1,78 @@ +--- +eves-identifier: 008 +title: ENVITED-X On-Chain Identity & Revocation Management +author: [Your Name] (@GitHub user) +discussions-to: https://github.com/ASCS-eV/EVES/issues/ +status: Draft +type: Process +created: 2026-02-27 +requires: ["EVES-001"] +replaces: None +--- + +## Abstract + +This specification defines the core decentralized identity (DID) architecture and operational lifecycle for the ENVITED-X ecosystem. It introduces the application of the `did:ethr` method on the EVM-compatible Tezos Etherlink layer, describes an IPFS-backed approach for managing Credential Revocation Sets (CRSet), and details a Gas Station relay service to provide frictionless onboarding for ecosystem participants. + +## Motivation + +The ENVITED-X Data Space requires a robust, scalable, and verifiable on-chain identity architecture: +1. **DID Method Verification**: The legacy SimpulseID implementation lacked resolvable DID documents on Tezos deployments, hindering direct on-chain verification by smart contracts. +2. **Revocation Scalability**: Maintaining extensive Credential Revocation Sets (CRSet) purely via EVM smart contracts (or blob transactions) incurs unpredictable costs and storage constraints on Layer 2. +3. **Frictionless Onboarding**: Requiring Trust Anchors or new Companies to acquire crypto funds solely to interact with a base registry (e.g., delegating authority) creates a significant adoption bottleneck. + +By standardizing these three pillars—DID Method, Revocation Mechanics, and Gasless Onboarding—this EVES ensures a cohesive, interoperable trust framework. + +## Specification + +### 1. Decentralized Identifier (DID) Method Selection + +The ENVITED-X ecosystem mandates the use of the **`did:ethr`** method, conforming to the [ERC-1056 Smart Contract standard](https://eips.ethereum.org/EIPS/eip-1056). + +- **Deployment Layer**: Contract instances MUST be deployed on EVM-compatible networks, specifically targeting the Tezos Etherlink L2. +- **Key Management**: The DID identifier remains permanent, while the `identityOwner` (controller) can be rotated independently of the address via `changeOwner`. +- **Delegation Separation**: Identifiers MUST differentiate between overarching Identity Owners and explicit Delegates (e.g., ephemeral hot wallets authorized strictly for signing Verifiable Credentials for a limited validity period). +- **Service Endpoints**: Ecosystem actors MUST utilize the native `setAttribute` functionality of the ERC-1056 registry to declare ecosystem services, fundamentally facilitating the CRSet mechanism. + +### 2. IPFS-Based Credential Revocation Set (CRSet) + +To avoid excessive on-chain storage while retaining decentralized verifiability, Credential Revocation Sets are maintained via IPFS. + +#### Workflow Implementation +1. **Storing Revocations**: Utilizing the structure proposed in the CRSet protocol, the `Issuer` MUST generate a Bloom Filter Cascade (BFC) reflecting current revoked VCs and store it on IPFS. +2. **CID Declaration**: The calculated Content Identifier (CID) MUST be published as a service endpoint within the issuer's `did:ethr` document. +3. **Verification**: A `Verifier` (e.g., ENVITED-X backend or another smart contract system) MUST resolve the issuer's DID document, retrieve the active CID from the service entry, fetch the BFC from IPFS, and evaluate the credential's status entirely off-chain. + +#### Actor Roles & Control +- **Trust Anchor**: Exercises top-level governance, typically via an M-of-N Multisig, controlling which overarching Entity/Company identities are trusted. +- **Company**: Holds the overarching organizational DID. +- **Admin**: Authorized entities (delegated by the Company or Trust Anchor) explicitly permitted to update the CRSet via the IPFS CID linkage in the registry. +- **User (Holder)**: Retains VCs, utilizing them specifically in `OID4VP` processes, passing the `credentialStatus` attribute during presentation. + +### 3. Gas Station Relay Service for Onboarding + +To establish frictionless adoption, the ENVITED-X backend implements a Gas Station relayer designed explicitly to handle Company/User onboarding operations without requiring the initializing party to hold native network tokens. + +#### Relay Workflow +1. **Read State**: The Company frontend performs a gas-free `read` operation to fetch the current `nonce` of their identity from the deployed `EthereumDIDRegistry`. +2. **Signature Construct**: The frontend constructs an EIP-712 / `keccak256` hash representing the intended `changeOwner` / delegation operation and the user signs it locally (gas-free). +3. **Relay Execution**: The signed payload is transmitted (e.g., via `POST /api/onboard`) to the Backend Relayer. +4. **Validation and Payment**: The Backend Relayer splits the signature (`v, r, s`), verifies validity against the expected payload, pays the network computational gas, and invokes the `changeOwnerSigned()` function on the ERC-1056 logic contract. + +*Note: While ERC-4337 (Account Abstraction) was evaluated, it was rejected due to lack of immediate, native compatibility with the canonical `did:ethr` registry without writing intermediary adapters.* + +## Backwards Compatibility + +This specification enforces the replacement of undocumented identity mechanics with strict adherence to `did:ethr` standards. Current infrastructure attempting to query SimpulseID generic DIDs or expecting on-chain BFC arrays will require middleware adaptation to index the IPFS CIDs referenced within the DID documents. + +## References + +- [ERC-1056: Ethereum Lightweight Identity](https://eips.ethereum.org/EIPS/eip-1056) +- [did:ethr Method Specification](https://github.com/decentralized-identity/ethr-did-resolver) +- [OID4VCI & OID4VP Overview](https://openid.net/protocols/) +- [IPFS Content Addressing](https://docs.ipfs.tech/concepts/content-addressing/) + +## Template Instructions +*(Remember to remove this section upon issuing a PR)* +- Replace `[Your Name]` with your actual name or team identifier. +- Ensure the reference to PRs/Discussions in the header points to the exact GitHub Issue. From 7b69cc169bd2881888e0d5bf12f8b1244a042191 Mon Sep 17 00:00:00 2001 From: siyovush-hamidov Date: Fri, 27 Feb 2026 13:34:56 +0100 Subject: [PATCH 2/6] Update authors and clean up template instructions in EVES-008 --- EVES/EVES-008/EVES-008.md | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/EVES/EVES-008/EVES-008.md b/EVES/EVES-008/EVES-008.md index 635d158..2ef680b 100644 --- a/EVES/EVES-008/EVES-008.md +++ b/EVES/EVES-008/EVES-008.md @@ -1,7 +1,7 @@ --- eves-identifier: 008 title: ENVITED-X On-Chain Identity & Revocation Management -author: [Your Name] (@GitHub user) +author: Sid Lamichhane (@sid030sid); Siyovush Hamidov (@siyovush-hamidov); Baki Berkay Uzel (@bakiberkay); Felix Hoops (@flhps); Carlo van Driesten (@jdsika) discussions-to: https://github.com/ASCS-eV/EVES/issues/ status: Draft type: Process @@ -69,10 +69,5 @@ This specification enforces the replacement of undocumented identity mechanics w - [ERC-1056: Ethereum Lightweight Identity](https://eips.ethereum.org/EIPS/eip-1056) - [did:ethr Method Specification](https://github.com/decentralized-identity/ethr-did-resolver) -- [OID4VCI & OID4VP Overview](https://openid.net/protocols/) +- [OID4VCI & OID4VP Overview](https://openid.net/sg/openid4vc/) - [IPFS Content Addressing](https://docs.ipfs.tech/concepts/content-addressing/) - -## Template Instructions -*(Remember to remove this section upon issuing a PR)* -- Replace `[Your Name]` with your actual name or team identifier. -- Ensure the reference to PRs/Discussions in the header points to the exact GitHub Issue. From 3243e224715e0c38332e461d90345ba6bf766449 Mon Sep 17 00:00:00 2001 From: siyovush-hamidov Date: Fri, 27 Feb 2026 13:58:06 +0100 Subject: [PATCH 3/6] fix: resolve markdownlint CI errors for MD013, MD022, MD032 and MD060 --- EVES/EVES-007/eves-007.md | 2 +- EVES/EVES-008/EVES-008.md | 10 ++++++++-- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/EVES/EVES-007/eves-007.md b/EVES/EVES-007/eves-007.md index b26c3dd..f146e5a 100644 --- a/EVES/EVES-007/eves-007.md +++ b/EVES/EVES-007/eves-007.md @@ -45,7 +45,7 @@ urn:blockchain:{chain_namespace}:{chain_id}:contract:{contract_address} ##### Smart Contract Example Mappings -| Blockchain | Namespace | Chain ID | Example URN | +| Blockchain | Namespace | Chain ID | Example URN | |-------------------------|-----------|-------------------|--------------------------------------------------------------------------------------| | **Tezos (Ghostnet)** | `tezos` | `NetXnHfVqm9iesp` | `urn:blockchain:tezos:NetXnHfVqm9iesp:contract:KT1PCaD2kmgCHy15wQ1gpqZUy9RLxyBVJdTF` | | **Ethereum (Mainnet)** | `eip155` | `1` | `urn:blockchain:eip155:1:contract:0xABC123456789...` | diff --git a/EVES/EVES-008/EVES-008.md b/EVES/EVES-008/EVES-008.md index 2ef680b..76bcfdb 100644 --- a/EVES/EVES-008/EVES-008.md +++ b/EVES/EVES-008/EVES-008.md @@ -12,11 +12,13 @@ replaces: None ## Abstract -This specification defines the core decentralized identity (DID) architecture and operational lifecycle for the ENVITED-X ecosystem. It introduces the application of the `did:ethr` method on the EVM-compatible Tezos Etherlink layer, describes an IPFS-backed approach for managing Credential Revocation Sets (CRSet), and details a Gas Station relay service to provide frictionless onboarding for ecosystem participants. +This specification defines the core decentralized identity (DID) architecture and operational lifecycle for the ENVITED-X ecosystem. +It introduces the application of the `did:ethr` method on the EVM-compatible Tezos Etherlink layer, describes an IPFS-backed approach for managing Credential Revocation Sets (CRSet), and details a Gas Station relay service to provide frictionless onboarding for ecosystem participants. ## Motivation The ENVITED-X Data Space requires a robust, scalable, and verifiable on-chain identity architecture: + 1. **DID Method Verification**: The legacy SimpulseID implementation lacked resolvable DID documents on Tezos deployments, hindering direct on-chain verification by smart contracts. 2. **Revocation Scalability**: Maintaining extensive Credential Revocation Sets (CRSet) purely via EVM smart contracts (or blob transactions) incurs unpredictable costs and storage constraints on Layer 2. 3. **Frictionless Onboarding**: Requiring Trust Anchors or new Companies to acquire crypto funds solely to interact with a base registry (e.g., delegating authority) creates a significant adoption bottleneck. @@ -39,11 +41,13 @@ The ENVITED-X ecosystem mandates the use of the **`did:ethr`** method, conformin To avoid excessive on-chain storage while retaining decentralized verifiability, Credential Revocation Sets are maintained via IPFS. #### Workflow Implementation + 1. **Storing Revocations**: Utilizing the structure proposed in the CRSet protocol, the `Issuer` MUST generate a Bloom Filter Cascade (BFC) reflecting current revoked VCs and store it on IPFS. 2. **CID Declaration**: The calculated Content Identifier (CID) MUST be published as a service endpoint within the issuer's `did:ethr` document. 3. **Verification**: A `Verifier` (e.g., ENVITED-X backend or another smart contract system) MUST resolve the issuer's DID document, retrieve the active CID from the service entry, fetch the BFC from IPFS, and evaluate the credential's status entirely off-chain. #### Actor Roles & Control + - **Trust Anchor**: Exercises top-level governance, typically via an M-of-N Multisig, controlling which overarching Entity/Company identities are trusted. - **Company**: Holds the overarching organizational DID. - **Admin**: Authorized entities (delegated by the Company or Trust Anchor) explicitly permitted to update the CRSet via the IPFS CID linkage in the registry. @@ -54,6 +58,7 @@ To avoid excessive on-chain storage while retaining decentralized verifiability, To establish frictionless adoption, the ENVITED-X backend implements a Gas Station relayer designed explicitly to handle Company/User onboarding operations without requiring the initializing party to hold native network tokens. #### Relay Workflow + 1. **Read State**: The Company frontend performs a gas-free `read` operation to fetch the current `nonce` of their identity from the deployed `EthereumDIDRegistry`. 2. **Signature Construct**: The frontend constructs an EIP-712 / `keccak256` hash representing the intended `changeOwner` / delegation operation and the user signs it locally (gas-free). 3. **Relay Execution**: The signed payload is transmitted (e.g., via `POST /api/onboard`) to the Backend Relayer. @@ -63,7 +68,8 @@ To establish frictionless adoption, the ENVITED-X backend implements a Gas Stati ## Backwards Compatibility -This specification enforces the replacement of undocumented identity mechanics with strict adherence to `did:ethr` standards. Current infrastructure attempting to query SimpulseID generic DIDs or expecting on-chain BFC arrays will require middleware adaptation to index the IPFS CIDs referenced within the DID documents. +This specification enforces the replacement of undocumented identity mechanics with strict adherence to `did:ethr` standards. +Current infrastructure attempting to query SimpulseID generic DIDs or expecting on-chain BFC arrays will require middleware adaptation to index the IPFS CIDs referenced within the DID documents. ## References From 73cce6f64a0dc000c8568c131e07620b76b8d8dd Mon Sep 17 00:00:00 2001 From: siyovush-hamidov Date: Fri, 27 Feb 2026 14:29:27 +0100 Subject: [PATCH 4/6] docs: add EVES-008 specification --- .gitignore | 7 +++- EVES/EVES-008/EVES-008.md | 79 --------------------------------------- EVES/EVES-008/eves-008.md | 79 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 85 insertions(+), 80 deletions(-) delete mode 100644 EVES/EVES-008/EVES-008.md create mode 100644 EVES/EVES-008/eves-008.md diff --git a/.gitignore b/.gitignore index a61585a..4bc390a 100644 --- a/.gitignore +++ b/.gitignore @@ -3,4 +3,9 @@ .history/ *.vsix .ionide -.DS_Store \ No newline at end of file +.DS_Store + +# Vale downloaded styles +.github/styles/Google/ +.github/styles/proselint/ +.github/styles/write-good/ \ No newline at end of file diff --git a/EVES/EVES-008/EVES-008.md b/EVES/EVES-008/EVES-008.md deleted file mode 100644 index 76bcfdb..0000000 --- a/EVES/EVES-008/EVES-008.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -eves-identifier: 008 -title: ENVITED-X On-Chain Identity & Revocation Management -author: Sid Lamichhane (@sid030sid); Siyovush Hamidov (@siyovush-hamidov); Baki Berkay Uzel (@bakiberkay); Felix Hoops (@flhps); Carlo van Driesten (@jdsika) -discussions-to: https://github.com/ASCS-eV/EVES/issues/ -status: Draft -type: Process -created: 2026-02-27 -requires: ["EVES-001"] -replaces: None ---- - -## Abstract - -This specification defines the core decentralized identity (DID) architecture and operational lifecycle for the ENVITED-X ecosystem. -It introduces the application of the `did:ethr` method on the EVM-compatible Tezos Etherlink layer, describes an IPFS-backed approach for managing Credential Revocation Sets (CRSet), and details a Gas Station relay service to provide frictionless onboarding for ecosystem participants. - -## Motivation - -The ENVITED-X Data Space requires a robust, scalable, and verifiable on-chain identity architecture: - -1. **DID Method Verification**: The legacy SimpulseID implementation lacked resolvable DID documents on Tezos deployments, hindering direct on-chain verification by smart contracts. -2. **Revocation Scalability**: Maintaining extensive Credential Revocation Sets (CRSet) purely via EVM smart contracts (or blob transactions) incurs unpredictable costs and storage constraints on Layer 2. -3. **Frictionless Onboarding**: Requiring Trust Anchors or new Companies to acquire crypto funds solely to interact with a base registry (e.g., delegating authority) creates a significant adoption bottleneck. - -By standardizing these three pillars—DID Method, Revocation Mechanics, and Gasless Onboarding—this EVES ensures a cohesive, interoperable trust framework. - -## Specification - -### 1. Decentralized Identifier (DID) Method Selection - -The ENVITED-X ecosystem mandates the use of the **`did:ethr`** method, conforming to the [ERC-1056 Smart Contract standard](https://eips.ethereum.org/EIPS/eip-1056). - -- **Deployment Layer**: Contract instances MUST be deployed on EVM-compatible networks, specifically targeting the Tezos Etherlink L2. -- **Key Management**: The DID identifier remains permanent, while the `identityOwner` (controller) can be rotated independently of the address via `changeOwner`. -- **Delegation Separation**: Identifiers MUST differentiate between overarching Identity Owners and explicit Delegates (e.g., ephemeral hot wallets authorized strictly for signing Verifiable Credentials for a limited validity period). -- **Service Endpoints**: Ecosystem actors MUST utilize the native `setAttribute` functionality of the ERC-1056 registry to declare ecosystem services, fundamentally facilitating the CRSet mechanism. - -### 2. IPFS-Based Credential Revocation Set (CRSet) - -To avoid excessive on-chain storage while retaining decentralized verifiability, Credential Revocation Sets are maintained via IPFS. - -#### Workflow Implementation - -1. **Storing Revocations**: Utilizing the structure proposed in the CRSet protocol, the `Issuer` MUST generate a Bloom Filter Cascade (BFC) reflecting current revoked VCs and store it on IPFS. -2. **CID Declaration**: The calculated Content Identifier (CID) MUST be published as a service endpoint within the issuer's `did:ethr` document. -3. **Verification**: A `Verifier` (e.g., ENVITED-X backend or another smart contract system) MUST resolve the issuer's DID document, retrieve the active CID from the service entry, fetch the BFC from IPFS, and evaluate the credential's status entirely off-chain. - -#### Actor Roles & Control - -- **Trust Anchor**: Exercises top-level governance, typically via an M-of-N Multisig, controlling which overarching Entity/Company identities are trusted. -- **Company**: Holds the overarching organizational DID. -- **Admin**: Authorized entities (delegated by the Company or Trust Anchor) explicitly permitted to update the CRSet via the IPFS CID linkage in the registry. -- **User (Holder)**: Retains VCs, utilizing them specifically in `OID4VP` processes, passing the `credentialStatus` attribute during presentation. - -### 3. Gas Station Relay Service for Onboarding - -To establish frictionless adoption, the ENVITED-X backend implements a Gas Station relayer designed explicitly to handle Company/User onboarding operations without requiring the initializing party to hold native network tokens. - -#### Relay Workflow - -1. **Read State**: The Company frontend performs a gas-free `read` operation to fetch the current `nonce` of their identity from the deployed `EthereumDIDRegistry`. -2. **Signature Construct**: The frontend constructs an EIP-712 / `keccak256` hash representing the intended `changeOwner` / delegation operation and the user signs it locally (gas-free). -3. **Relay Execution**: The signed payload is transmitted (e.g., via `POST /api/onboard`) to the Backend Relayer. -4. **Validation and Payment**: The Backend Relayer splits the signature (`v, r, s`), verifies validity against the expected payload, pays the network computational gas, and invokes the `changeOwnerSigned()` function on the ERC-1056 logic contract. - -*Note: While ERC-4337 (Account Abstraction) was evaluated, it was rejected due to lack of immediate, native compatibility with the canonical `did:ethr` registry without writing intermediary adapters.* - -## Backwards Compatibility - -This specification enforces the replacement of undocumented identity mechanics with strict adherence to `did:ethr` standards. -Current infrastructure attempting to query SimpulseID generic DIDs or expecting on-chain BFC arrays will require middleware adaptation to index the IPFS CIDs referenced within the DID documents. - -## References - -- [ERC-1056: Ethereum Lightweight Identity](https://eips.ethereum.org/EIPS/eip-1056) -- [did:ethr Method Specification](https://github.com/decentralized-identity/ethr-did-resolver) -- [OID4VCI & OID4VP Overview](https://openid.net/sg/openid4vc/) -- [IPFS Content Addressing](https://docs.ipfs.tech/concepts/content-addressing/) diff --git a/EVES/EVES-008/eves-008.md b/EVES/EVES-008/eves-008.md new file mode 100644 index 0000000..0ff2c6b --- /dev/null +++ b/EVES/EVES-008/eves-008.md @@ -0,0 +1,79 @@ +--- +eves-identifier: 008 +title: ENVITED-X On-Chain Identity & Revocation Management +author: Sid Lamichhane (@sid030sid); Siyovush Hamidov (@siyovush-hamidov); Baki Berkay Uzel (@bakiberkay); Felix Hoops (@flhps); Carlo van Driesten (@jdsika) +discussions-to: https://github.com/ASCS-eV/EVES/issues/ +status: Draft +type: Process +created: 2026-02-27 +requires: ["EVES-001"] +replaces: None +--- + +## Abstract + +This specification defines the core decentralized identity (DID) architecture and operational lifecycle for the ENVITED-X ecosystem. +It introduces the application of the `did:ethr` method on the EVM-compatible `Tezos` `Etherlink` layer, describes an IPFS-backed approach for managing Credential Revocation Sets (`CRSet`), and details a Gas Station relay service to provide frictionless setup for ecosystem participants. + +## Motivation + +The ENVITED-X Data Space requires a robust, scalable, and verifiable on-chain identity architecture: + +1. **DID Method Verification**: The legacy `SimpulseID` implementation lacked resolvable DID documents on `Tezos` deployments, hindering direct on-chain verification by smart contracts. +2. **Revocation Scalability**: Maintaining extensive Credential Revocation Sets (`CRSet`) purely via EVM smart contracts (or blob transactions) incurs unpredictable costs and storage constraints on Layer 2. +3. **Frictionless Setup**: Requiring Trust Anchors or new Companies to obtain cryptocurrency funds solely to interact with a base registry (for example, delegating authority) creates a significant adoption bottleneck. + +By standardizing these three pillars—DID Method, Revocation Mechanics, and Sponsored Setup—this document ensures a cohesive, interoperable trust framework. + +## Specification + +### 1. Decentralized Identifier (DID) Method Selection + +The ENVITED-X ecosystem mandates the use of the **`did:ethr`** method, conforming to the [ERC-1056 Smart Contract standard](https://eips.ethereum.org/EIPS/eip-1056). + +- **Deployment Layer**: Developers MUST deploy contract instances on EVM-compatible networks, specifically targeting the `Tezos` `Etherlink` L2. +- **Key Management**: The DID identifier remains permanent, while the controller can rotate the `identityOwner` independently of the address via `changeOwner`. +- **Delegation Separation**: Identifiers MUST differentiate between overarching Identity Owners and explicit Delegates (for example, ephemeral hot wallets holding explicit authorization strictly for signing Verifiable Credentials for a limited validity period). +- **Service Endpoints**: Ecosystem actors MUST use the native `setAttribute` feature of the ERC-1056 registry to declare ecosystem services, fundamentally facilitating the `CRSet` mechanism. + +### 2. IPFS-Based Credential Revocation Set (`CRSet`) + +To avoid excessive on-chain storage while retaining decentralized verifiability, the ecosystem maintains Credential Revocation Sets via IPFS. + +#### Workflow Implementation + +1. **Storing Revocations**: Using the structure proposed in the `CRSet` protocol, the `Issuer` MUST generate a Bloom Filter Cascade (BFC) reflecting current revoked Verifiable Credentials and store it on IPFS. +2. **CID Declaration**: The issuer MUST publish the calculated Content Identifier (`CID`) as a service endpoint within the `did:ethr` document. +3. **Verification**: A `Verifier` (for example, ENVITED-X backend or another smart contract system) MUST resolve the DID document of the issuer, retrieve the active `CID` from the service entry, fetch the BFC from IPFS, and assess the credential status entirely off-chain. + +#### Actor Roles & Control + +- **Trust Anchor**: Exercises top-level governance, typically via an M-of-N multi-signature wallet, controlling which overarching Entity/Company identities receive trust. +- **Company**: Holds the overarching organizational DID. +- **Admin**: Entities holding explicit permission (delegated by the Company or Trust Anchor) to update the `CRSet` via the IPFS `CID` linkage in the registry. +- **User (Holder)**: Retains Verifiable Credentials, using them specifically in `OID4VP` processes, passing the `credentialStatus` attribute during presentation. + +### 3. Gas Station Relay Service for Setup + +To establish frictionless adoption, the ENVITED-X backend implements a Gas Station relay service designed explicitly to handle Company/User setup operations without requiring the initializing party to hold native network tokens. + +#### Relay Workflow + +1. **Read State**: The Company frontend performs a read operation, requiring no transaction fees, to fetch the current `nonce` of their identity from the deployed `EthereumDIDRegistry`. +2. **Signature Construct**: The frontend constructs an EIP-712 / `keccak256` hash representing the intended `changeOwner` / delegation operation and the user signs it locally. +3. **Relay Execution**: The frontend transmits the signed payload (for example, via `POST /api/onboard`) to the Backend Relay Service. +4. **Validation and Payment**: The Backend Relay Service splits the signature (`v, r, s`), verifies validity against the expected payload, pays the network computational fee, and invokes the `changeOwnerSigned()` function on the ERC-1056 logic contract. + +*Note: The team evaluated ERC-4337 (Account Abstraction) but rejected it due to lack of immediate, native compatibility with the canonical `did:ethr` registry without writing intermediary adapter software.* + +## Backwards Compatibility + +This specification enforces the replacement of undocumented identity mechanics with strict adherence to `did:ethr` standards. +Current infrastructure attempting to query `SimpulseID` generic identifiers or expecting on-chain BFC arrays demands adapter software to index the IPFS `CIDs` referenced within the DID documents. + +## References + +- [ERC-1056: Ethereum Lightweight Identity](https://eips.ethereum.org/EIPS/eip-1056) +- [did:ethr Method Specification](https://github.com/decentralized-identity/ethr-did-resolver) +- [OID4VCI & OID4VP Overview](https://openid.net/sg/openid4vc/) +- [IPFS Content Addressing](https://docs.ipfs.tech/concepts/content-addressing/) \ No newline at end of file From ebf475aca3e8969db0d25a24a8533df6d6944816 Mon Sep 17 00:00:00 2001 From: siyovush-hamidov Date: Fri, 27 Feb 2026 14:32:32 +0100 Subject: [PATCH 5/6] fix: add trailing newline to EVES-008 --- EVES/EVES-008/eves-008.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EVES/EVES-008/eves-008.md b/EVES/EVES-008/eves-008.md index 0ff2c6b..a0695f3 100644 --- a/EVES/EVES-008/eves-008.md +++ b/EVES/EVES-008/eves-008.md @@ -76,4 +76,4 @@ Current infrastructure attempting to query `SimpulseID` generic identifiers or e - [ERC-1056: Ethereum Lightweight Identity](https://eips.ethereum.org/EIPS/eip-1056) - [did:ethr Method Specification](https://github.com/decentralized-identity/ethr-did-resolver) - [OID4VCI & OID4VP Overview](https://openid.net/sg/openid4vc/) -- [IPFS Content Addressing](https://docs.ipfs.tech/concepts/content-addressing/) \ No newline at end of file +- [IPFS Content Addressing](https://docs.ipfs.tech/concepts/content-addressing/) From 419f8a3b53bb21472ea8bb293ee1ddba59a336e8 Mon Sep 17 00:00:00 2001 From: siyovush-hamidov Date: Fri, 27 Feb 2026 14:42:19 +0100 Subject: [PATCH 6/6] fix: vale conflicts --- EVES/EVES-008/eves-008.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EVES/EVES-008/eves-008.md b/EVES/EVES-008/eves-008.md index a0695f3..adab71b 100644 --- a/EVES/EVES-008/eves-008.md +++ b/EVES/EVES-008/eves-008.md @@ -1,13 +1,13 @@ --- eves-identifier: 008 title: ENVITED-X On-Chain Identity & Revocation Management -author: Sid Lamichhane (@sid030sid); Siyovush Hamidov (@siyovush-hamidov); Baki Berkay Uzel (@bakiberkay); Felix Hoops (@flhps); Carlo van Driesten (@jdsika) +author: "`Sid Lamichhane` (@sid030sid); `Siyovush Hamidov` (@siyovush-hamidov); `Baki Berkay Uzel` (@bakiberkay); `Felix Hoops` (@flhps); `Carlo van Driesten` (@jdsika)" discussions-to: https://github.com/ASCS-eV/EVES/issues/ status: Draft type: Process created: 2026-02-27 requires: ["EVES-001"] -replaces: None +replaces: None --- ## Abstract