Prometheus-X Work Packages 1.4 & 1.5 Specifications

Context

Prometheus-X is tasked with providing the code that enables a 'catalog_owner' entity (for example, Visions) to deploy a catalog.

The current website https://catalog.visionstrust.com/ provides insight into what a catalog instance will ultimately become. Visions plans to deploy the first official catalog of the ecosystem.

Prometheus X aspires to incorporate decentralized and interoperable management of catalogs users (legal persons) identity into its code. This document presents the validated specifications.

Objectives

The implementation of digital identities within the Prometheus-X catalogs aims to achieve the following objectives:

• Provide a protocol for identity and cross-cutting entitlements across the ecosystem, meaning natively interoperable between catalogs and ultimately compatible with Gaia-X services.
• Favor autonomous management by the catalog_owner entity of its legal person users catalog_user(s). In particular, Prometheus-X, as an association, does not wish to deploy registers or common services other than directory of accredited catalog.
• Be delivered and operational in a short time to allow proper compliance with the overall roadmap of Prometheus-X, while being self-hosted, that is to say, without endpoints put online by Prometheus-X.

Functional overview

Here's an example of a catalog interface:

Administration of Digital Identities of Catalog Users

Each catalog is authorized to provide its catalog users with a digital identity that is directly usable across all other catalogs, any potential services of Prometheus-X (for example, services delivered from the association's website); and, in the long term, by Gaia-X services.

The digital identity of a catalog user is defined by:

• A decentralized identifier DID, a pivotal identifier within all environments;
• A "verified_identity" credential attesting to the catalog user's identity within Prometheus-X;
• Authorization credentials: for example, "ecosystem_owner" or "ecosystem_data_user". These credentials allow access to particular services.

Prior Verification of a catalog user's Identity

The identity verification procedure is ensured within the centralized application, catalog_app, deployed by the catalog_owner and carried out under its responsibility.

Once this procedure is complete, the catalog_owner issues the catalog_user their verified_identity credential, enabling them to authenticate and sign as a verified member of Prometheus-X.

The enforceable proofs of this verification are included in the verified_identity credential in order to demonstrate, if necessary, the catalog user's identity following an action signed with their DID.

The verification procedure can guarantee:

• The existence of the legal entity catalog_user;
• The identity of the “catalog_user_agent_admin” undertaking the verification procedure on behalf of its entity, catalog_owner;
• The authorization of the “catalog_user_agent_admin” to proceed with this procedure on behalf of its entity.

This procedure can be automated using third-party services that will be validated by the Prometheus-X association (for example: API for verifying a company's status; online service for verifying a person’s identity, etc.).

Directory of Descriptions

When a catalog_user wishes to publish a self_description or a description of one of their services, they have the ability, within the catalog_app application, to draft and then sign it.

The description is then deposited on a decentralized storage, and the URI of this description is added or updated on their verified_identity credential.

Thus, public access can be provided to the directory of self_descriptions and descriptions from the catalog directory.

Management of an Ecosystem

An ecosystem is a subgroup of catalog_user(s) wishing to implement a data exchange contract (for example) among themselves within a specific catalog. The ecosystem is initiated by a catalog_user who self-assigns a “ecosystem_owner” credential; and who can then invite other catalog_user(s), who can be assigned a “ecosystem_data_user” credential.

Possession of an ecosystem_owner or ecosystem_data_user credential grants access to the private workspace of the ecosystem within the catalog_app application.

Directory of accredited catalogs

A catalog deployed by a "catalog_owner" entity is officially recognized as part of the Prometheus X catalogs by decision of the association. This decision is modeled by a "catalog_label" credential issued by the Prometheus X association.

The labeling credential may contain the following public information:

• Catalog_owner informations; * URI used by the catalog for all its services (e.g., https://catalog_app.domain.org);
• ID / Official name of the catalog. - This allows access to the public directory of labeled catalogs.

This allows access to the public directory of labeled catalogs.

Implementation and Architecture

Global Environment

The smart contracts will be open source and deployed on a public EVM-compatible blockchain. Contract owners can therefore interact with them via any compatible open-source wallet.

The keys used for generating the DIDs will be of the secp256k1 type.

The credentials are data sets that comply with Gaia-X credential schemas, notably the Participant schema. These data are carried by SBTs (EIP 5484), issued via smart contracts. They contain only information that can be made publicly accessible.

EVM-Compatible Blockchain and Decentralized Storage Space

The beta version is proposed on an Ethereum testnet: Sepolia or Holesky are considered. The choice of the production blockchain environment will be enacted by Prometheus-X.

On a blockchain like Polygon, an estimate of the operating costs of a catalog contract is negligible compared to the overall deployment and operating costs of catalog_app. These costs are estimated at less than 1000 €/year based on 200 catalog users and 10,000 signatures on a Polygon/Layer 2 type blockchain.

IPFS is proposed to ensure the decentralized and secure storage of the self-description(s); The cost estimate for storing 20,000 self-descriptions is less than 250€/year.

Directory of accredited catalogs

Prometheus X deploys a smart contract, catalog_directory, which allows it to issue catalog_label credentials in SBT format to catalog_owner(s). This smart contract has a method that allows listing all the issued credentials and their status. This smart contract can be used via any compatible open-source tool.

As part of the Prometheus-X project, 3videnZ provides Prometheus-X with a business interface that makes the issuance, sending, and claim by catalog_owner of the credentials accessible without technical skills.

Administration of a catalog

Catalog_owner deploys a catalog_administration smart contract enabling them to issue verified_identity, ecosystem_owner, and ecosystem_data_user credentials to catalog_users. This smart contract features a method to list all issued credentials and their status. This smart contract can be used via any compatible open-source tool.

Within the framework of the Prometheus-X project, 3videnZ provides Visions, the catalog_owner, with a business interface enabling the issuance, sending, and claiming of credentials by users without technical expertise.

Enterprise wallet

The enterprise wallet can be any Ethereum wallet compatible with WalletConnect.

If the catalog_user wishes, 3videnZ provides, within the framework of the Prometheus-X project, a custodial enterprise wallet mywallet.cloud, which allows to: carry out the operations of claiming credentials, authentication, and signature without any specific skills.

mywallet.cloud will manage a first level of "consultation" authorization (i.e., authorized login, unauthorized signature).

Decentralized Identifiers

DIDs are self-sovereign, globally unique identifiers for entities like individuals, companies, and devices. Learn more about DIDs by walt.id.

The DID format proposed to allow authentication within the catalogs and Prometheus X is did:ethr. It meets all the criteria of the project:

• Be immediately available in production;
• Allow authentication;
• Allow delegation;
• Be W3C-compliant: enable compatibility with future use of VC/VP, with any other DID format, particularly those used by Gaia-X.

Sign-in with DID is proposed to benefit from interoperability with DID ecosystems + EVM address authentication to enable SBT-credentials gate services.

Source: https://www.researchgate.net/figure/The-authentication-process-of-a-DID-holder-The-verifier-retrieves-the-DID-document-and_fig1_343201004

DID Method = did:ethr

Native authentication of EVM address for authenticated did:ethr Ready to use open source (Apache-2.0 license) stack:

• Ethereum DID registry - https://github.com/uport-project/ethr-did-registry
• Ethereum DID resolver - https://github.com/decentralized-identity/ethr-did-resolver

Ethereum DID Registry

The Ethereum DID Registry is a decentralized ledger (open source smart contract / Apache-2.0 license) used to register ethereum DIDs and deployed on multiple EVM chains (cross-chain interoperability).

The smart contract is administration and owner free: once deployed its behavior cannot be altered. Ethereum address owner DIDs can be resolved without any fee or registration (the DID document can automatically be resolved without any action from address owners). However owners can manage their DIDs but need to pay tx fees.

Source: https://github.com/uport-project/ethr-did-registry Ethereum mainnet instance: https://etherscan.io/address/0xdca7ef03e98e0dc2b855be647c39abe984fcf21b#readContract

Ethereum DID Resolver

The Ethereum DID Resolver is an open source (Apache-2.0 license) library used to resolve ethereum DIDs (compliant with W3C DID specs)

The DID document is later used in the sign-in process to authenticate control of the DID and thus the ETH address.

The resolver can be configured with multiple networks allowing cross-chain interoperability. The DID resolution is gas free because it reads-only the chain.

Source: https://github.com/decentralized-identity/ethr-did-resolver

DiD Sign-In & Verification of SBT Credentials

Consistent with the use of did:ethr, the use of a sign-in method via a challenge of the catalog user's Ethereum address. The verifier library deliverable needs to be able to communicate with web3 wallets (Browser extensions, web apps, mobile app, ledger, …) to send sign requests for the library to verify the challenge. In this sense, open sources solutions are proposed to promote interoperability with multiple wallets:

• Sign-in with Ethereum - https://login.xyz/ - https://github.com/spruceid/siwe - walt.id idpkit
• Walletconnect - https://walletconnect.com/ - https://github.com/walletconnect

Following the connection via DiD, onchain verification of the ownership of authorization SBTs by the catalog user will allow the restoration of authorizations without additional trusted third parties.

List of Delivered Open Source Components

• Catalog_directory contract

  • EVM-compatible smartcontract & ABI
  • Documentation (including call methods)
  • Client code for Web integration of the catalog directory

• Catalog_administration contract

  • EVM-compatible Smartcontract & ABI
  • Documentation (including call methods)
  • Client code for Web integration of the credentials & descriptions directory

• Authentication Component via did:ethr: Allows authentication via DID and verification of credentials. Integrated with catalog_app, it enables the appropriate rights for catalog users.

• Signature Component via did:ethr: Incorporated into the catalog_app code, it particularly allows the signing of self-descriptions.

• Component for Publishing Descriptions on IPFS

Technologies & Languages Considered: Solidity / Javascript – Typescript

B2B Identity Service Workshop

Date: October 12th at 3:00 PM CET Document: Architecture proposal working draft - https://docs.google.com/document/d/1fiv7Rwfci3OLUjc60Jge8tEW9mJIhtBX3uxG37FDykY

Slides: https://docs.google.com/presentation/d/1HgA_PwwefxzeN2YrWDax6Zv-btTaPi-3/edit?pli=1#slide=id.p1

The specifications were presented during the workshop on October 12, 2023, with around thirty participants and active participation from Pierre Gronlier, CTO of GAÏA-X. The following contribution is integrated into the implementation work of these specifications: Alignment with https://docs.gaia-x.eu/policy-rules-committee/trust-framework/22.10/ for the verification of the identity of catalog_users.