From 791f48ca275c3fb940a46437aa56dd860798ab4d Mon Sep 17 00:00:00 2001 From: jdsika Date: Fri, 28 Nov 2025 10:36:43 +0100 Subject: [PATCH 1/2] Add first draft for EVES-008 Signed-off-by: jdsika --- EVES/EVES-002/eves-002.md | 6 +- EVES/EVES-003/eves-003.md | 12 +-- EVES/EVES-008/eves-008.md | 176 ++++++++++++++++++++++++++++++++++++++ EVES/SUMMARY.md | 1 + README.md | 19 ++-- 5 files changed, 196 insertions(+), 18 deletions(-) create mode 100644 EVES/EVES-008/eves-008.md diff --git a/EVES/EVES-002/eves-002.md b/EVES/EVES-002/eves-002.md index 99068b9..eef6537 100644 --- a/EVES/EVES-002/eves-002.md +++ b/EVES/EVES-002/eves-002.md @@ -38,7 +38,7 @@ The ENVITED-X Data Space is built on the following core modules: - Establish trust by verifying user and organization identities. - Enable permission management (e.g., membership validation, terms of service acceptance). - **Key Features**: - - Credentials are issued via [DEMIM](https://staging.identity.ascs.digital) and stored in W3C-compliant wallets like [Altme](https://altme.io). + - Credentials are issued via [SimpulseID](https://identity.ascs.digital) and stored in W3C-compliant wallets like [Altme](https://altme.io). - Future support for contract-based credentials (e.g., purchase or download permissions). - **Standards**: - Gaia-X Trust Framework. @@ -97,7 +97,7 @@ The ENVITED-X Data Space is built on the following core modules: The interaction between modules can be summarized as follows: 1. **Credential Issuance**: - - A user or organization requests a credential via DEMIM. + - A user or organization requests a credential via SimpulseID following the process in EVES-008. - Credential metadata includes identity, permissions, and additional attributes. - Credential is stored in a wallet (e.g., Altme) and referenced by uuid in the registry contract. @@ -140,7 +140,7 @@ Future EVES will provide detailed specifications for each module. ## References -1. [DEMIM](https://staging.identity.ascs.digital) +1. [SimpulseID](https://identity.ascs.digital) 2. [Altme Wallet](https://altme.io) 3. [Tezos FA2.1 Standard](https://gitlab.com/tzip/tzip/-/blob/master/proposals/tzip-21/tzip-21.md) 4. [Etherlink Bridge](https://www.etherlinkbridge.com/bridge) diff --git a/EVES/EVES-003/eves-003.md b/EVES/EVES-003/eves-003.md index 282c3cc..20a0684 100644 --- a/EVES/EVES-003/eves-003.md +++ b/EVES/EVES-003/eves-003.md @@ -63,11 +63,11 @@ Uploaded file names MUST exclude extensions (e.g., use `file` instead of `file.j The ENVITED-X Data Space implements a three-tiered privacy model: -| envited-x:accessRole | ENVITED-X Domain | Comment | -| -------------------- | --------------------------------------------------------------------- | ------------------------------------- | -| `isOwner` | | CID v1, signed URLs, asset credential | -| `isRegistered` | | CID v1, signed URLs, DEMIM credential | -| `isPublic` | to | CID v1, public, indexer to new URL | +| envited-x:accessRole | ENVITED-X Domain | Comment | +| -------------------- | --------------------------------------------------------------------- | ------------------------------------------ | +| `isOwner` | | CID v1, signed URLs, asset credential | +| `isRegistered` | | CID v1, signed URLs, SimpulseID credential | +| `isPublic` | to | CID v1, public, indexer to new URL | ### 4. Asset Validation and Upload Process @@ -168,7 +168,7 @@ Examples are the first five tags or "publishers", which is always ENVITED-X and | "name" | envited-x:DataResource:gx:name | | | "description" | envited-x:DataResource:gx:description | | | "tags" | $TAG = format:formatType + " " + format:version | "tags": ["GaiaX","ASCS","ENVITED-X","EVES","nft", "$TAG"] | -| "minter" | Member DID (CAIP-10) associated with user | Returned by the View from the DEMIM revocation registry | +| "minter" | Member DID (CAIP-10) associated with user | Returned by the View from the SimpulseID revocation registry | | "creators" | Name of the company | Taken from the company profile the user belongs to | | "date" | [System date-time][14] | | | "rights" | manifest:hasLicense:gx:license | [SPDX identifier][15] | diff --git a/EVES/EVES-008/eves-008.md b/EVES/EVES-008/eves-008.md new file mode 100644 index 0000000..694b6f1 --- /dev/null +++ b/EVES/EVES-008/eves-008.md @@ -0,0 +1,176 @@ +--- +eves-identifier: 008 +title: ENVITED-X SimpulseID Credential and Identity Framework +author: Carlo van Driesten (@jdsika) +discussions-to: https://github.com/ASCS-eV/credentials/blob/main/README.md +status: Draft +type: Process +created: 2025-11-28 +requires: ["EVES-001", "EVES-002", "EVES-007"] +replaces: None +--- + +## Abstract + +The SimpulseID Credential and Identity Framework defines the identity, membership, and credential architecture used within the ENVITED Ecosystem. +It specifies how organizations and natural persons are represented using W3C Verifiable Credentials v2, did:web identifiers, and Gaia‑X aligned semantics. +This EVES outlines the conceptual model, lifecycle, artifacts, and governance required for interoperable identity management in ENVITED. + +## Motivation + +The ENVITED Ecosystem requires a unified, privacy‑preserving identity model that supports trustable onboarding of organizations and users, program membership verification, and secure authentication across ENVITED services. +Existing identity systems are typically built around centralized identity federators such as Google or Microsoft, which introduce platform lock-in, limited user sovereignty, and dependencies on non-European infrastructure. +These systems lack standardized semantic foundations, interoperability across ecosystems, and cryptographically verifiable trust guarantees. +A European data-space environment like ENVITED requires an identity model that ensures sovereignty, avoids reliance on foreign identity providers, and supports open, verifiable, and interoperable credentials. +SimpulseID addresses these issues by providing: + +- A Gaia‑X aligned identity vocabulary +- Machine‐verifiable membership credentials +- did:web based decentralised identifiers with key rotation +- OIDC4VP authentication integration +- Clear governance roles for ASCS and participants + +This specification is necessary to maintain consistency across ENVITED applications, ensure long-term interoperability, and comply with European data space standards. + +## Specification + +### 1. Overview + +SimpulseID defines five credential types and supporting semantic resources enabling verifiable identity and membership management: + +- **Participant Credential** — Represents an organization. +- **ASCS Base Membership Credential** — Establishes fundamental ASCS membership. +- **ENVITED Membership Credential** — Extends membership for ENVITED services. +- **Administrator Credential** — Granted by ASCS to privileged natural persons. +- **User Credential** — Issued by participants to natural persons. + +All credentials use: + +- W3C VC Data Model v2 +- JSON‑LD contexts hosted at `https://schema.ascs.digital/` +- did:web identifiers under `did.identity.ascs.digital` +- Gaia‑X Trust Framework 24.11 semantics (`gx:*`) +- Harbour Credential Status for revocation tracking + +### 2. Lifecycle + +#### 2.1 Organization Onboarding + +1. Organization applies for ENVITED participation. +2. ASCS issues: + - Participant Credential + - ASCS Base Membership Credential + - ENVITED Membership Credential (optional) + +#### 2.2 Administrator Onboarding + +ASCS issues Administrator Credentials to individuals acting on behalf of ASCS or the participant. + +#### 2.3 User Onboarding + +Participant administrators create user DIDs and issue User Credentials. + +#### 2.4 Authentication and Verification + +1. Users authenticate via SSI‑to‑OIDC Bridge (OIDC4VP). +2. Services verify credentials, contexts, and revocation status. +3. DID resolution provides public keys and metadata. + +### 3. Key Definitions and Components + +#### 3.1 Decentralized Identifiers (did:web) + +All ENVITED entities use did:web under: + +```url +https://did.identity.ascs.digital/ +``` + +Sub‑namespaces: + +- `participants/` +- `programs/` +- `users//u-` +- `users/ascs/admin-` + +DIDs contain: + +- Tezos `did:pkh` verification keys +- Etherlink/EVM `eip155:42793` verification keys +- No personal data + +#### 3.2 JSON‑LD Contexts + +| Context | URL | +|--------|------| +| SimpulseID main context | | +| Legal form vocabulary | | +| Harbour revocation context | | + +#### 3.3 Ontologies + +Main ontology: +`https://schema.ascs.digital/SimpulseIdOntology/v1` + +Defines: + +- Classes: Participant, Memberships, User, Administrator +- Object properties: `simpulseid:legalForm`, `simpulseid:baseMembership`, `simpulseid:termsAndConditions` +- vCard address properties +- Gaia‑X identity alignment + +### 4. Reference Implementation + +A full reference implementation exists in the public repository: + +```url +https://github.com/ASCS-eV/credentials +``` + +It includes: + +- Example credentials +- Example did:web documents +- Contexts +- Ontologies +- Wallet rendering manifests (Altme compatible) + +The SSI‑to‑OIDC bridge integration is provided via: + + +## Backwards Compatibility + +This EVES introduces a new identity model and does not replace earlier ENVITED identity systems; however, it is fully interoperable with prior membership databases through mapping tables. No breaking changes are introduced to existing EVES documents. + +## References + +- W3C Verifiable Credentials v2 +- Gaia‑X Trust Framework 24.11 +- DIF Wallet Rendering Specification +- JSON-LD 1.1 +- schema.org +- vCard Ontology +- EVES‑001: ENVITED Governance +- EVES‑002: ENVITED Architecture + +## Implementation + +To deploy SimpulseID: + +1. Host contexts and ontologies at `https://schema.ascs.digital/` +2. Host did:web documents at `https://did.identity.ascs.digital/` +3. Use Altme wallets or any VC v2 wallet supporting OIDC4VP +4. Integrate credential verification in ENVITED services via SSI-to-OIDC Bridge +5. Maintain revocation registries accessible through does:web service endpoints + +Repository structure required for implementation: + +```txt +/contexts +/examples +/examples/did-web +/manifests +/ontologies +``` + +This specification MUST be implemented by all ENVITED services handling identity, membership, or access control. diff --git a/EVES/SUMMARY.md b/EVES/SUMMARY.md index 720f825..826f084 100644 --- a/EVES/SUMMARY.md +++ b/EVES/SUMMARY.md @@ -13,3 +13,4 @@ * [EVES-005: ENVITED-X Contract Negotiation Process](./EVES-005/eves-005.md) * [EVES-006: ENVITED-X Scaling Architecture](./EVES-006/eves-006.md) * [EVES-007: ENVITED-X Blockchain Identifier URN Schema](./EVES-007/eves-007.md) +* [EVES-008: ENVITED-X SimpulseID Credential and Identity Framework](./EVES-008/eves-008.md) diff --git a/README.md b/README.md index 2326b34..cc5b84b 100644 --- a/README.md +++ b/README.md @@ -10,12 +10,13 @@ The process on how to write, submit or change specifications in defined in [EVES ## EVES Overview -| Number | Title | Type | Status | -| ---------------------------------- | ---------------------------------------------------- | --------- | ------ | -| [001](./EVES/EVES-001/eves-001.md) | ENVITED-X Ecosystem Specification Process | Process | Review | -| [002](./EVES/EVES-002/eves-002.md) | ENVITED-X Data Space Architecture Overview | Standards | Draft | -| [003](./EVES/EVES-003/eves-003.md) | ENVITED-X Asset Definition and Upload Process | Standards | Review | -| [004](./EVES/EVES-004/eves-004.md) | ENVITED-X Roles and Responsibilities of EVES Editors | Process | Review | -| [005](./EVES/EVES-005/eves-005.md) | ENVITED-X Contract Negotiation Process | Process | Review | -| [006](./EVES/EVES-006/eves-006.md) | ENVITED-X Scaling Architecture | Process | Draft | -| [007](./EVES/EVES-007/eves-007.md) | ENVITED-X Blockchain Identifier URN Schema | Standards | Draft | +| Number | Title | Type | Status | +| ---------------------------------- | ------------------------------------------------------ | --------- | ------ | +| [001](./EVES/EVES-001/eves-001.md) | ENVITED-X Ecosystem Specification Process | Process | Review | +| [002](./EVES/EVES-002/eves-002.md) | ENVITED-X Data Space Architecture Overview | Standards | Draft | +| [003](./EVES/EVES-003/eves-003.md) | ENVITED-X Asset Definition and Upload Process | Standards | Review | +| [004](./EVES/EVES-004/eves-004.md) | ENVITED-X Roles and Responsibilities of EVES Editors | Process | Review | +| [005](./EVES/EVES-005/eves-005.md) | ENVITED-X Contract Negotiation Process | Process | Review | +| [006](./EVES/EVES-006/eves-006.md) | ENVITED-X Scaling Architecture | Process | Draft | +| [007](./EVES/EVES-007/eves-007.md) | ENVITED-X Blockchain Identifier URN Schema | Standards | Draft | +| [008](./EVES/EVES-008/eves-008.md) | ENVITED-X SimpulseID Credential and Identity Framework | Process | Draft | From 8e1e92ded14e4a57fbf0fde8028ef4caa0cfb7d1 Mon Sep 17 00:00:00 2001 From: jdsika Date: Fri, 28 Nov 2025 10:42:43 +0100 Subject: [PATCH 2/2] mardown lint Signed-off-by: jdsika --- EVES/EVES-007/eves-007.md | 34 ++++++------ EVES/EVES-008/eves-008.md | 112 +++++++++++++++++++------------------- 2 files changed, 74 insertions(+), 72 deletions(-) diff --git a/EVES/EVES-007/eves-007.md b/EVES/EVES-007/eves-007.md index b26c3dd..edb3d88 100644 --- a/EVES/EVES-007/eves-007.md +++ b/EVES/EVES-007/eves-007.md @@ -45,8 +45,8 @@ 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...` | | **Etherlink (Layer 2)** | `eip155` | `42793` | `urn:blockchain:eip155:42793:contract:0x646B92C8f21e55DF67E766047E4bD7bEdF8DfA14` | @@ -67,11 +67,11 @@ urn:blockchain:{chain_namespace}:{chain_id}:tx:{transaction_hash} ##### Transaction Example Mappings -| Blockchain | Namespace | Chain ID | Example URN | -|-------------------------|------------|-------------------|-----------------------------------------------------------------------------------------------------| -| **Tezos (Ghostnet)** | `tezos` | `NetXnHfVqm9iesp` | `urn:blockchain:tezos:NetXnHfVqm9iesp:tx:oojtGLnHuS8og5WGf8jF8EoxTbegfrXvpxzvyPiW2GYZFGbFLaJ` | -| **Ethereum (Mainnet)** | `eip155` | `1` | `urn:blockchain:eip155:1:tx:0xad0fa6b98b66bc19ab4936d1181697ac7f1e19755e1501e4e250434200a32cba` | -| **Etherlink (Layer 2)** | `eip155` | `42793` | `urn:blockchain:eip155:42793:tx:0xad0fa6b98b66bc19ab4936d1181697ac7f1e19755e1501e4e250434200a32cba` | +| Blockchain | Namespace | Chain ID | Example URN | +| ----------------------- | --------- | ----------------- | --------------------------------------------------------------------------------------------------- | +| **Tezos (Ghostnet)** | `tezos` | `NetXnHfVqm9iesp` | `urn:blockchain:tezos:NetXnHfVqm9iesp:tx:oojtGLnHuS8og5WGf8jF8EoxTbegfrXvpxzvyPiW2GYZFGbFLaJ` | +| **Ethereum (Mainnet)** | `eip155` | `1` | `urn:blockchain:eip155:1:tx:0xad0fa6b98b66bc19ab4936d1181697ac7f1e19755e1501e4e250434200a32cba` | +| **Etherlink (Layer 2)** | `eip155` | `42793` | `urn:blockchain:eip155:42793:tx:0xad0fa6b98b66bc19ab4936d1181697ac7f1e19755e1501e4e250434200a32cba` | > **_NOTE:_** > @@ -80,24 +80,26 @@ urn:blockchain:{chain_namespace}:{chain_id}:tx:{transaction_hash} ### 2. Standardization Considerations -- **CAIP-2 & CAIP-10 Alignment**: +- **CAIP-2 & CAIP-10 Alignment**: - The `chain_namespace` and `chain_id` **strictly follow** CAIP-2 & CAIP-10 conventions. - `eip155`, `tezos` **retain compatibility with existing tooling**. - -- **Layer 2 Distinction**: +- **Layer 2 Distinction**: + - **Etherlink URNs explicitly specify their Layer 2 chain ID** (`ghostnet: 128123`, `mainnet: 42793`). - This prevents **collision between Layer 1 and Layer 2 assets**. -- **Human-Readable & Resolvable**: +- **Human-Readable & Resolvable**: - This URN structure can be used in **metadata files (TZIP-21, ERC-721)**. - Enables **cross-chain verification of contracts and operations**. ### 3. Use Cases - **NFT Metadata (TZIP-21, ERC-721, ERC-1155)** + - Store **contract & transaction references** in **token metadata** crosschain. - **Cross-Chain Credential Verification (EVES-005, EVES-006)** + - Supports contract-based **Verifiable Credentials (SD-JWT VC)**. - **ENVITED-X Asset Tracking** @@ -105,7 +107,7 @@ urn:blockchain:{chain_namespace}:{chain_id}:tx:{transaction_hash} ### **4. MIME Type for Blockchain URNs** -To ensure structured and standardized handling of **URN-based blockchain references**, this specification defines a MIME type for representing **contract and transaction identifiers** in a machine-readable format. +To ensure structured and standardized handling of **URN-based blockchain references**, this specification defines a MIME type for representing **contract and transaction identifiers** in a machine-readable format. #### **4.1 MIME Type Definition** @@ -117,14 +119,14 @@ application/vnd.eves.blockchain-urn+json #### **4.2 Rationale** -- **`application/`** → Indicates structured data. -- **`vnd.eves.`** → Specifies the ENVITED-X standardization scope. -- **`blockchain-urn`** → Clearly identifies the content as a **URN-based blockchain reference**. +- **`application/`** → Indicates structured data. +- **`vnd.eves.`** → Specifies the ENVITED-X standardization scope. +- **`blockchain-urn`** → Clearly identifies the content as a **URN-based blockchain reference**. - **`+json`** → Specifies that the format is **compatible with JSON-based data structures**. #### **4.3 Example Usage** -The MIME type is used in metadata files, API payloads, and verifiable credential documents where blockchain URN references are required. +The MIME type is used in metadata files, API payloads, and verifiable credential documents where blockchain URN references are required. ##### **Example: NFT Metadata (TZIP-21, ERC-721)** diff --git a/EVES/EVES-008/eves-008.md b/EVES/EVES-008/eves-008.md index 694b6f1..b1b384f 100644 --- a/EVES/EVES-008/eves-008.md +++ b/EVES/EVES-008/eves-008.md @@ -24,11 +24,11 @@ These systems lack standardized semantic foundations, interoperability across ec A European data-space environment like ENVITED requires an identity model that ensures sovereignty, avoids reliance on foreign identity providers, and supports open, verifiable, and interoperable credentials. SimpulseID addresses these issues by providing: -- A Gaia‑X aligned identity vocabulary -- Machine‐verifiable membership credentials -- did:web based decentralised identifiers with key rotation -- OIDC4VP authentication integration -- Clear governance roles for ASCS and participants +- A Gaia‑X aligned identity vocabulary +- Machine‐verifiable membership credentials +- did:web based decentralised identifiers with key rotation +- OIDC4VP authentication integration +- Clear governance roles for ASCS and participants This specification is necessary to maintain consistency across ENVITED applications, ensure long-term interoperability, and comply with European data space standards. @@ -38,29 +38,29 @@ This specification is necessary to maintain consistency across ENVITED applicati SimpulseID defines five credential types and supporting semantic resources enabling verifiable identity and membership management: -- **Participant Credential** — Represents an organization. -- **ASCS Base Membership Credential** — Establishes fundamental ASCS membership. -- **ENVITED Membership Credential** — Extends membership for ENVITED services. -- **Administrator Credential** — Granted by ASCS to privileged natural persons. -- **User Credential** — Issued by participants to natural persons. +- **Participant Credential** — Represents an organization. +- **ASCS Base Membership Credential** — Establishes fundamental ASCS membership. +- **ENVITED Membership Credential** — Extends membership for ENVITED services. +- **Administrator Credential** — Granted by ASCS to privileged natural persons. +- **User Credential** — Issued by participants to natural persons. All credentials use: -- W3C VC Data Model v2 -- JSON‑LD contexts hosted at `https://schema.ascs.digital/` -- did:web identifiers under `did.identity.ascs.digital` -- Gaia‑X Trust Framework 24.11 semantics (`gx:*`) -- Harbour Credential Status for revocation tracking +- W3C VC Data Model v2 +- JSON‑LD contexts hosted at `https://schema.ascs.digital/` +- did:web identifiers under `did.identity.ascs.digital` +- Gaia‑X Trust Framework 24.11 semantics (`gx:*`) +- Harbour Credential Status for revocation tracking ### 2. Lifecycle #### 2.1 Organization Onboarding -1. Organization applies for ENVITED participation. -2. ASCS issues: - - Participant Credential - - ASCS Base Membership Credential - - ENVITED Membership Credential (optional) +1. Organization applies for ENVITED participation. +2. ASCS issues: + - Participant Credential + - ASCS Base Membership Credential + - ENVITED Membership Credential (optional) #### 2.2 Administrator Onboarding @@ -72,8 +72,8 @@ Participant administrators create user DIDs and issue User Credentials. #### 2.4 Authentication and Verification -1. Users authenticate via SSI‑to‑OIDC Bridge (OIDC4VP). -2. Services verify credentials, contexts, and revocation status. +1. Users authenticate via SSI‑to‑OIDC Bridge (OIDC4VP). +2. Services verify credentials, contexts, and revocation status. 3. DID resolution provides public keys and metadata. ### 3. Key Definitions and Components @@ -88,24 +88,24 @@ https://did.identity.ascs.digital/ Sub‑namespaces: -- `participants/` -- `programs/` -- `users//u-` -- `users/ascs/admin-` +- `participants/` +- `programs/` +- `users//u-` +- `users/ascs/admin-` DIDs contain: -- Tezos `did:pkh` verification keys -- Etherlink/EVM `eip155:42793` verification keys -- No personal data +- Tezos `did:pkh` verification keys +- Etherlink/EVM `eip155:42793` verification keys +- No personal data #### 3.2 JSON‑LD Contexts -| Context | URL | -|--------|------| -| SimpulseID main context | | -| Legal form vocabulary | | -| Harbour revocation context | | +| Context | URL | +| -------------------------- | ------------------------------------------------------------- | +| SimpulseID main context | | +| Legal form vocabulary | | +| Harbour revocation context | | #### 3.3 Ontologies @@ -114,10 +114,10 @@ Main ontology: Defines: -- Classes: Participant, Memberships, User, Administrator -- Object properties: `simpulseid:legalForm`, `simpulseid:baseMembership`, `simpulseid:termsAndConditions` -- vCard address properties -- Gaia‑X identity alignment +- Classes: Participant, Memberships, User, Administrator +- Object properties: `simpulseid:legalForm`, `simpulseid:baseMembership`, `simpulseid:termsAndConditions` +- vCard address properties +- Gaia‑X identity alignment ### 4. Reference Implementation @@ -129,11 +129,11 @@ https://github.com/ASCS-eV/credentials It includes: -- Example credentials -- Example did:web documents -- Contexts -- Ontologies -- Wallet rendering manifests (Altme compatible) +- Example credentials +- Example did:web documents +- Contexts +- Ontologies +- Wallet rendering manifests (Altme compatible) The SSI‑to‑OIDC bridge integration is provided via: @@ -144,24 +144,24 @@ This EVES introduces a new identity model and does not replace earlier ENVITED i ## References -- W3C Verifiable Credentials v2 -- Gaia‑X Trust Framework 24.11 -- DIF Wallet Rendering Specification -- JSON-LD 1.1 -- schema.org -- vCard Ontology -- EVES‑001: ENVITED Governance -- EVES‑002: ENVITED Architecture +- W3C Verifiable Credentials v2 +- Gaia‑X Trust Framework 24.11 +- DIF Wallet Rendering Specification +- JSON-LD 1.1 +- schema.org +- vCard Ontology +- EVES‑001: ENVITED Governance +- EVES‑002: ENVITED Architecture ## Implementation To deploy SimpulseID: -1. Host contexts and ontologies at `https://schema.ascs.digital/` -2. Host did:web documents at `https://did.identity.ascs.digital/` -3. Use Altme wallets or any VC v2 wallet supporting OIDC4VP -4. Integrate credential verification in ENVITED services via SSI-to-OIDC Bridge -5. Maintain revocation registries accessible through does:web service endpoints +1. Host contexts and ontologies at `https://schema.ascs.digital/` +2. Host did:web documents at `https://did.identity.ascs.digital/` +3. Use Altme wallets or any VC v2 wallet supporting OIDC4VP +4. Integrate credential verification in ENVITED services via SSI-to-OIDC Bridge +5. Maintain revocation registries accessible through does:web service endpoints Repository structure required for implementation: