# Introduction
Growing demand for AI products and data sovereignty **is fuelling a proliferation of institutional AI and data ecosystems.**
Since the initial release of Ocean Protocol there has been strong interest from the business and enterprise community in Ocean Protocol’s next generation data and AI ecosystem technology.
Now, thanks to Ocean Enterprise, businesses can leverage a fully compliant, stable and secure version of Ocean Protocol that includes a wide range of specially developed enterprise ready features ready for immediate deployment at scale.
### Quick Links
* [What is Ocean Enterprise?](/discover/what-is-ocean)
* [What can you do with Ocean Enterprise?](/discover/benefits)
* [Licensing Information](/discover/licensing)
* [FAQ](broken://pages/3Y6sOofwqndzkjpx5dym), [Glossary](broken://pages/R2OLx4Fnk7DPAqs49qjw)
***
*Next:* *Why Ocean?*
*Back:* [*Docs main*](/)
# What is Ocean Enterprise?
### What is Ocean Enterprise?
Ocean Enterprise is a free open-source enterprise-ready data ecosystem software solution that enables companies and public institutions to securely manage and monetize proprietary AI & data products and services in a trusted and compliant environment.\
\
Domain agnostic and collectively governed by an independent non-profit association, Ocean Enterprise is shaping a new transparent era of the data economy and is already being used by leading data-driven businesses in aerospace, agriculture, manufacturing, mobility, smart cities and more.
### Tech: Data NFTs and Datatokens
Ocean Enterprise enables decentralized access control via token-gating using Data NFTs (for assigning IP) and Datatokens (for consuming data services). \
\
Key principles:
* Publish data services as a data NFT (ERC721)
* Access the datasets and data services if you hold datatokens (ERC20)
* Consuming data services = spending datatokens
Crypto wallets, exchanges, and DAOs become *data* wallets, exchanges, and DAOs.
### Tech: Compute-to-Data (C2D)
Ocean Enterprise enables you to buy & sell private data, while preserving privacy
* Private data is valuable: using it can improve research and business outcomes. But concerns over privacy and control make it hard to access.
* Compute-to-Data (C2D) grants access run compute against the data, *on the same premises of the data*. Only the results are visible to the consumer. The data never leaves the premises. Decentralized blockchain technology does the handshaking.
* C2D enables people to sell private data while preserving privacy, as an opportunity for companies to monetize their data assets.
* C2D can also be used for data sharing in science or technology contexts, with lower liability risk, because the data doesn't move.
* Data can be on Azure or AWS, Filecoin or Arweave, REST APIs or smart contract feeds. Data may be raw AI training data, feature vectors, trained models, even AI model predictions, or non-AI data.
Compute-to-Data flow
### Ecosystem, News & Updates
Ocean Enterprise Collective emerged out of the Ocean Protocol [ecosystem](https://oceanprotocol.com/explore/ecosystem), a vibrant and forward-thinking community of data scientists and AI enthusiasts actively building and shaping the future of AI & data. \
\
Keep up to date on all the latest Ocean Enterprise developments and news by following Ocean Enterprise on [LinkedIn](https://www.linkedin.com/company/ocean-enterprise-collective) and [Medium](https://medium.com/ocean-enterprise-collective) to. Or, track Ocean Enterprise progress directly on [GitHub](https://github.com/OceanProtocolEnterprise).
***
*Next:* [*What can you do with Ocean?*](/discover/benefits)
*Back:* [*Why Ocean?*](broken://pages/EF1FkqJ9GSKnM8iRAjrc)
# What can you do with Ocean Enterprise?
Ocean Enterprise essentially provides enterprises with a comprehensive platform to build data marketplaces, enable secure data sharing, and create new revenue streams from their data assets while maintaining compliance and security standards.
**Core Capabilities:**
* **Data Monetization & Sharing**: Create secure, controlled environments for businesses to share and monetize their data assets
* **Compute-to-Data (C2D)**: Enable data processing without exposing the underlying data, maintaining privacy and security
* **Advanced Pricing Models**: Implement sophisticated pricing mechanisms for data assets and services
* **IP Licensing**: Advanced intellectual property licensing capabilities for data and algorithms
Build Your Token-gated AI dApp
Monetize by making your dApp token-gated. Users no longer have to use credit cards or manage OAuth credentials. Rather, they buy & spend ERC20 datatokens to access your dApp content.
Go further yet: rather than storing user profile data on your centralized server -- which exposes you to liability -- have it on-chain encrypted by the user's wallet, and just-in-time decrypt for the app.
Build Your Token-gated REST API
Focus on the backend: make a Web3-native REST API. Like the token-gated dApps, consumers of the REST API buy access with crypto, not credit cards.
***
*Next:* [Ocean Enterprise Collective e.V](/discover/ocean-enterprise-collective-e.v.)
*Back:* [*What is Ocean?*](/discover/what-is-ocean)
# Ocean Enterprise Collective e.V.
### Ocean Enterprise Collective e.V.
Ocean Enterprise is designed, developed maintained and governed by the Ocean Enterprise Collective e.V. (OEC): a non-profit association registered in Germany that was founded by companies representing a wide range of countries and industries including agriculture, energy, health, human resources, manufacturing and public sector.\
\
Whether startup, enterprise, or government entity, we welcome you to become a member of the OEC and join a pioneering community of passionate business leaders shaping the future of data sharing, AI compliance, and next generation digital ecosystems.\
\
OEC membership opens the door to cutting-edge technologies, high-value partnerships, and new business opportunities in the new data economy.\
\
Learn more about [OEC membership opportunities and benefits](https://www.oceanenterprise.io/member-benefits).
# Governance
This section serves as a guide to the policies, procedures, and standards that drive the development and maintenance of Ocean Enterprise software by Ocean Enterprise Collective e.V. and its community.
The section includes details on version numbering and releases, operational decision making, strategic decision making, contributions, quality assurance and code of conduct.
Quick links to pages in this section:
* [Version Numbering & Releases](https://docs.oceanenterprise.io/~/revisions/x26BXC6KT8zMWxX3gyfl/discover/governance/version-numbering-and-releases)
* [Operational Decision Making](https://docs.oceanenterprise.io/~/revisions/x26BXC6KT8zMWxX3gyfl/discover/governance/operational-decision-making)
* [Strategic Decision Making](https://docs.oceanenterprise.io/~/revisions/x26BXC6KT8zMWxX3gyfl/discover/governance/strategic-decision-making)
* [Contributions & Quality Assurance](https://docs.oceanenterprise.io/~/revisions/x26BXC6KT8zMWxX3gyfl/discover/governance/contributions-and-quality-assurance)
* [Code of Conduct](https://docs.oceanenterprise.io/~/revisions/x26BXC6KT8zMWxX3gyfl/discover/governance/code-of-conduct)
# Version Numbering & Releases
This page includes the standardised versioning system and release process used by OEC to ensure updates to the code base don't unexpectedly break existing workflows.
## 1. Version Numbering Strategy
#### Semantic Versioning
Versions of OE software are named and numbered according to MAJOR.MINOR.PATCH format (e.g., 2.3.1):
* MAJOR: Breaking changes, incompatible API modifications
* MINOR: New features, backward-compatible additions
* PATCH: Bug fixes, security patches
## 2. Release Cadence
#### Feature-Based Releases
* A new release will occur when specific features are complete, typically about every 6 months
## 3. Release Preparation Process
#### Phase 1: Planning
* Typically 3-4 months prioir to release
* Roadmap review: Maintainer meeting to finalize features for release
* Issue triage: Label and milestone assignment
* Communication: Announce upcoming release and feature freeze date
* Documentation planning: Identify docs needing updates
#### Phase 2: Development Window
* Active development: Contributors work on milestoned features
* Regular check-ins: Progress updates in public channels, typically weekly
* Pull request reviews: Prioritize release-targeted PRs
* Testing infrastructure: Ensure Continuous Iteration (CI) / Continuous Delivery (CD) pipelines are healthy
#### Phase 3: Feature Freeze
* typically 1 month before scheduled release
* Code freeze: No new features, only bug fixes
* Beta release: Deploy beta version for community testing
* Bug bash: Organized testing period with contributor participation
* Translation updates: Coordinate with localization teams
* Documentation completion: Finalize release notes, changelog, upgrade guides
#### Phase 4: Release Candidate
* Release Candidate deployment: Publish release candidate (RC)
* Final testing: Regression testing, security audit
* Sign-off process: Maintainer approval required
* Announcement draft: Prepare blog posts, social media content
#### Phase 5: Release Day
* Tag creation: Create git tag with version number
* Build artifacts: Generate and sign release binaries/packages
* Distribution: Upload to package managers, registries, download sites
* Announcement: Publish release notes, blog post, social media
* Support preparation: Ensure maintainers are available for issues
#### Phase 6: Post-Release Activities
* Monitor issue tracker for critical bugs
* Prepare hotfix releases if needed
* Gather community feedback
* Update documentation based on user questions
* Retrospective meeting with contributors
* Document lessons learned
* Update release process based on feedback
* Begin planning next release cycle
# Operational Decision Making
This page covers guidelines used for routine decisions with respect to the code base.
For routine decisions to the code base that do NOT involve new version updates or breaking updates the following approach is taken:
#### Basic Decision Framework
* Consensus-seeking: Aim for agreement through discussion
* Voting mechanism: Fallback for disputed decisions (majority)
* Public transparency: Document decisions in issue trackers or mailing lists
#### Maintainer Roles
* Release Manager: Coordinates release process; rotates between maintainers.
* Core Maintainers: Vote on major decisions, approve final releases
* Area Maintainers: Responsible for specific components
# Strategic Decision Making
This page includes guidelines used for important strategic decisions with respect to the code base.
For important strategic decisions with respect to the code base such as feature inclusion (new version updates) and feature changes (breaking updates) a vote must be taken by existing OEC Association members.
Only members in good standing are eligible to vote.
Voting on these decisions is based on a contribution-weighted voting system, where voting power is proportional to the member's level of contribution to the OEC Association's activities, as measured by:
* Technical contributions to Ocean Enterprise development
* In-Kind contributions for work needed to complete pre defined deliverables
* Financial contributions beyond membership dues
* Material contributions including subscriptions to online collaboration and marketing tools
Contribution-weights are reassessed on a quarterly basis based on the contribution level of the previous quarter.
The OEC Board acts as tie breaker. Contribution-weights are calculated according to the following structure:
* if you want to allow all published algorithms to run on the dataset, in the "Allowed Algorithms" dropdown list select "*Allow any published algorithm*". Once you select this option, the "**Selected Algorithms**" and "**Allow Trusted Algorithm Publishers**" list will be disabled.
* **Allowed Trusted Algorithm Publishers**: in this dropdown list, the "*Allow specific algorithm publishers*" option is selected and an input field is displayed.
* To allow the algorithms published by a specific publisher, enter the web3 address of the publisher and click "Add". The address will be added to the list. You can add as many publishers as you need.
* To allow algorithms published by all publisher, in the "**Allowed Trusted Algorithm Publishers**", select the option *"Allow all trusted algorithm publishers*". Once you select this option, the "**Selected Algorithms**" and "**Allow Trusted Algorithm Publishers**" list will be disabled.
**Note**: if you select nothing in the "**Allowed Algorithms**" and "**Allow Trusted Algorithm Publishers**", no algorithm will have access to run on the dataset.
* **Algorithm Privacy**: In case an asset of type **algorithm** is created, the **Algorithm Privacy** group is displayed. In this group, the checkbox "**Keep my algorithm private for Compute-to-Data**" is displayed.
* If you want the algorithm to only be run in C2D jobs, check the checkbox
* If you want the algorithm to be downloaded by consumers and have access to the code, uncheck the checkbox
**17. Service Configuration Group**
In this group, the dataset location and the node that will encrypt the file location are specified.
* **Dataset location:** based on the content's location, four types of the assets can be registered in Ocean Enterprise: of type URL, IPFS, Arweave or GraphQL
* **URL**: to register a content stored at a URL, select the **URL** tab.
* In the **File** field, add the URL. The URL can point to a file or to an API endpoint
* From the right side, select the HTTP method: GET or POST
* If header parameters are required, specify the key and value for each parameter and press "**Add**"
* Press "**Submit URL**" to verify the URL is accessible.
* **IPFS**: to register content stored in IPFS, select the **IPFS** tab.
* In the CID field, enter the content identifier of the content you want to register and press **Validate**
* **Arweave**: to register content stored in Arweave, select the Arweave tab
* In the **Transaction ID** field, enter the transaction ID of the content and press **Validate**
* **GraphQL**: to register a GraphQL query, select the **GraphQL** tab
* In the **URL** field, enter the URL of the GrapghQL server
* If header parameters are required, specify the key and value for each parameter and press "**Add**"
* In the **Query** field, enter the query to run on the GrapghQL server
* Press **Submit Query** to verify the URL
* **Provider URL, Sample File, Timeout**
* **Provider URL**: This field indicates the Ocean Node that will encrypt the URL. By default, this field is prepopulated with the Ocean Node URL used by the marketplace. If you want to use a different node, press Delete, then insert the URL of the desired Ocean Node and press Validate.
* **Sample File** (optional field): Enter the URL where a sample file of the asset is located and press **Validate**.
* **Timeout**: the time the consumer who purchased an asset has access to the asset. In the marketplace, it can be set to: 1 day, 1 week, 1 month, 1 year, or forever. The time counter starts the moment the asset is purchased. Once the time expires, the asset has to be purchased again to access it.
* Select a value from the dropdown list
**18. Access Rules**
* **Allow Eth Address** and **Deny Eth Address** lists: Use the fields in this group to determine who is allowed or denied access to the service. The rules are based on web3 addresses. These fields work the same way as the ones defined at the asset-level credentials, so please refer to steps 5 - 8 on the[ Asset Level Credentials page](/user-guides/using-the-oe-marketplace/publishing-an-asset/asset-level-credentials).
**Note:** To assess a user's right to access a service of an asset, the allow and deny lists at the asset and service level are cumulated and evaluated altogether.
**19. SSI Policies:** to enable access rules based on SSI credentials at the service level, select the "Enable SSI Policies" checkbox. The SSI Policies group is displayed. Please refer to step 11 on the[ Asset Level Credentials page](/user-guides/using-the-oe-marketplace/publishing-an-asset/asset-level-credentials) for an understanding of how these fields work.
20\. **Consumer Parameters**
Consumer Parameters are the parameters the asset uses. For a dataset of type URL, the consumer parameters are the query parameters used to call the URL. For an asset of type algorithm, the consumer parameters are the arguments passed to the program.
* To define consumer parameters for an asset, check the **"This asset uses user-defined parameters"** checkbox. The Custom parameters group is displayed
* Four types of parameters can be defined in the interface: text, number, boolean, or select (list of values).
* To define a consumer Parameter, input the following fields:
* **Parameter Name**: the name of the parameter
* **Parameter Label**: the label that will be displayed on screen
* **Description**: parameter description
* **Parameter Type**: one of the four types listed above
* **Required**: if the field is required or optional
* **Default value**: the default value of the parameter. It will be used if no value is input by the consumer at the time of consumption
* For Parameters of type "select", the screen includes additional fields where the list's values are entered.
* To add a new consumer parameter, press "**Add parameter**"
21\. Press the **Continue** button.
# Service Pricing
22\. The Asset Level Credentials screen is displayed. In this screen, the asset's price is set.
An asset published on Ocean Enterprise can either be free or paid.
* **Publishing a free asset**: Click on the **Free** tab. Check the "I want this asset to be free. I understand network fees are still to be paid" checkbox and press **Continue**.
* Publishing a paid asset: Click on the **Fixed** tab.
* In the **Price** field, enter the price for the service.
* The currency of the price is displayed at the left side of the Price field
* Press **Continue**
# Additional Asset Description
23\. The **Additional Asset Description** screen is displayed. On this screen, additional descriptions of the asset in other formats can be added. The additional descriptions will be saved in a dedicated field in the asset's DDO and can be retrieved from the cache.
* To include an additional asset description in the DDO, press the **"Create Additional Asset Description"** button.
* In the **Type** field, enter the type of the additional asset description (e.g. GAIA-X)
* In the **Content** field, insert the asset description
* You can insert as many additional asset descriptions as you need
* Press the **Continue** button
# Preview
24\. The **Preview** screen is displayed. Here you can see how the asset and service will look after they are published.
If everything is fine, proceed to the last step by pressing the **Continue** button.
# Submit
25\. The Submit screen is displayed.
* Press the **Submit** button to publish the asset.
* During the publishing process, the Metamask wallet will display notification messages that require your approval to perform the transaction on the blockchain. Approve all transactions
* After the asset is published, a confirmation message is displayed on screen.
* Press the **View Asset** button to show the asset.
Please note that from the time an asset is created on the blockchain until it is indexed by the Ocean Node’s indexer, a delay may occur. This delay typically ranges from a few seconds to several minutes, depending on factors such as RPC endpoint performance, the current indexed block, and the machine’s processing capacity running the Ocean Node.
# Editing an asset
Editing an asset allows the asset's owner to:
* change the asset's attributes
* change the state of an asset (enabled/disabled)
* add, delete, or change the asset's services
* change the status of a service (enabled/disabled)
**Note**: Once created, an asset cannot be deleted; it can only be deactivated, meaning none of its services can be consumed. Similarly, a service created within an asset cannot be deleted; it can only be deactivated, which means it cannot be consumed. However, other enabled services within the same asset can be consumed.
## Precondition
The user has logged in to the marketplace.
## Steps
1\. Select the asset. If the user is the asset owner, the "Edit Asset" option appears under the services list.
2\. Click "**Edit Asset**". The Edit screen is displayed with two options to select from:
* [*Edit Asset*](/user-guides/using-the-oe-marketplace/editing-an-asset/update-the-assets-attributes-and-state) (preselected), to update the asset's attributes and state
* [*Edit Services*](/user-guides/using-the-oe-marketplace/editing-an-asset/update-the-assets-services) to update the attributes or the state of an existing service, or to add a new service to the asset
# Update the asset's attributes and state
To update the asset's attributes, perform the following:
1\. From the Edit page, select the option "**Edit Asset**". You can update the following attributes:
* Title
* Description
* Sample file URL
* Tags
* Author
* Access rules
* State. Select one of the following:
* Active - the asset is consumable
* EndOfLife - the asset is not consumable
* Deprecated - the asset is not consumable
* RevokedByPublisher - the asset is not consumable
* OrderingIsTemporaryDisabled - the asset is not consumable
* Unlisted - the asset is not consumable
* License file
* Additional Asset Description
For a description of each of these attributes, please review the [Publishing an asset](/user-guides/using-the-oe-marketplace/publishing-an-asset) page, steps 1 and 2.
**Note**: The Asset Type (Dataset or Algorithm) cannot be changed once set.
2\. After the changes were made, click "**Submit**". A transaction request notification from Metamask appears on the screen. Press "**Confirm**".
3\. A confirmation message is displayed on the screen. Click "**Back to Asset**" to return to the asset details screen.
Please note that from the time an asset is updated on the blockchain until it is indexed by the Ocean Node’s indexer, a delay may occur. This delay typically ranges from a few seconds to several minutes, depending on factors such as RPC endpoint performance, the current indexed block, and the machine’s processing capacity running the Ocean Node.
# Update the asset's services
To update the asset's services, perform the following:
1\. From the Edit page, select the option "**Edit Service**". The existing services are listed, along with a button to add a new service.
From this screen, you can perform the following:
* [Update an existing service](/user-guides/using-the-oe-marketplace/editing-an-asset/update-the-assets-services/update-an-existing-service)
* [Create a new service](/user-guides/using-the-oe-marketplace/editing-an-asset/update-the-assets-services/create-a-new-service)
# Update an existing service
To update an existing service, perform the following:
1 . Click on the service. The service attributes are displayed.
2\. You can change the following attributes:
* Service Name
* Service Description
* Service Language
* Price: Please note that if the service is paid, it cannot be changed to a free service and vice versa.
* Payment Collector Address: By default, the payment collector address is the publisher's address; however, it can be changed to a different address.
* Provider URL: the Ocean Node that will encrypt the asset.
* The asset's file: it is protected and not displayed in this field. If you want to change it, first, delete the existing file and then add the new one.
* Timeout
* Service State: select one of the following:
* Active - the service is consumable
* EndOfLife - the service is not consumable
* Deprecated - the service is not consumable
* RevokedByPublisher - the service is not consumable
* OrderingIsTemporaryDisabled - the service is not consumable
* Unlisted - the service is not consumable
* Access Rules
* Consumer Parameters
For a description of each of these attributes, please review the [Publishing an asset](/user-guides/using-the-oe-marketplace/publishing-an-asset) page, step 3.
3\. After the changes were made, click "**Submit**". A transaction request notification from Metamask appears on the screen. Press "**Confirm**".
4\. A confirmation message is displayed on the screen. Click "**Back to Asset**" to return to the asset details screen.
Please note that from the time an asset is updated on the blockchain until it is indexed by the Ocean Node’s indexer, a delay may occur. This delay typically ranges from a few seconds to several minutes, depending on factors such as RPC endpoint performance, the current indexed block, and the machine’s processing capacity running the Ocean Node.
# Create a new service
To create a new service, perform the following:
1\. Click on the "**Add a new service**" button. The "Add a new service" form is displayed.
2\. Fill in the following fields:
* Service Name
* Service Description
* Service Language
* Price: If you want the asset to be free, set the price to zero. For a paid asset, set the price to a value other than zero.
* Payment Collector Address: By default, the payment collector address is the publisher's address; however, it can be changed to a different address.
* Provider URL: the Ocean Node that will encrypt the asset.
* The asset's file
* Timeout
* Access Rules
* Consumer Parameters
For a description of each of these attributes, please review step 3 of the [Publishing an asset](/user-guides/using-the-oe-marketplace/publishing-an-asset) page.
3\. After the service's attributes are entered, click "**Submit**". A transaction request notification from Metamask appears on the screen. Press "**Confirm**".
4\. A confirmation message is displayed on the screen. Click "**Back to Asset**" to return to the asset details screen.
Please note that from the time an asset is updated on the blockchain until it is indexed by the Ocean Node’s indexer, a delay may occur. This delay typically ranges from a few seconds to several minutes, depending on factors such as RPC endpoint performance, the current indexed block, and the machine’s processing capacity running the Ocean Node.
# Consuming an asset's service
Consuming an asset’s service means accessing its URI and retrieving the result on your local machine. Depending on the type of resource available at the URI, this may involve:
* Downloading a file directly to your local system.
* Calling an API endpoint and retrieving the returned results.
* Running a GraphQL query and collecting the query’s output.
**Note**: Only services of type `access` can be consumed as listed above. Services of type `compute` can only be used in a C2D job.
For a consumer to access an asset's service, the following conditions must be met:
* **Access Rights**: the consumer must be authorized to access both the asset and the service. Authorization is evaluated at both levels (asset and service) based on:
* The consumer’s Web3 address
* The required verifiable credentials defined in the SSI access policies of the asset and the service
* **Payment**: If the service is paid, the consumer must purchase access by paying:
* The service’s listed price
* Any applicable additional fees
## Precondition
* The consumer has logged in to the marketplace
## Steps
1\. Locate the asset in the Catalogue and open it by clicking its tile. The Asset Details screen will appear, showing the available services on the right side. Each service includes information about its access type (access or compute) and price.
2\. Select the service you want from the service list by pressing on its tile. The marketplace will then perform an initial access verification based on the consumer's web3 address.
**Note:**
* If the consumer’s address passes verification, no message is shown on the screen.
* If the consumer's address fails marketplace verification, an error message is displayed (see image below).
3\. Press the "**Check Credentials**" button. The next steps vary depending on whether the asset is governed by SSI-based access policies or not.
* **The asset does not have SSI-based access policies**
* The consumer's address is verified by Ocean Node against the access rules defined in the asset's description.
* If verification succeeds:
* An information message is displayed on-screen,
* The "Calculate Total Price" button is shown.
* If verification fails
* An error message is displayed on-screen
* The "Retry" button is shown
* **The asset has SSI-based access policies**
* In accordance with the SSI policies defined at the asset and service levels, the marketplace receives a request for the consumer to present one or more verifiable credentials from the consumer's SSI wallet.
* The marketplace retrieves from the consumer's SSI wallet the verifiable credentials that correspond to the SSI policy criteria.
* If no verifiable credentials correspond to the SSI policy criteria, a message stating that no credentials were found is displayed.
* If one or more verifiable credentials are found, a window with all found verifiable credentials is displayed
* Select the verifiable credentials to present and press **"Accept**".
* The DID Selector window is displayed. Select the DID that will be used to sign the verifiable presentation in which the selected verifiable credentials will be sent for verification. Then press "**Confirm**".
* The verifiable credentials are submitted for verification against the SSI policy defined in the asset metadata
* If the verification fails, an error message will be displayed on-screen.
* If verification succeeds:
* An information message is displayed on-screen
* The "**Calculate Total Price**" button is shown.
4\. Click "**Calculate Total Price**".
5\. The detailed list of costs associated with the purchase of the asset is shown.
* Check the "I agree to the Terms and Conditions" checkbox. The Terms and Conditions can be reviewed by clicking on the link.
* Check the "I agree to the License Terms under which this asset was made available". The License Terms of the asset can be reviewed by clicking on the link
* Click "**Buy**"
6 . Metamask wallet will display a spending cap request. Click "**Confirm**".
6\. Metamask wallet will display a transaction request. Click "**Confirm**".
7. The service is purchased, and the "**Download**" button is displayed.
**Note**: If a service requires consumer parameters, the corresponding fields for entering values will be displayed (see picture below). The user must enter a value for each mandatory field to enable the "Download" button.
8\. Click "**Download**". Metamask wallet will display a signature request message.
9\. The result of accessing the service's URI is downloaded.
# Running Compute-To-Data Jobs
The Compute-to-Data (C2D) feature in the OE stack enables algorithms to be executed against published datasets without exposing the raw data to end users, preserving privacy and security.
**Note:** C2D jobs can use **only** assets of type *"compute*". C2D jobs cannot be run on assets of type "download".
This chapter includes the following information:
* [Introduction to C2D](/user-guides/using-the-oe-marketplace/running-compute-to-data-jobs/c2d-concepts), where the main concepts are introduced
* [Step-by-step guide](/user-guides/using-the-oe-marketplace/running-compute-to-data-jobs/running-and-managing-c2d-jobs) to run and manage C2D jobs and the related information
# C2D Concepts
## How C2D jobs work
To run a C2D job, the user needs to purchase an "*algorithm"* asset and zero or more "*dataset*" assets. The algorithm is the program that will be executed in a container on the Ocean Node server. The datasets are downloaded in the container and accessed by the running algorithm. When the job finishes, the algorithm’s output and log files are saved. The user who started the C2D job can then download them.
**Note:** In contrast to asset downloads, which prevent users from downloading their own assets, publishers are permitted to execute C2D jobs on assets they have published.
## C2D environment
When starting a C2D job, the user can configure the environment in which the job will run, including the processing and storage resources allocated to it, as well as its maximum duration. The following resources can be configured.
* Number of processing cores
* RAM
* Disk space
* Maximum job duration
**Note**: Ensure the maximum job duration is sufficient for the job to finish. If the duration expires, the job will be terminated automatically.
When a C2D job starts, resources are allocated from the resource pool for the duration of its execution. The remaining pool resources remain available for other C2D jobs. Once the job completes, its resources are released back into the pool.
## C2D environment types
Ocean Node provides two C2D environments to run jobs:
* **Free environment:** Best for testing. It has limited compute, storage, and job duration, and is free of charge.
* **Paid environment**: Best for production. It offers more compute, storage, and longer job durations. Used resources are billed; running jobs here generates costs.
Each environment has a pool of processing and storage resources. When a C2D job starts, resources are allocated from the resource pool for the duration of its execution. Unused pool resources remain available for other C2D jobs. When a job completes, its resources are automatically released back into the pool.
**Node**: the Ocean Node operator configures each environment, so resources and job duration limits can differ from one Ocean Node to another.
## C2D job cost
In a paid environment, running C2D jobs incurs costs. Each resource has a per‑minute price (set by the Ocean Node provider), and the job cost is determined by multiplying the resource prices by the job’s duration in minutes. Let's take the following example:
In the paid environment, the unit price of each resource is:
* CPU: 0.2 EUR per 1 core/ 1 minute
* RAM: 0.1 EUR per 1 GB/ 1 minute
* Storage: 0.05 EUR per 1GB/ 1 minute
\
If the C2D job runs in a paid environment with **2 cores, 8 GB of RAM and 16 GB of storage**, for **3 minutes**, the total cost associated with this job is calculated as:
**`C2D env cost/minute`**` ``= (2 cores)*0.2EUR + (8GB RAM)*0.1EUR + (16GB storage)*0.05EUR =`` `**`2 EUR/min`**
**`Job cost = (`**`C2D env cost/minute) * 3minutes`` `**`=`**` ``2 * 3 =`` `**`6 EUR`**
So, to run the job in this environment costs 6 EUR.
To start a C2D job in a paid environment, the user needs to allocate in advance the amount that covers running the job in the selected environment for the specified maximum duration.
Continuing with our example, if the user wants to run a job for **a maximum duration of 10 minutes** in the environment described above, the allocated amount is calculated as:
**Allocated amount** = **C2D env cost/minute** \* **maximum job duration** = 2 EUR/minutes \* 10 minute = **20 EUR**
## Escrow account
When running a C2D job in a paid environment, the user must deposit the full amount needed for the maximum job duration into an escrow account. This account is set by the Ocean Enterprise Collective and is unique to each blockchain.
The following happens when the C2D job starts in a paid environment:
1. The user deposits the allocated amount into the escrow account.
2. The Ocean Node that runs the job locks this amount while the job runs.
3. Once the job finishes, the actual cost is calculated based on the per‑minute environment cost and the job’s duration (rounded up to the nearest minute).
4. The Ocean Node deducts the job cost and unlocks the rest.
5. Any leftover funds remain in the escrow account, available for future jobs or withdrawal.
# Running and managing C2D jobs
Ocean Marketplace provides a wizard to make it easier to run C2D jobs and collect results. You can start a C2D job using either a dataset or an algorithm of type *"compute"*.
In the Ocean Marketplace, you can:
* [Run a C2D starting from a dataset](/user-guides/using-the-oe-marketplace/running-compute-to-data-jobs/running-and-managing-c2d-jobs/run-a-c2d-starting-from-a-dataset)
* [Run a C2D job starting from an algorithm](/user-guides/using-the-oe-marketplace/running-compute-to-data-jobs/running-and-managing-c2d-jobs/run-a-c2d-job-starting-from-an-algorithm)
* [Manage your escrow account](/user-guides/using-the-oe-marketplace/running-compute-to-data-jobs/running-and-managing-c2d-jobs/manage-the-escrow-account)
* [See all the C2D jobs you've executed](/user-guides/using-the-oe-marketplace/running-compute-to-data-jobs/running-and-managing-c2d-jobs/c2d-jobs-history)
# Run a C2D starting from a dataset
Use the C2D wizard to run a job by selecting a dataset as the starting point.
## Precondition
* The user is logged in to the marketplace
## Steps
1\. Access the Catalogue. The catalogue lists all registered assets - datasets and algorithms - of any type - download or compute.
**Note**: to refine your selection in the catalogue, use the search bar at the top of the list or the filters available on the left side of the catalogue
2\. Select a dataset from the list. The asset details page is displayed.
3\. From the services list, select a service of type *compute*. The "**Start Compute**" button is displayed.
4\. Click "**Start Compute**". The C2D wizard is started, and Step 1 - Select Algorithm window is shown.
5\. A list of allowed algorithms to run over the selected dataset is displayed. Select the algorithm you want to run over the dataset. The algorithm will be added to the top of the list. Press **Continue**.
6\. The "**Select Algorithm Services"** screen is displayed. The list includes selected service. Press **Continue**.
7\. The "**Preview Algorithm and Service**" screen is displayed, showing the selection made so far. If you're satisfied with the selected algorithm service, press **Continue**.
8\. If any of the selected services (datasets or algorithms) contain consumer parameters, the **User Parameters** screen will open. It displays all parameters along with their default values. Provide the required inputs and select **Continue**.
9\. The **"Select C2D Environment"** screen appears. Here you’ll see the Ocean Nodes linked to the dataspace that can run C2D jobs. Each node shows which environments are available—free, paid, or both. Select a node and press **Continue**.
**Note**: At present, the list displays only the node linked to the dataspace. Future releases of OE will support multiple nodes serving a single dataspace.
9\. The **C2D Environment Configuration** screen opens. Here you’ll see the available environments for the selected Ocean Node. Each environment lists its resources, and if you choose a paid environment, you’ll also see the per‑minute price for each resource.
* Select the environment
* Set the resources your job will use
* Choose the maximum job duration. \ **Note:** For the paid environment, the C2D Environment Price field shows the total cost for the selected duration. You’ll also see a message about your escrow account balance—whether it’s enough to cover the job cost or if you need to deposit more. For more details, check the job cost and escrow account page.
* When you’re ready, confirm the configuration and click **Continue**.
10\. The "**Review**" screen opens.
This screen is divided into three sections: Assets, C2D Resources, and Fees.
* *Assets*
* Displays the price of each selected asset (algorithms and datasets).
* Includes a credential verification button next to each asset
* *C2D Resources*
* Shows the calculated cost of the C2D job.
* Displays the user’s escrow account balance.
* Indicates the additional amount to deposit if the job cost exceeds the current escrow balance.
* Fees: List applicable fees, organized into the following categories:
* Marketplace fees (datasets and algorithms)
* OEC fees (datasets and algorithms)
* Provider fees (datasets and algorithms)\ **Note**: the Provider fee is not displayed initially. It is calculated after the assets' credentials are verified.
a) In the Assets section, click the "**Check Credential**" button next to one of the assets to initiate the asset credentials verification process. The process will verify the consumer's credentials against the access rules defined for any asset. The verification is performed asset by asset.
b) If the current asset has SSI-based access policies defined, then the marketplace will run a query in the consumer's SSI wallet and list the Verifiable Credentials that match the specified criteria. Select the Verifiable Credentials you want to send for verification and click **Accept**.
c) The DID selector window is open, containing the list of all DIDs from the SSI wallet. Select the DID you want to use to sign the Verifiable Presentation in which the Verifiable Credentials selected in the previous step will be wrapped before being sent for verification. Then click **Confirm**.
d) Credential verification is performed, and each asset is marked with the Verified tag. For assets protected by SSI-based access control, the verification session remains valid only for a limited time. Within this period, the C2D job must be initiated; otherwise, it will fail. A countdown timer is displayed to indicate the remaining validity. If the validity time expires, you will have to reinitiate the credential verification process.
**Note 1**: If credential verification fails, the system displays an error message, and the C2D job cannot be executed. To proceed, you must either supply alternative credentials for verification or select different assets.
e) If the credential verification succeeds, the user has to check the two checkboxes at the bottom of the screen to confirm:
* agreement with the marketplace Terms and Conditions, and
* agreement with the license terms governing each selected asset.
**Note**: To view the license terms for an asset, click the link provided next to it. The link opens the asset details page in a new browser tab.
f) Click **Calculate Extra Fees**. The provider fees will be retrieved and displayed in the Fees section.
g) Review the total cost associated with running the C2D job and click **Buy Compute Job**.
h) Next, there will be multiple interactions with the Metamask wallet for spending cap approvals and payments, as the user purchases each asset and transfers money into the escrow account.
i) At the end, a message will notify the user that the C2D job was started. Click **Continue**.
j) The user will be returned to the Service Details screen, and the C2D job will appear in the Your Compute Jobs list. Click **Refresh** to monitor the job's status.
k) When the job finishes, click **Show Details**.
l) The Job Details page is displayed. It shows the assets used to execute the job, along with information such as the actual job duration and cost. The Results section provides links to the job’s logs and output files. To download a file, click its name in the list.
# Run a C2D job starting from an algorithm
## Precondition
* The user is logged in to the marketplace
## Steps
1\. Access the Catalogue. The catalogue lists all registered assets - datasets and algorithms - of any type - download or compute.
**Note**: to refine your selection in the catalogue, use the search bar at the top of the list or the filters available on the left side of the catalogue
2\. Select an algorithm from the list. The asset details page is displayed.
3\. From the services list, select a service of type *compute*. The "**Start Compute**" button is displayed.
4\. Click "**Start Compute**". The C2D wizard is started, and Step 1 - Select Datasets window is shown.
5\. This screen lists only the datasets that include services on which the selected algorithm can run (see [Service Metadata and Credentials](/user-guides/using-the-oe-marketplace/publishing-an-asset/service-metadata-and-credentials)).
When running a C2D job starting from an algorithm, you can select zero or more datasets on which the algorithm will be executed.
a) **Run C2D job without datasets:** If no datasets are needed to run the algorithm, mark the "Proceed without Dataset Selection" checkbox. This will disable the datasets list, remove unnecessary steps from the wizard, and enable the Continue button. Click **Continue**, then move to step 8 of this page.
b) **Run C2D job with one or more datasets:** If one or more datasets are needed to run the algorithm, select them from the list by clicking on their tiles. The "Selected" status will be displayed next to the asset's name, and the Continue button will be enabled. Click **Continue**.
6\. The "**Select Services**" page appears, showing the assets chosen in the previous step along with the services on which the algorithm can run. Select the services you want to run the algorithm on and click **Continue**.
7\. The "**Preview Selected Datasets and Services**" screen is displayed, showing the selection made so far. If you're satisfied with the selected dataset services, press **Continue**.
8\. If any of the selected services (datasets or algorithms) contain consumer parameters, the **User Parameters** screen will open. It displays all parameters along with their default values. Provide the required inputs and select **Continue**.
9\. The **"Select C2D Environment"** screen appears. Here you’ll see the Ocean Nodes linked to the dataspace that can run C2D jobs. Each node shows which environments are available—free, paid, or both. Select a node and press **Continue**.
**Note**: At present, the list displays only the node linked to the dataspace. Future releases of OE will support multiple nodes serving a single dataspace.
9\. The **C2D Environment Configuration** screen opens. Here you’ll see the available environments for the selected Ocean Node. Each environment lists its resources, and if you choose a paid environment, you’ll also see the per‑minute price for each resource.
* Select the environment
* Set the resources your job will use
* Choose the maximum job duration. \ **Note:** For the paid environment, the C2D Environment Price field shows the total cost for the selected duration. You’ll also see a message about your escrow account balance—whether it’s enough to cover the job cost or if you need to deposit more. For more details, check the job cost and escrow account page.
* When you’re ready, confirm the configuration and click **Continue**.
10\. The "**Review**" screen opens.
This screen is divided into three sections: Assets, C2D Resources, and Fees.
* *Assets*
* Displays the price of each selected asset (algorithms and datasets).
* Includes a credential verification button next to each asset
* *C2D Resources*
* Shows the calculated cost of the C2D job.
* Displays the user’s escrow account balance.
* Indicates the additional amount to deposit if the job cost exceeds the current escrow balance.
* Fees: List applicable fees, organized into the following categories:
* Marketplace fees (datasets and algorithms)
* OEC fees (datasets and algorithms)
* Provider fees (datasets and algorithms)\ **Note**: the Provider fee is not displayed initially. It is calculated after the assets' credentials are verified.
a) In the Assets section, click the "**Check Credential**" button next to one of the assets to initiate the asset credentials verification process. The process will verify the consumer's credentials against the access rules defined for any asset. The verification is performed asset by asset.
b) If the current asset has SSI-based access policies defined, then the marketplace will run a query in the consumer's SSI wallet and list the Verifiable Credentials that match the specified criteria. Select the Verifiable Credentials you want to send for verification and click **Accept**.
c) The DID selector window is open, containing the list of all DIDs from the SSI wallet. Select the DID you want to use to sign the Verifiable Presentation in which the Verifiable Credentials selected in the previous step will be wrapped before being sent for verification. Then click **Confirm**.
d) Credential verification is performed, and each asset is marked with the Verified tag. For assets protected by SSI-based access control, the verification session remains valid only for a limited time. Within this period, the C2D job must be initiated; otherwise, it will fail. A countdown timer is displayed to indicate the remaining validity. If the validity time expires, you will have to reinitiate the credential verification process.
**Note 1**: If credential verification fails, the system displays an error message, and the C2D job cannot be executed. To proceed, you must either supply alternative credentials for verification or select different assets.
e) If the credential verification succeeds, the user has to check the two checkboxes at the bottom of the screen to confirm:
* agreement with the marketplace Terms and Conditions, and
* agreement with the license terms governing each selected asset.
**Note**: To view the license terms for an asset, click the link provided next to it. The link opens the asset details page in a new browser tab.
f) Click **Calculate Extra Fees**. The provider fees will be retrieved and displayed in the Fees section.
g) Review the total cost associated with running the C2D job and click **Buy Compute Job**.
h) Next, there will be multiple interactions with the Metamask wallet for spending cap approvals and payments, as the user purchases each asset and transfers money into the escrow account.
i) At the end, a message will notify the user that the C2D job was started. Click **Continue**.
j) The user will be returned to the Service Details screen, and the C2D job will appear in the Your Compute Jobs list. Click **Refresh** to monitor the job's status.
k) When the job finishes, click **Show Details**.
l) The Job Details page is displayed. It shows the assets used to execute the job, along with information such as the actual job duration and cost. The Results section provides links to the job’s logs and output files. To download a file, click its name in the list.
# Manage the escrow account
## Precondition
* The user is logged in to the marketplace
* User has a good understanding of the C2D concepts (please consult this page: [C2D Concepts](/user-guides/using-the-oe-marketplace/running-compute-to-data-jobs/c2d-concepts))
## Steps
1\. Place the mouse over the user's web3 address and from the context menu select View Profile.
2\. The Profile view is displayed. At the top of this screen, summary information is displayed, including the funds available in the escrow account and the funds locked in the escrow account by C2D jobs, which have not been claimed yet.
3\. To withdraw the available funds in the escrow account, click the withdraw button under the Escrow Available Funds field.
4\. The **Withdraw Escrow Funds** window is displayed. Enter the amount to withdraw or press **Max** to withdraw all available funds, then press **Withdraw**.
5\. Metamask wallet will display a transaction request to be approved. Press Confirm.
6\. The funds will be moved from the escrow account to the user's wallet.
# C2D jobs history
## Precondition
* The user is logged in to the marketplace
* User has a good understanding of the C2D concepts (please consult this page: [C2D Concepts](/user-guides/using-the-oe-marketplace/running-compute-to-data-jobs/c2d-concepts))
The list of C2D jobs started by a user is displayed in two different places:
* The list of C2D jobs that were executed using the service(s) of a specific asset (dataset or algorithm) is displayed on the asset details page, within the **Your Compute Jobs** display group.
* The entire list of C2D jobs executed by a user are displayed in the profile details page, under the **Compute Jobs** tab.
# Technical Architecture
This chapter describes the technical details of the Ocean Enterprise technical stack.
***
*Next:* [*Architecture*](/developers/architecture)
# High-Level Architecture
This page describes the architecture of a Ocean Enterprise system
Ocean Enterprise has a multi-layer architecture, as presented in the following diagram.
**Data Storage Layer:** handles saving and retrieving of the data managed by the OE stack. The following types of storage are used:
* *IPFS* for storing the asset description. When an asset is created in OE, its description, including all metadata attached to the asset, is saved in IPFS.
* *Blockchain* for storing the reference to the asset description. After the description of the asset is created in IPFS, the reference to the IPFS object is saved in a transaction on the blockchain.
* *Web storage* for storing the actual content of the assets. For assets of type dataset or algorithm, their content is saved on a storage platform accessible via the HTTP protocol. The storage platform can be either on the publisher's premises or in the cloud.
**Business Logic Layer:** Ocean Enterprise enables a decentralized exchange of data, on one side, and value, on the other side, between a publisher and a consumer. The core element that enables this exchange is represented by the Smart Contracts deployed on-chain. To this end, the OE Smart Contracts implement the flows for publishing and consuming assets. This layer includes factory contracts, templates for data NFTs and data tokens, fixed-rate exchange contracts for paid assets, and Dispenser contracts for free assets.
**Services Layer:** Represented by the Ocean Node component, this layer acts as a bridge between the Business Logic Layer and SDK, orchestrating how requests are processed and how business logic is executed. It provides the following services:
* orchestration of the entire consumption flows (download and Compute-To-Data).
* validation for requests.
* data encryption/decryption
* data streaming of the purchased asset to the consumer
* indexing mechanisms for assets
* abstraction of the complexity of the business and data layer, exposing clean APIs
**SDK:** The ocean.js library encapsulates the Smart Contract functions to create assets as well as the services provided by Ocean Node in JavaScript functions, which can be used to develop OE-enabled business applications.
**User Interface:** This facilitates the interaction between an end-user and the system. OE provides two interfaces:
* *Ocean Enterprise Marketplace*: a graphical interface where users can publish, retrieve, and consume assets in a very user-friendly manner. The user interface controls how data is displayed and how it responds to user actions. It also performs input validations before passing data to deeper levels.
* *Command Line Interface (CLI)*: a set of high-level tools that enable the creation and consumption of OE assets from a command line interface. This is appropriate when OE assets need to be manipulated in back-end like applications, where a user interface is not required.
**Access Control Layer:** Is a critical component that governs who can interact with specific resources in OE and under what conditions. It acts as a gatekeeper, enforcing policies that determine user permissions based on identity or other descriptive attributes. This layer controls, for instance, who is allowed to publish assets, who is allowed to consume a specific asset, or what algorithm is allowed to be executed on top of a specific dataset.
# Dataspace Architecture
Depending on the required level of protection for the assets published in an OE-enabled dataspace, the OE stack can be configured either with or without **SSI-based access control**. Each configuration requires a distinct set of software components, which are detailed in this chapter.
**Note:** For details on SSI-based access control, refer to [Managing access to assets](/developers/fg-permissions).
## OE-enabled dataspace with SSI-based access control enabled (SSI on)
The configuration of an OE-enabled dataspace with SSI on is presented in the diagram below.
Participants interact with the dataspace through the **Marketplace**’s user interface, which enables them to manage their own assets and access assets shared by others. The **OE Node** serves as the core component of the system, supporting the secure publication, retrieval, and consumption of assets.
### **Logging in to the Marketplace**
To publish or consume assets, a user must first log in to the marketplace. Logging in requires establishing a connection to the marketplace server using both the **Web3 wallet** and the **SSI wallet**. The Web3 Wallet stores the participant’s Web3 private key, while the SSI wallet manages the participant’s DID and associated Verifiable Credentials.
In a production environment, each participant deploys their own SSI wallet instance within the dataspace to safeguard their private keys, DIDs, and Verifiable Credentials. Alternatively, the marketplace operator may offer a shared SSI wallet instance for participants who have not provisioned their own.
### Publishing an asset
When an asset is published, a corresponding NFT is created on the **Blockchain.** Then, the asset description (DDO) is encrypted by the OE Node, saved in **IPFS,** and the ID of the IPFS content is saved on-chain. The asset is then indexed by the OE Node and becomes available for consumption through the Marketplace.
### Controlling access to assets
In this configuration, the OE Node delegates asset access control to the **Policy Server**. When a participant attempts to consume the service of an asset, the OE Node forwards the request to the Policy Server, including the access control rules defined at both the asset and service levels and the participant's web3 address. Using this information, the Policy Server evaluates the request and determines whether the participant is authorized to access the service, should be denied, or - if SSI-based access policies apply - must complete additional verification.
If additional verification is required, the Policy Server forwards the request to the Verifier component, which initiates an OIDC presentation session. During this session, the Verifier and the SSI Wallet exchange several messages to determine which Verifiable Credentials must be presented. These messages flow between the Verifier and the SSI Wallet through the Policy Server, the Ocean Node, and the **Policy Server Proxy**.
Once this exchange is complete, the participant sees in the Marketplace UI a list of Verifiable Credentials that satisfy the presentation requirements. The participant selects the credentials to submit, and the SSI Wallet packages them into a Verifiable Presentation, which is then sent to the Verifier.
The Verifier evaluates the submitted credentials against the rules defined for the asset. If custom rules are present, the Verifier consults the **OPA (Open Policy Agent) Server**. Optionally, it may rely on an external **Credential Verification Service** to determine whether the credentials meet the verification criteria.
Finally, the Verifier returns an allow/deny decision to the Policy Server, which relays the result back to the participant. Access to the service is granted or denied based on this outcome.
## OE-enabled dataspace with SSI-based access control disabled (SSI off)
The configuration of an OE-enabled dataspace with SSI off is presented in the diagram below.
With SSI‑based access control disabled, asset access decisions rely solely on web3 addresses. In this setup, the OE Node handles access verification internally. As a result, the dataspace architecture remains straightforward, requiring only the **Marketplace** and **OE Node** components.
### **Logging in to the Marketplace**
To publish or consume assets, a user must first log in to the marketplace. Logging in requires establishing a connection to the marketplace server using the **Web3 wallet**.
### Publishing an asset
When an asset is published, a corresponding NFT is created on the **Blockchain.** Then, the asset description (DDO) is encrypted by the OE Node, saved in **IPFS,** and the ID of the IPFS content is saved on-chain. The asset is then indexed by the OE Node and becomes available for consumption through the Marketplace.
### Controlling access to assets
When a participant attempts to consume the service of an asset, the OE Node verifies the participant's web3 address against the allow and deny rules defined for web3 addresses, at both the asset and the service levels. The deny list takes precedence. Access to the service is granted or denied based on this outcome.
# Reference Network Architecture
**WORK IN PROGRESS**
# OE software stack components
The Ocean Enterprise software stack comprises the following components:
## Marketplace
The Marketplace provides the user interface through which dataspace participants manage their own assets and access assets shared by others. Main features include:
* Support for assets with multiple services
* Verification flow for SSI-based access control to assets
* Compute-to-Data wizard for starting C2D jobs
* Support for consumers' parameters in download and C2D flows
* User dashboard
## OE Node
The OE Node is the heart of the system; it is a multi-role component, providing the following features:
* encryption of the asset's URI and description during asset publishing
* indexing of the published assets
* on-chain verification for consumer payment
* streaming the asset's data directly to the consumer, without revealing the asset's URI
* providing a Compute-To-Data environment to run jobs using the published assets
* management of the C2D jobs
## Policy Server
The Policy Server is used by the OE Node to determine whether a consumer is authorized to access an asset’s service. It validates access credentials using both the consumer’s web3 address and any SSI‑based access policies defined for the asset. Its core responsibilities include:
* Verifying access based on the consumer’s web3 address.
* Checking for SSI-based access control policies if the web3 address is permitted.
* Forwarding any SSI-based access policies to the Verifier component for evaluation.
* Facilitating the data exchange between the Verifier and the consumer’s SSI Wallet to validate the Verifiable Credentials against the asset’s SSI policies.
* Relaying the Verifier’s allow/deny decision back to the OE Node.
## Policy Server Proxy
Policy Server Proxy exposes a set of endpoints that the SSI wallet uses to communicate with the Verifier. Its purpose is to preserve the expected communication flow between the SSI Wallet and the Verifier while routing all interactions through the OE Node and the Policy Server components.
## Verifier
The Verifier (component provided by [walt.id](https://walt.id/)) validates a wide range of digital credentials—such as W3C VCs, SD‑JWT VCs. It checks signatures, formats, and trust policies, and allows you to customize verification behavior through configurable policies, including support for ecosystems like EBSI. For more information about the walt.id verifier, please consult this link:
In the context of the OE software stack, the Verifier provides the following core functionalities:
* receives the requested credentials and the verification policies from the Policy Server and initiates a presentation session
* validates the Verifiable Credentials submitted by the SSI wallet, for a specific verification request, against the verification policies and returns a success/failure message to the Policy Server.
* invokes the OPA Server to assess and enforce custom policies during the verification process
* optionally interacts with external credential verification services to perform advanced or domain‑specific validation of Verifiable Credentials.
## SSI Wallet
The SSI Wallet (component provided by [walt.id](https://walt.id/)) is an API-driven identity wallet that lets users store, manage, and present a wide range of digital credentials—including W3C VCs, SD‑JWT VCs, using OIDC4VC standards. It also allows users to manage keys and DIDs.
In the context of the OE software stack, the SSI Wallet provides the following core functionalities:
* securely stores the participant's private keys, DIDs, and Verifiable Credentials
* Constructs a Verifiable Presentation from the credentials selected by the participant and submits it to the Verifier for validation
**Note**: It is recommended that, in a production environment, each participant deploys its own SSI Wallet instance within its infrastructure to securely store keys, DIDs, and verifiable credentials. However, the marketplace operator may also provide a default SSI Wallet instance, which the marketplace will automatically use whenever a participant does not supply its own.
## OPA Server
The Open Policy Agent Server (available [here](https://www.openpolicyagent.org/)) is a general-purpose policy engine that unifies policy enforcement, based on a high-level declarative language.
In the context of the OE software stack, the OPA Server is invoked by the Verifier to assess a set of rules and return a true/false response.
# Assets and Services
# Identifiers (DIDs)
Specification of decentralized identifiers for assets in Ocean Protocol using the DID & DDO standards.
### Identifiers
In Ocean Enterprise, we use decentralized identifiers (DIDs) to identify your asset within the network. Decentralized identifiers (DIDs) are a type of identifier that enables verifiable, decentralized digital identity. In contrast to typical, centralized identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document, allowing trustable interactions associated with that subject.
### Examples
DIDs in Ocean Enterprise follow [the generic DID scheme](https://w3c-ccg.github.io/did-spec/#the-generic-did-scheme), they look like this:
```
did:ope:0ebed8226ada17fde24b6bf2b95d27f8f05fcce09139ff5cec31f6d81a7cd2ea
```
The part after `did:ope:` is the ERC721 contract address(in checksum format) and the chainId (expressed to 10 decimal places). The following JavaScript example shows how to calculate the DID for the asset:
```javascript
const CryptoJS = require('crypto-js')
const dataNftAddress = '0xa331155197F70e5e1EA0CC2A1f9ddB1D49A9C1De'
const chainId = 1
const checksum = CryptoJS.SHA256(dataNftAddress + chainId.toString(10))
const did = 'did:op:' + checksum
console.log(did)
```
# Asset File Types
Specification of storage types for assets in Ocean Enteprise.
Ocean Enterprise does not handle the actual storage of files directly. The files are stored via other services, which are then specified within the DDO.
During the publish process, file URLs must be encrypted with the respective *Provider* API call before storing the DDO on-chain. For this, you need to send the following object to Provider (where "files" contains one or more storage objects):
```json
{
"datatokenAddress":"0x1",
"nftAddress": "0x2",
"files": [
...
]
}
```
The remainder of this document specifies the different types of storage objects that are supported:
## Static URLs
Parameters:
* `url` - File *URL*, **required**
* `method` - The HTTP *method*, **required**
* `headers` - Additional HTTP *headers*, **optional**
```json
{
"type": "url",
"url": "https://url.com/file1.csv",
"method": "GET",
"headers":
{
"Authorization": "Bearer 123",
"APIKEY": "124",
}
}
```
## Interplanetary File System
**`IPFS`**
The [Interplanetary File System](https://ipfs.tech/) (IPFS) is a distributed file storage protocol that allows computers all over the globe to store and serve files as part of a giant peer-to-peer network. Any computer, anywhere in the world, can download the IPFS software and start hosting and serving files.
Parameters:
* `hash` - The file *hash,* **required**
{
"type": "ipfs",
"hash": "XXX"
}
## GraphQL
**`GraphQL`**
[GraphQL](https://graphql.org/) is a query language for APIs and a runtime for fulfilling those queries with your existing data.
Parameters:
* `url` - Server endpoint *URL*, **required**
* `query` - The *query* to be executed, **required**
* `headers` - Additional HTTP headers, **optional**
```json
{
"type": "graphql",
"url": "http://172.15.0.15:8000/subgraphs/name/oceanprotocol/ocean-subgraph",
"headers":{
"Authorization": "Bearer 123",
"APIKEY": "124",
},
"query": """query{
nfts(orderBy: createdTimestamp,orderDirection:desc){
id
symbol
createdTimestamp
}
}"""
}
```
## Smart Contract Data
Use a smart contract as data source.
Parameters:
* `chainId` - The *chainId* used to query the contract, **required**
* `address` - The smartcontract *address*, **required**
* `abi` - The function *abi* (NOT the entire contract abi), **required**
{% code overflow="wrap" %}
```json
{
"type": "smartcontract",
"chainId": 1,
"address": "0x8149276f275EEFAc110D74AFE8AFECEaeC7d1593",
"abi": {
"inputs": [],
"name": "swapOceanFee",
"outputs": [{"internalType": "uint256", "name": "", "type": "uint256"}],
"stateMutability": "view",
"type": "function"
}
}
```
{% endcode %}
## Arweave
[Arweave](https://www.arweave.org/) is a decentralized data storage that allows permanently storing files over a distributed network of computers.
Parameters:
* `transactionId` - The *transaction identifier,* **required**
```json
{
"type": "arweave",
"transactionId": "a4qJoQZa1poIv5guEzkfgZYSAD0uYm7Vw4zm_tCswVQ",
}
```
First-class integrations supported in the future : **`Filecoin`** **`Storj`** **`SQL`**
A service can contain multiple files, using multiple storage types.
Example:
```json
{
"datatokenAddress": "0x1",
"nftAddress": "0x2",
"files": [
{
"type": "url",
"url": "https://url.com/file1.csv",
"method": "GET"
},
{
"type": "ipfs",
"hash": "XXXX"
}
]
}
```
To get information about the files after encryption, the `/fileinfo` endpoint of the [*Provider*](https://github.com/OceanProtocolEnterprise/docs/blob/OE-structure/developers/old-infrastructure/provider/README.md) returns based on a passed DID an array of file metadata (based on the file type):
```json
[
{
"type": "url",
"contentLength": 100,
"contentType": "application/json"
},
{
"type": "ipfs",
"contentLength": 130,
"contentType": "application/text"
}
]
```
This only concerns metadata about a file, but never the file URLs. The only way to decrypt them is to exchange at least 1 datatoken based on the respective service pricing scheme.
## FTP
**WORK IN PROGRESS**
# Asset Metadata
## Introduction
Asset metadata plays a critical role within the Ocean Enterprise ecosystem, enabling the cataloging and management of service offerings. Each asset can include multiple service offerings. The metadata is intended for publication to federated catalogues, ensuring that service offerings are easily discoverable across different data spaces and data ecosystems. To ensure confidentiality and integrity, the metadata is encrypted by default.
Additionally, while most metadata is stored off-chain to optimize performance and scalability, a hash of this metadata is anchored on-chain. This approach combines the benefits of off-chain storage with the immutability and security of blockchain technology, ensuring both scalable data management and verifiable metadata integrity.
Due to privacy and efficiency reasons, the asset metadata is split into two parts:
* **Off-chain part**: it is a W3C-compliant Verifiable Credential (V), encoded in VC-JWT format and stored using IPFS. It is signed by the asset publisher and encrypted.
* **On-chain part**: it is recorded on the blockchain and contains a remote pointer linking to the off‑chain part of the DDO, where the full metadata is stored.
## The off-chain part of the DDO
The off‑chain component of the DDO is encoded as a **W3C‑compliant Verifiable Credential** and signed by the asset’s publisher, ensuring authenticity and integrity.
```mermaid
graph TD
%% Main DDO Node
DDO[Asset DDO]
%% Core Pillars
DDO --> ID[id: DID String]
DDO --> CS[credentialSubject]
DDO --> Proof[proof: Cryptographic Signature]
%% Credential Subject Breakdown
CS --> Meta["`**Metadata**
name
description
type
created
updated
tags
copyrightHolder
providedBy
links
license
algorithm`"]
Meta --> Algorithm["`
**Algorithm**
(_only for assets
of type algorithm_)
@language
Version
Container`"]
Algorithm --> Container["`
**Container**
image
tag
entrypoint
`"]
CS --> AssetCreds["`**credentials**
(Asset-Level
Access Control)`"]
CS --> Services["`**services**
(_Operational Offerings_)`"]
%% Asset Level Credentials Details
AssetCreds --> AC_Allow["`**allow:**
(_Whitelist Rules_)`"]
AssetCreds --> AC_Deny["`**deny:**
(_Blacklist Rules_)
type: address
values`"]
AC_Allow --> AC_SSI["`type: SSIpolicy
vp_policies
vc_policies
request_credentials`"]
AC_Allow --> AC_Add["`type: address
values`"]
%% Services Breakdown
Services --> Serv1["`
Service
(_Data Access Payload_)
id
name
description
type (access/compute)
datatokenAddress
files
serviceEndpoint
timeout
state
credentials
consumerParameters
compute
`"]
Serv1 --> ServCreds["`**credentials**
(Service-Level
Access Control)`"]
Serv1 --> Compute["`**Compute**
allowRawAlgorithm
allowNetworkAccess
publisherTrustedAlgorithmPublishers
publisherTrustedAlgorithms
`"]
Serv1 --> ConsumerParamenters["`
**consumerParameters**
name
type
label
description
default
required
options `"]
%% Service Level Credentials Details
ServCreds --> Serv_AC_Allow["`**allow:**
(_Whitelist Rules_)`"]
Serv_AC_Allow --> Serv_AC_SSI["`type: SSIpolicy
vc_policies
request_credentials`"]
Serv_AC_Allow --> Serv_AC_Add["`type: address
values`"]
ServCreds --> Serv_AC_Deny["`**deny:**
(_Blacklist Rules_)
type: address
values`"]
```
### Verifiable Credential
| Attribute | Type | Description |
| --------------------------------------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `@context` | `Array of String` |
Specifies the W3C data standards utilized to validate the cryptographic security format of the asset document. \[ |
| "" | | |
| ]
| | |
| `type` | Array of `Strings` |
Declares the identity type of this record, systematically marked as a VerifiableCredential. \[ |
| "VerifiableCredential" | | |
| ]
| | |
| `version` | `String` | Indicates the system configuration template version used to render the document (e.g., `5.0.0`). |
| `id` | `String` | The unique Decentralized Identifier (DID) assigned to the asset, serving as its permanent global lookup address on the marketplace. |
| `credentialSubject` | `Object` | The primary container holding all asset profiles, metadata rules, distribution permissions, and pricing stats. The credentialSubject object is detailed in the table [credentialSubject](#credentialsubject). |
| `issuer` | `String` | The verified decentralized identity of the entity that signed off on publishing the asset. (e.g. `"did:web:wallet2.demo.oceanenterprise.io:wallet-api:registry:publisher132"`) |
| `proof` | `Object` | The final cryptographic payload consisting of standard encryption schemas used to verify document authenticity. |
### credentialSubject
| Attribute | Type | Description |
| ---------------- | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `chainId` | `Integer` | The blockchain network identification code where this asset and its related smart contracts reside. |
| `metadata` | `Object` | Contains all human-readable definitions of the asset, such as titles, creation dates, and licensing information. The metadata object is described in the table [Metadata](#metadata). |
| `services` | `Array of Objects` | Configuration details for asset's services, outlining the technical access paths, the node endpoints, time limits, and parameters. The service object is described in the table [Service](#service). |
| `credentials` | `Object` |
Access rules defining who can access the overall asset. The credentials object is described in the table Credentials
|
| `nftAddress` | `String` | The address of the NFT minted in the blockchain, which represents the asset. |
| `additionalDdos` | `Array` | List of additional descriptions of the asset in other formats. |
### Metadata
There are two types of assets managed in Ocean Enterprise: `datasets` and `algorithms`. Each asset type has its specific attributes.
| Attribute | Type | Description |
| ----------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `created` | `String (ISO date/time)` | The exact date and time, in ISO8601 format, when the asset profile was first registered (e.g. `2000-10-31T01:30:00Z`). |
| `updated` | `String (ISO date/time)` | The exact date and time, in ISO8601 format, when the asset profile was last updated (e.g. `2000-10-31T01:30:00Z`). |
| `type` | `String` |
Defines the format classification of the asset entry ( dataset or alogorithm). Each type has a different subset of metadata attributes.
|
| `name` | `String` | The public display name of the asset, shown to marketplace buyers. |
| `description` | `String` | Multilingual, direction-aware descriptive text detailing what the dataset contains.The description object is detailed in the table [Description](#description) |
| `tags` | `Array of Strings` | Categorization keywords used by portal search bars to filter, search, and group relevant assets. |
| `author` | `String` | Name of the entity generating this data (e.g. `Ocean Enterprise e.V.`). |
| `copyrightHolder` | `String` | The entity holding the legal copyright. |
| `providedBy` | `string` | Verifiable Credential of the entity offering this asset. |
| `links` | `Object` | Mapping of URL titles(key) and URL strings(value) |
| `license` | `Object` | The licenses applied to all services of this asset. The license object is detailed in table [License](#license). |
| `algorithm` | `Object` | This object is set only if the asset is an algorithm (the field `type` is set to `algorithm`). This algorithm object is described in table [Algorithm](#algorithm) |
#### Description
| Attribute | Type | Description |
| ------------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `@value` | `String` | Description of the asset in one specific language |
| `@direction` | `String` | Text direction, whose value is a [base direction](https://www.w3.org/TR/i18n-glossary/#dfn-base-direction) string defined by the `@direction` property in \[[JSON-LD11](https://w3c.github.io/vc-data-model/#bib-json-ld11)] .Example: `rtl` (`ltr` or `rtl`) |
| `@language` | `String` | Text language, as defined by [BCP47](https://w3c.github.io/vc-data-model/#bib-bcp47) |
Example of a `description` object:
```
"title": {
"@value": "HTML و CSS: تصميم و إنشاء مواقع الويب",
"@language": "ar",
"@direction": "rtl"
}
```
#### License
| Attribute | Type | Description |
| ----------------------------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `name` | `String` | The primary name, label, or reference link representing the master data license or legal agreement for the asset. |
| `licenseDocuments` | `Array of Objects` | A comprehensive manifest listing individual files, addendums, or reference agreements attached directly to this license profile. |
| `licenseDocuments[].additionalInformation` | `Object` | An extensible metadata bucket for storing operational file properties. |
| `licenseDocuments[].additionalInformation.size` | `Integer` | The physical file size (measured in bytes) of the attached legal or reference document. |
| `licenseDocuments[].sha256` | `String` | A unique cryptographic fingerprint of the document file. This ensures the legal terms cannot be modified or replaced without invalidating the manifest. |
| `licenseDocuments[].mirrors` | `Array of Objects` | A list of alternative hosting locations where the marketplace application can safely retrieve the document file. |
| `licenseDocuments[].mirrors[].method` | `String` | The technical HTTP transmission rule used to download the document (e.g., `get`). |
| `licenseDocuments[].mirrors[].type` | `String` | The storage infrastructure category hosting this specific copy (e.g., traditional web link `url` or decentralized storage `ipfs`). |
| `licenseDocuments[].mirrors[].url` | `String` | The precise URL destination path used to download the file if hosted on standard cloud web servers. |
| `licenseDocuments[].mirrors[].headers` | `String` | Optional protocol header parameters required by secure servers during the file download process. |
| `licenseDocuments[].mirrors[].ipfsCid` | `String` | The cryptographic Content Identifier (CID) used to fetch the file copy if it is stored across decentralized networks. |
| `licenseDocuments[].displayName` | `Object` | A localization container for the file label displayed to consumers in the marketplace portal user interface. |
| `licenseDocuments[].displayName.@direction` | `String` | Layout direction setting for rendering text (e.g., `ltr` for left-to-right languages). |
| `licenseDocuments[].displayName.@language` | `String` | niversal language standard code indicating the translation of the display text (e.g., `en`). |
| `licenseDocuments[].name` | `String` | The strict administrative filename matching the document index registry record. |
| `licenseDocuments[].description` | `Object` | A localization container used to provide supplementary details or descriptive footnotes about a specific file attachment. |
| `licenseDocuments[].description.@value` | `String` | Human-readable explanation detailing what a specific attached document or addendum covers. |
| `licenseDocuments[].description.@direction` | `String` | Layout direction setting for parsing the text block (e.g., `ltr`). |
| `licenseDocuments[].description.@language` | `String` | Universal language standard code specifying the language of the description string (e.g., `en`). |
| `licenseDocuments[].fileType` | `String` | The official file format layout standard (e.g., `png` or `text/html; charset=utf-8`), which informs the marketplace app how to correctly render or display the file to a user. |
Example of a license object including the following:
* a license file referenced as a URL ()
* two additional files:
* "test additional file": file uploaded to IPFS
* "test additional file 2": file referenced as a URL available at
```json
"license": {
"name": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf",
"licenseDocuments": [
{
"additionalInformation": {
"size": 224393
},
"sha256": "891580d4fa62d00141a6237987a68e5da03064478ca3511d95685e810fcf30d0",
"mirrors": [
{
"method": "get",
"type": "url",
"url": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf"
}
],
"displayName": {
"@value": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf",
"@direction": "ltr",
"@language": "en"
},
"name": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf",
"description": {
"@value": "",
"@direction": "ltr",
"@language": "en"
},
"fileType": "text/html; charset=utf-8"
},
{
"additionalInformation": {
"size": 27424
},
"sha256": "97edf62ae8f3ff7f77d56b7fba900a457c3d85a5777b58510ef0ca5074a7b440",
"mirrors": [
{
"headers": {},
"ipfsCid": "QmTU7vUCxUeGMmYnxiU9655meJcfvXfX5Jt58m2V8swprF",
"type": "ipfs"
}
],
"displayName": {
"@value": "test additional file",
"@direction": "ltr",
"@language": "en"
},
"name": "test additional file",
"description": {
"@value": "",
"@direction": "ltr",
"@language": "en"
},
"fileType": "png"
},
{
"additionalInformation": {
"size": 224393
},
"sha256": "0a526e7a36c2abaed8441112264dfee38d546a6bf28da1c7cac3036af8363d66",
"mirrors": [
{
"method": "get",
"type": "url",
"url": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf"
}
],
"displayName": {
"@value": "test additonal file 2",
"@direction": "ltr",
"@language": "en"
},
"name": "test additonal file 2",
"description": {
"@value": "",
"@direction": "ltr",
"@language": "en"
},
"fileType": "text/html; charset=utf-8"
}
]
}
```
#### Algorithm
| Attribute | Type | Description |
| ----------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `@language` | `String` | Language to implement the software |
| `version` | `String` | Version of the software, preferably in [SemVer](https://semver.org/) notation. E.g. `1.0.0`. |
| `container` | Object | Describes the Docker container image based on which the container that will run the algorithms will be instantiated. The container object is described in the table [Container](#container) |
#### Container
| Attribute | Type | Description |
| ------------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| `image` | `String` | The Docker image name the algorithm will run with. |
| `tag` | `String` | The Docker image tag. |
| `entrypoint` | `String` | The Docker entrypoint. `$ALGO` is a macro that gets replaced inside the compute job, depending where your algorithm code is downloaded. |
Example of a container object for an algorithm written in JavaScript/Node.js, based on Node.js v24:
```json
{
"algorithm": {
"container": {
"entrypoint": "node $ALGO",
"image": "node",
"tag": "24"
}
}
}
```
### Service
| Attribute | Type | Description |
| -------------------- | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id` | `String` | Unique ID of the asset's service |
| `name` | `String` | Service name |
| `description` | `Object` | Multilingual, direction-aware descriptive text detailing what the dataset contains.The description object is detailed in the table [Description](#description) |
| `type` | `String` | Defines the transaction fulfillment style of the service endpoint (e.g., `access` for direct data file downloading or `compute` for access to the service endpoint only within a Compute-to-Data job). |
| `datatokenAddress` | `String` | Smart contract address of the specific token assigned to this service. |
| `files` | `String` | Ecrypted access control information of the files associated with this service. When the service is consumed, the files listed here are served to the consumer. The information is encrypted by the node provided in the `serviceEndpoint` parameter. The structure of the file object encrypted and saved in this field depends on the type of file: HTTP, S3 etc. All file objects are presented in chapter [File Types](broken://pages/UO9SaREtSdAsjbOnSy5q). |
| `serviceEndpoint` | `String (URL)` | Tthe URL of the OE Node responsible for controlling the access to the service: verifying payments for the service and streaming the data files safely to the buyer. |
| `timeout` | `Integer` | The active lifetime window (measured in seconds) a consumer has to utilize or download the service from the purchase moment (e.g., `86400` seconds equals 24 hours). After the timeout is reached, the consumer has to purchase the service again in order to access it once more. |
| `state` | `Integer` | Indicates the operational lifecycle status of the service (e.g., `0` means active and purchaseable; other values designate paused or retired services). |
| `credentials` | `Object` |
Access rules defining who can access the service. The credentials object is described in the table Credentials
|
| `consumerParameters` | `Array of Objects` |
Defines the parameters the consumer has to input before consuming the asset. This object is described in table Consumer Parameters.
|
| `compute` | `Object` |
This object is defined only for services used in C2D (i.e. service.type is set to compute).
This compute object is described in table Compute.
|
#### Compute
For services used in C2D jobs, the compute object is added to the service description. This object includes the following attributes.
| Attribute | Type | Description |
| ------------------------------------------------------- | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `allowRawAlgorithm` | `boolean` |
Used only for assets of type algorithm.
Specify if passed raw text will be allowed to run. It is by default set to false (do not allow raw algorithms to run).
|
| `allowNetworkAccess` | `boolean` |
Used only for assets of type algorithm.
Specify if the algorithm job network access.
|
| `publisherTrustedAlgorithmPublishers` | `Array of Strings` |
Used only for assets of type dataset. A list of the web3 addresses of algorithm publishers that the service recognizes as trusted.
|
| `publisherTrustedAlgorithms` | `Array of Objects` |
Used only for assets of type dataset. Specify the list of algorithms allowed to run on the dataset represented by the service.
|
| `publisherTrustedAlgorithms[].did` | `String` | The DID of the asset allowed to run on the dataset |
| `publisherTrustedAlgorithms[].serviceId` | `String` | The ServiceId of the service within the asset that is allowed to run on the dataset. |
| `publisherTrustedAlgorithms[].containerSectionChecksum` | `String` | Hash of algorithm's image details |
| `publisherTrustedAlgorithms[].filesChecksum` | `String` | Hash of algorithm's files. |
Example of a compute object for a dataset service. There are two algorithm publishers trusted by this dataset (listed in `publisherTrustedAlgorithmPublishers`), meaning all algorithms from these two publishers can be executed on the dataset. Moreover, there are three additional trusted algorithms (listed in publisherTrustedAlgorithms), which can also be executed on the dataset.
```json
"compute": {
"allowRawAlgorithm": false,
"allowNetworkAccess": true,
"publisherTrustedAlgorithmPublishers": [
"0xd727fb9be39fa019d7c02fea19e54d688da3a662",
"0x61db12d8b636cb49ea09eca58a893da9480e1f33"
],
"publisherTrustedAlgorithms": [
{
"did": "did:ope:c68e6efe498f70cf0d671f9a405374176607d209546837e25b11cedbbcc9cd02",
"containerSectionChecksum": "ee2da20f61e82ced3033ad6a7cb44fe136d91b715eaf2db2811ee0b0ad4a5b99",
"filesChecksum": "2c36c054711dad021f45cc7e0990bd38864a51d753c8055b63e78014a6bee515",
"serviceId": "4d89d718fc670b20217d97466e9612244e82aad21a40d19738d2a6ed0e3e8893"
},
{
"did": "did:ope:c534e37e815b267d229c7051086f17c084ab72dce41af12df6f6daf900b30b16",
"containerSectionChecksum": "2ea683746c6927342c7ea51ddd9b8acada2490c67a357ff9b41bda64fe05cb34",
"filesChecksum": "dc0b0c89639614533fecd6ebe7dc53dcfbda96865322213dea7c3ecf88ad7ea4",
"serviceId": "ae2367882fa6d10c006dcce30b4a2bdd70434f8348c0ed6431f2125b572b12f4"
},
{
"did": "did:ope:b66c9ccce1b117711918ba1232e70d99c75e52a68a88a13639eed3a8450c41f8",
"containerSectionChecksum": "dfce591ecb9b35c1c2931c8b38b4c216a61b40cd33407ab886df3b44c6b8904d",
"filesChecksum": "ffd8c9b460451dd7d1677878f60cc93ce35a5a2517f08819761c0ddf424f7f88",
"serviceId": "40c3fefb7b73c1a3190a437227d1954f8ef682676e26c1a914668f2d05401d22"
}
]
}
```
### Consumer Parameters
| Attribute | Type | Description |
| ------------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `name` | `String` | The internal technical identifier for the parameter. |
| `type` | `String` | Controls the visual input style generated on the interface screen. Accepted configurations include `text` (string field), `select` (a dropdown menu), `number` (a numeric keypad/input field), or `boolean` (a true/false checkbox/toggle switch). |
| `label` | `String` | The human-readable title displayed directly above the input field in the marketplace portal. |
| `description` | `String` | Explanatory instructional text or tooltips presented next to the interface field to guide consumers on what their choice affects. |
| `default` | `String` | The standard pre-selected value automatically used if the user skips modifying this parameter or leaves the field empty. |
| `required` | `boolean` | Enforces entry rules. If set to `true`, the marketplace will block the consumption request until the user explicitly inputs a value. If `false`, the parameter is optional. |
| `options` | `Array of Objects` | Applicable only when `type` is set to `select`. Defines the selectable items inside the dropdown menu, mapping a backend code name (e.g., `apac`) to its user-friendly display value (e.g., `Asia Pacific`). |
Example of a consumerParameters object:
```json
"consumerParameters": [
{
"default": "eu",
"name": "region",
"options": [
{
"eu": "Europe"
},
{
"us": "United States"
},
{
"apac": "Asia Pacific"
}
],
"description": "Choose the region for the download.",
"label": "Region",
"type": "select",
"required": true
},
{
"default": "csv",
"name": "format",
"options": [
{
"csv": "CSV"
},
{
"json": "JSON"
},
{
"parquet": "Parquet"
}
],
"description": "Choose the output format returned by the download service.",
"label": "Export Format",
"type": "select",
"required": false
},
{
"default": "1000",
"name": "rowLimit",
"description": "Maximum number of rows returned.",
"label": "Row Limit",
"type": "number",
"required": false
},
{
"default": "false",
"name": "includeHeaders",
"description": "Whether the exported file should include column headers.",
"label": "Include Headers",
"type": "boolean",
"required": false
}
]
```
### Credentials
The credentials are specified at the asset level (`credentialSubject.credetials`) and at the service level (`credentialSubject.services[].credentials`). Both objects share the same structure. The only difference between the two is that asset-level credentials may include additional clauses regarding the presentation of verifiable credentials. These clauses specific to asset-level credentials are highlighted in the text below.
| Attribute | Type | Description |
| --------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `allow` | `Array of Objects` | The Access Whitelist. A collection of rules defining who *is* permitted to interact with the asset. If an entity matches any defined rule block here, they are granted baseline access. The allow object is presented in table Allow. |
| `deny` | `Array of Objects` |
The Access Blacklist. Explicit ban parameters based on web3 address. Any wallet address matching criteria in this block will be hard-blocked from accessing the asset or service, even if they qualify under the allow section.
|
#### Allow
| Attribute | Type | Description |
| ------------------------------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `type` | `String` | Specifies the security mechanism used for evaluation. The supported values are `address` (crypto-wallet-based gating) or `SSIpolicy` (decentralized enterprise identity profiles). |
| `values` | `Array of Objects` | Contains the operational parameters and settings assigned to the specific rule type. |
| `allow[].values[].address` | `String` | Used when type is `address`. Denotes the explicit blockchain wallet address allowed to see the asset. A value of `*` serves as a wildcard, permitting any connected wallet. |
| `allow[].values[].vc_policies` | `Array of Strings` | Global Verifiable Credential Baselines. Security audits enforced automatically across *every* submitted credential, such as checking the digital `signature` or ensuring the timeline is valid via `not-before`. |
| `allow[].values[].vp_policies` | `Array of Objects` |
This field is present only in the asset-level credentials object. Verifiable Presentation (VP) Bundle Rules. Rules dictating how the overall collection of credentials must behave together, such as enforcing anti-spoofing (holder-binding) or setting a minimum number of valid matching certificates (minimum-credentials).
|
| `allow[].values[].request_credentials` | `Array of Objects` | Used when type is `SSIpolicy`. Outlines the precise digital verifiable credentials the user must present from their corporate identity wallet (e.g., corporate registry records). |
| `allow[].values[].request_credentials[].type` | `String` | The specific schema or classification of the requested certificate, such as `gx:LegalPerson` (company profile) or `gx:LeiCode` (Legal Entity Identifier). |
| `allow[].values[].request_credentials[].format` | `String` | The technical data format of the credential package being checked (e.g., `jwt_vc_json`). |
| `allow[].values[].request_credentials[].policies` | `Array of Strings or Objects` | Targeted validation checks applied to that specific credential. Can range from a simple validity check like `expired` to complex dynamic rules containing parameters and evaluation servers. |
Example of an asset-level allow object. The following access credentials are defined for the asset:
* access allowed to any web3 address (field `credentials.allow[{"type":"address"}].values[0].address = "*"`)
* access allowed to any consumer who presents the following VCs (the fields `credentials.allow[{"type":"SSIpolicy"}].values[0].request_credentials[].type`):
* gx:LegalPerson
* gx:Issuer
* gx:LeiCode
* all VCs have to comply with the following static policies (the field `credentials.allow[{"type":"SSIpolicy"}].values[0].vc_policies[]`)
* not-before: VC is not used before its validity start date
* revoked-status-list: VC is not revoked
* signature: VC has a valid signature
* the Verifiable Presentation (VP) in which the VCs are packed before submission to verification must comply with the following policies (the field `credentials.allow[{"type":"SSIpolicy"}].values[0].vp_policies[]`):
* holder-binding: the identifier that signs the VP must be the subject of each VC included in the VP
* minimum-credentials: a minimum of two VCs must be included in the VP
* vp\_required\_credentials: the VP must include gx:LegalPerson VC and optionally one of the following VCs: gx:LeiCode and gx:Issuer
* the gx:LegalPerson VC must comply with the following policy (`credentials.allow[{"type":"SSIpolicy"}].values[0].request_credential[0].policies[]`):
* expired: the VC has not expired
* the gx:Issuer VC must comply with the following policy (`credentials.allow[{"type":"SSIpolicy"}].values[0].request_credential[1].policies[]`)
* allowed-issues: the VC must be issued by the entity identified by did:GXCH
* the gx:LeiCode VC must comply with the following policy (`credentials.allow[{"type":"SSIpolicy"}].values[0].request_credential[1].policies[]`):
* a dynamic policy named countryGermany
* the dynamic policy verifies if the field gx:countryCode of the VC has the value "DE"
```json
"credentials": {
"allow": [
{
"type": "SSIpolicy",
"values": [
{
"request_credentials": [
{
"format": "jwt_vc_json",
"policies": [
"expired"
],
"type": "gx:LegalPerson"
},
{
"format": "jwt_vc_json",
"policies": [
{
"policy": "allowed-issuer",
"args": [
"did:GXCH"
]
}
],
"type": "gx:Issuer"
},
{
"format": "jwt_vc_json",
"policies": [
{
"policy": "dynamic",
"args": {
"policy_name": "countryGermany",
"opa_server": "http://ocean-node-vm3.oceanenterprise.io:8181",
"policy_query": "data",
"rules": {
"rego": "package data.countryGermany\n\ndefault allow := false\n\nallow if {\n lower(input.credentialData.credentialSubject[\"gx:countryCode\"]) == lower(input.parameter.param1)\n}"
},
"argument": {
"param1": "DE"
}
}
}
],
"type": "gx:LeiCode"
}
],
"vc_policies": [
"not-before",
"revoked-status-list",
"signature"
],
"vp_policies": [
{
"policy": "holder-binding"
},
{
"policy": "minimum-credentials",
"args": "2"
},
{
"policy": "vp_required_credentials",
"args": "{\"required\":[{\"credential_type\":\"gx:LegalPerson\"},{\"any_of\":[\"gx:LeiCode\",\"gx:Issuer\"]}]}"
}
]
}
]
},
{
"type": "address",
"values": [
{
"address": "*"
}
]
}
],
"deny": [],
"match_deny": "any"
}
```
#### Deny
| Attribute | Type | Description |
| ------------------ | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `type` | `String` | Specifies the security mechanism used for evaluation. Currently, the only accepted value is `address` |
| `values` | `Array of objects` | The list of web3 addresses that are restricted to access the asset/service. |
| `values[].address` | `String` | The web3 address restricteed to access the asset/service (e.g "`0xd727fb9be39fa019d7c02fea19e54d688da3a662`" - specific address; `"*"` - all addresses). |
Example of a deny object where two web3 addresses are restricted from accessing the asset/service.
```json
"deny": [
{
"type": "address",
"values": [
{
"address": "0xd727fb9be39fa019d7c02fea19e54d688da3a662"
},
{
"address": "0x61db12d8b636cb49ea09eca58a893da9480e1f33"
}
]
}
],
"match_deny": "any"
```
Example of a deny object where all addresses are restricted from accessing the asset/service.
```json
"deny": [
{
"type": "address",
"values": [
{
"address": "*"
}
]
}
],
"match_deny": "any"
```
## Examples of DDOs
### Dataset with two services
The asset is of type `dataset` and has two services of type `download` : "Service 1" and "Service 2"
{% code overflow="wrap" %}
```json
{
"@context": [
"https://www.w3.org/ns/credentials/v2"
],
"id": "did:ope:7752f58eece2711f16a0a2cd2d4490dcbde06c440386170f0881c9151b9f478c",
"version": "5.0.0",
"credentialSubject": {
"chainId": 11155111,
"metadata": {
"created": "2026-06-23T05:39:40Z",
"updated": "2026-06-23T06:08:24.287Z",
"type": "dataset",
"name": "publish with signer server updated",
"description": {
"@value": "this is a publishhh updated",
"@direction": "ltr",
"@language": "en"
},
"tags": [],
"author": "",
"license": {
"name": "https://microsoftedge.github.io/Demos/json-dummy-data/64KB.json",
"licenseDocuments": [
{
"sha256": "cde3fa1e4696435fb274304f710742f67bc4b810fd7ee850543d162f3e10aa70",
"mirrors": [
{
"method": "get",
"type": "url",
"url": "https://microsoftedge.github.io/Demos/json-dummy-data/64KB.json"
}
],
"name": "https://microsoftedge.github.io/Demos/json-dummy-data/64KB.json",
"fileType": "application/json; charset=utf-8"
}
]
},
"additionalInformation": {
"termsAndConditions": true
},
"copyrightHolder": "",
"providedBy": "",
"links": {}
},
"services": [
{
"credentials": {
"allow": [
{
"values": [
{
"address": "*"
}
],
"type": "address"
}
],
"match_deny": "any",
"deny": []
},
"name": "Service 1",
"files": "0x0471e141a36eb191e13122b3aeeefb9ae4ead2be502a411895a7e02aa462e7a0013eb887e0f0a2252f156956c22c57d75c25bf4832506f6e174194323e7876505c0cdd9d0d1d3eb9e3644821e163c7f04c3101b893a96499a28df3b436af3780c0f9c964ff11aa748852837cff27308839bba4ad98befdcb91d0f8523bb7ebcf720856070d6d9d077553f39961e75071710bb3260ec50f4df793b825b703145936a7c28f0f80fdbb9d00ab79efd0e4870686087eef02aeac1f7e0cac197ebe4290b3799d1e77c35a95276699d1047435ccb148e1499d8b60f8e76f2e82eb90e4f90c0cdb469785c30dbda2c3440a21a02e26937143787d2b7b639e0467dbf44e1609b9a8c908610f3529014315b5516765769cdf6f19fcd4700ee91a175426bd245b269e365474b09a33d9f1a509fee148744b07a02ad6566e3a06bf59cc86c7fe8b872692d232b34f1dd298ba4e036f0feccae79d0c8cb2dd82e493d9778f790500a5",
"description": {
"@value": "This is a desc",
"@direction": "ltr",
"@language": "en"
},
"id": "3576f9a8dfd718e8f6ec238433547ca71c6da23259d6fba36712ee3604188d17",
"datatokenAddress": "0xa5b318dfb75B2f24a87d36791E378761B2174B11",
"serviceEndpoint": "https://ocean-node-vm3.oceanenterprise.io",
"state": 0,
"type": "access",
"timeout": 0
},
{
"credentials": {
"allow": [],
"match_deny": "any",
"deny": []
},
"name": "Service 2",
"description": {
"@value": "Service 2 description",
"@direction": "ltr",
"@language": "en"
},
"files": "0x047653de07d08d316bd10330bcc9ca42d5f3311f08d0e2e6a32931977f719f63be5ac816726ad0ce64628a4bd0f1b09b232d73afbf0274f39ec40ab58f6c938e52a8dbaa4a5d9197f4ae341e247de22736cb440e660ca5f1ea007ae96ad35b05975c0a5131bf2929658daa97bd86c5a04acb6cf2a020b328c59215b773cf5e0b11eea797b96547c96537327db7b41b207e6243039da87f8ed160aca0dc1dd9e879c63c83cb2d699942340c75f64d7cd71c6142ad28ff8a0dbc407d7541c4918e1d5a35b424c7aaf4039953ff56209763f98be0724d97c281e5ecaf6e8dbb9f4837bd87ce4dbb38144c6ec14df95acb42185df2911b9ffb7e3fd4aa7500ccfa2cc1b52ac045322888a500a97bf6e1adb57cece0c69e25d7818df0f2601792128874d6fca4d4032c7ce88ba869c09f0ed6c3b7f7bfbb11051db7f5182bbc6f556a7bb59820e55b9d79085ea618c87fa413166197ecf269c3dfb9a1b765d55f3f7e4cdf43",
"id": "c052e00890d7f37585be1fa4f39923181fcb3a24872aca9e5c09973534dd3c45",
"datatokenAddress": "0x9025391B26B38fEd0c4feBaE777Fd0633F4d6a5f",
"serviceEndpoint": "https://ocean-node-vm3.oceanenterprise.io",
"state": 0,
"type": "access",
"timeout": 86400
}
],
"nftAddress": "0x7090Eb5346929DdFaAac17d267a5d344381b19cB",
"credentials": {
"allow": [
{
"values": [
{
"address": "*"
}
],
"type": "address"
}
],
"deny": [],
"match_deny": "any"
},
"stats": {
"allocated": 0,
"orders": 0,
"price": {
"value": 1,
"tokenSymbol": "USDC",
"tokenAddress": "0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238"
}
},
"datatokens": [
{
"symbol": "OEAT",
"address": "0xa5b318dfb75B2f24a87d36791E378761B2174B11",
"name": "Access Token",
"serviceId": "3576f9a8dfd718e8f6ec238433547ca71c6da23259d6fba36712ee3604188d17"
},
{
"symbol": "OEAT",
"address": "0x9025391B26B38fEd0c4feBaE777Fd0633F4d6a5f",
"name": "Access Token",
"serviceId": "c052e00890d7f37585be1fa4f39923181fcb3a24872aca9e5c09973534dd3c45"
}
]
},
"additionalDdos": [],
"type": [
"VerifiableCredential"
],
"issuer": "did:web:wallet2.demo.oceanenterprise.io:wallet-api:registry:OEdid",
"proof": {
"signature": "iyRgl1AaFKjyCwY4c0rCw9M67OVwOXKkKUpOD2tgN_qws3o260-oQxGA5kzKsNOwnpSClxTlNFoUWCrmx-9r7A",
"header": {
"kid": "7r1KFbygYbFTCVj2xK1wLvimt73LgxZDO__SOPx0w_A",
"typ": "JWT",
"alg": "ES256K"
}
},
"indexedMetadata": {
"stats": [
{
"symbol": "OEAT",
"name": "Access Token",
"orders": 0,
"datatokenAddress": "0xa5b318dfb75B2f24a87d36791E378761B2174B11",
"serviceId": "3576f9a8dfd718e8f6ec238433547ca71c6da23259d6fba36712ee3604188d17",
"prices": [
{
"exchangeId": "0x6bd9c49449350aaa653dfe8c780760b6d5c456d31bdcaefdd0d6a7390b3d4107",
"price": "1.0",
"contract": "0xfa48673a7C36A2A768f89AC1ee8C355D5c367B02",
"type": "fixedrate",
"token": "0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238"
}
]
},
{
"symbol": "OEAT",
"name": "Access Token",
"orders": 0,
"datatokenAddress": "0x9025391B26B38fEd0c4feBaE777Fd0633F4d6a5f",
"serviceId": "c052e00890d7f37585be1fa4f39923181fcb3a24872aca9e5c09973534dd3c45",
"prices": [
{
"exchangeId": "0xeab62d1ac355b547cd05a907987c201a7024cc3aeb71c7041fb4c37ae85335b5",
"price": "1.0",
"contract": "0xfa48673a7C36A2A768f89AC1ee8C355D5c367B02",
"type": "fixedrate",
"token": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4"
}
]
}
],
"nft": {
"state": 0,
"address": "0x7090Eb5346929DdFaAac17d267a5d344381b19cB",
"name": "Data NFT",
"symbol": "OEC-NFT",
"owner": "0xcF3185a502bE4b5Eb2c4Eb81646ECf7Dd0aC2f22",
"created": "2026-06-23T06:09:24Z",
"tokenURI": ""
},
"event": {
"txid": "0x2cfb222c4ef199bcd8b113126e21d598fe91d840ad296493daaedc1c2eace272",
"from": "0xcF3185a502bE4b5Eb2c4Eb81646ECf7Dd0aC2f22",
"contract": "0x7090Eb5346929DdFaAac17d267a5d344381b19cB",
"block": 11121002,
"datetime": "2026-06-23T06:09:24.000Z"
},
"purgatory": {
"state": false
}
},
"accessDetails": [
{
"type": "fixed",
"price": "1.0",
"addressOrId": "0x6bd9c49449350aaa653dfe8c780760b6d5c456d31bdcaefdd0d6a7390b3d4107",
"baseToken": {
"address": "0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238",
"name": "USDC",
"symbol": "USDC",
"decimals": 6
},
"datatoken": {
"address": "0xa5b318dfb75B2f24a87d36791E378761B2174B11",
"name": "Access Token",
"symbol": "OEAT",
"decimals": 0
},
"paymentCollector": "0xcF3185a502bE4b5Eb2c4Eb81646ECf7Dd0aC2f22",
"templateId": 2,
"isOwned": false,
"validOrderTx": "",
"isPurchasable": true,
"publisherMarketOrderFee": "0"
},
{
"type": "fixed",
"price": "1.0",
"addressOrId": "0xeab62d1ac355b547cd05a907987c201a7024cc3aeb71c7041fb4c37ae85335b5",
"baseToken": {
"address": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4",
"name": "EURC",
"symbol": "EURC",
"decimals": 6
},
"datatoken": {
"address": "0x9025391B26B38fEd0c4feBaE777Fd0633F4d6a5f",
"name": "Access Token",
"symbol": "OEAT",
"decimals": 0
},
"paymentCollector": "0xcF3185a502bE4b5Eb2c4Eb81646ECf7Dd0aC2f22",
"templateId": 2,
"isOwned": false,
"validOrderTx": "",
"isPurchasable": true,
"publisherMarketOrderFee": "0"
}
]
}
```
{% endcode %}
### Dataset for computing with allowed algorithms and allowed algorithm publishers defined
The asset is of type `dataset` and has a service of type `compute`. The service accepts only a list of algorithms (identified by did and serviceID in the field `publisherTrustedAlgorithms`) and algorithm publishers (identified by web3 address in field `publisherTrustedAlgorithmPublishers`)
{% code overflow="wrap" %}
```json
{
"@context": [
"https://www.w3.org/ns/credentials/v2"
],
"id": "did:ope:ea37bfdf3c3d5ad57777db56ffbc1004a4f0f0a297731f37437e5e9d0921cd86",
"version": "5.0.0",
"credentialSubject": {
"chainId": 11155111,
"metadata": {
"created": "2026-06-25T13:19:52Z",
"updated": "2026-06-25T13:19:52Z",
"type": "dataset",
"name": "Test dataset - allowedAlgorithms and AllowedAlgorithmPublishers - 1",
"description": {
"@value": "Test dataset - allowedAlgorithms and AllowedAlgorithmPublishers - 1",
"@direction": "ltr",
"@language": "en"
},
"tags": [],
"author": "",
"license": {
"name": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf",
"licenseDocuments": [
{
"name": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf",
"fileType": "text/html; charset=utf-8",
"sha256": "79fc7fd736c48aa7fc18297e8dd5d54631b4f790331b7f4bcc9149081171a3ab",
"additionalInformation": {
"size": 224570
},
"displayName": {
"@value": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf",
"@language": "en",
"@direction": "ltr"
},
"description": {
"@value": "",
"@language": "en",
"@direction": "ltr"
},
"mirrors": [
{
"type": "url",
"method": "get",
"url": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf"
}
]
}
]
},
"additionalInformation": {
"termsAndConditions": true
},
"copyrightHolder": "",
"providedBy": ""
},
"services": [
{
"id": "a10c08a31657421035f258968c6fb49ffe7bc23e69bafdd319f559dd9421ae3d",
"type": "compute",
"files": "0x04e905d53f1b9e7709c86d5e13391231a5341b16767fccf0dc88b417611edd217dd3bdb044bfda29df46c05b5f80ef18315d5f56f98248cdd757b8f2015ac0164570ba0d879cd208ce4092d679b259580a99224b66adb0f1b2e7291e155d36bf04638954b11bbbc27645d8a16926f30d0073ce7f077bc2be80e4d0a1ff386b0778a05a48801189922df7fe4a47456324bc46b5ec876c3bfd3277e283126b4b5e3d22fead62a43d8653f045e7ed77c366df43694552f95d3a8e906a24d94a0f74034dd491cc15f0aceb4b5049953ad813c92cd89dacbbf0cd6638dfc3d131b6ba9c89eeb4bc341199f7bfd60d702ea0af2818adaa61196e85ca2603b05f06ce33e69b999f5cdbc967054d6f1b0544e9b0f2907aa1a0cdf41eae5dc1fa2ebea7b15ce43c70fac6b54203529c9a453efdf661dd1eeb671166562a7a869483a63c372dff4815f8e095fc73356fe4d51e7494b0d8ffde79787880c0aeb4991ffb9cac103e9daffa518a2e4fcea4e553e374984d76d460c9fd2ae95d",
"datatokenAddress": "0x37300E09cb7543F09B7E4a0DBE219aDE2cEd582d",
"serviceEndpoint": "https://ocean-node-vm3.oceanenterprise.io",
"timeout": 86400,
"compute": {
"allowRawAlgorithm": false,
"allowNetworkAccess": true,
"publisherTrustedAlgorithmPublishers": [
"0xd727fb9be39fa019d7c02fea19e54d688da3a662",
"0x61db12d8b636cb49ea09eca58a893da9480e1f33"
],
"publisherTrustedAlgorithms": [
{
"did": "did:ope:c68e6efe498f70cf0d671f9a405374176607d209546837e25b11cedbbcc9cd02",
"containerSectionChecksum": "ee2da20f61e82ced3033ad6a7cb44fe136d91b715eaf2db2811ee0b0ad4a5b99",
"filesChecksum": "2c36c054711dad021f45cc7e0990bd38864a51d753c8055b63e78014a6bee515",
"serviceId": "4d89d718fc670b20217d97466e9612244e82aad21a40d19738d2a6ed0e3e8893"
},
{
"did": "did:ope:c534e37e815b267d229c7051086f17c084ab72dce41af12df6f6daf900b30b16",
"containerSectionChecksum": "2ea683746c6927342c7ea51ddd9b8acada2490c67a357ff9b41bda64fe05cb34",
"filesChecksum": "dc0b0c89639614533fecd6ebe7dc53dcfbda96865322213dea7c3ecf88ad7ea4",
"serviceId": "ae2367882fa6d10c006dcce30b4a2bdd70434f8348c0ed6431f2125b572b12f4"
},
{
"did": "did:ope:b66c9ccce1b117711918ba1232e70d99c75e52a68a88a13639eed3a8450c41f8",
"containerSectionChecksum": "dfce591ecb9b35c1c2931c8b38b4c216a61b40cd33407ab886df3b44c6b8904d",
"filesChecksum": "ffd8c9b460451dd7d1677878f60cc93ce35a5a2517f08819761c0ddf424f7f88",
"serviceId": "40c3fefb7b73c1a3190a437227d1954f8ef682676e26c1a914668f2d05401d22"
}
]
},
"name": "Service 1 ",
"description": {
"@value": "Service 1 desc",
"@direction": "ltr",
"@language": "en"
},
"state": 0,
"credentials": {
"allow": [],
"deny": [],
"match_deny": "any"
}
}
],
"nftAddress": "0xB92b1B08247A912c68d564010e1eeE3E01760eBE",
"credentials": {
"allow": [
{
"type": "address",
"values": [
{
"address": "*"
}
]
}
],
"deny": [],
"match_deny": "any"
},
"stats": {
"allocated": 0,
"orders": 0,
"price": {
"value": 1,
"tokenSymbol": "EURC",
"tokenAddress": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4"
}
},
"datatokens": [
{
"address": "0x37300E09cb7543F09B7E4a0DBE219aDE2cEd582d",
"name": "Access Token",
"symbol": "OEAT",
"serviceId": "a10c08a31657421035f258968c6fb49ffe7bc23e69bafdd319f559dd9421ae3d"
}
]
},
"additionalDdos": [],
"type": [
"VerifiableCredential"
],
"issuer": "did:web:wallet2.demo.oceanenterprise.io:wallet-api:registry:publisher132",
"proof": {
"signature": "renUR-IRTGeCo_PJTwdJiO0X-h3xPj8H2XQNfG2oOYPezL9VQmhimp0ltWa_Itv9fqFULskf6Vt670Kj1iWkJA",
"header": {
"kid": "CqCLEltKrojmVXvWPApMYIbTupHhxI6dFwdJ8d2HUrk",
"typ": "JWT",
"alg": "ES256"
}
},
"indexedMetadata": {
"stats": [
{
"datatokenAddress": "0x37300E09cb7543F09B7E4a0DBE219aDE2cEd582d",
"name": "Access Token",
"symbol": "OEAT",
"serviceId": "a10c08a31657421035f258968c6fb49ffe7bc23e69bafdd319f559dd9421ae3d",
"orders": 0,
"prices": [
{
"type": "fixedrate",
"price": "1.0",
"token": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4",
"contract": "0xfa48673a7C36A2A768f89AC1ee8C355D5c367B02",
"exchangeId": "0x79f8250202522028c0c1a26e9acf6c86c0fdeda096017c4b48a429fc7cdec58b"
}
]
}
],
"nft": {
"state": 0,
"address": "0xB92b1B08247A912c68d564010e1eeE3E01760eBE",
"name": "Data NFT",
"symbol": "OEC-NFT",
"owner": "0x00Dc9e712D3b31Ab5446A5A7CeaDe0a2901E6d26",
"created": "2026-06-25T13:20:24Z",
"tokenURI": ""
},
"event": {
"txid": "0x7be6d1da632039b5e04c73ba813700458b2adf51ecb1c60c45e138b42aea3edd",
"from": "0x00Dc9e712D3b31Ab5446A5A7CeaDe0a2901E6d26",
"contract": "0xB92b1B08247A912c68d564010e1eeE3E01760eBE",
"block": 11136986,
"datetime": "2026-06-25T13:20:24.000Z"
},
"purgatory": {
"state": false
}
},
"accessDetails": [
{
"type": "fixed",
"price": "1.0",
"addressOrId": "0x79f8250202522028c0c1a26e9acf6c86c0fdeda096017c4b48a429fc7cdec58b",
"baseToken": {
"address": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4",
"name": "EURC",
"symbol": "EURC",
"decimals": 6
},
"datatoken": {
"address": "0x37300E09cb7543F09B7E4a0DBE219aDE2cEd582d",
"name": "Access Token",
"symbol": "OEAT",
"decimals": 0
},
"paymentCollector": "0x00Dc9e712D3b31Ab5446A5A7CeaDe0a2901E6d26",
"templateId": 2,
"isOwned": false,
"validOrderTx": "",
"isPurchasable": true,
"publisherMarketOrderFee": "0"
}
]
}
```
{% endcode %}
### Dataset with SSI credentials
The dataset has a service of type access. SSI access credentials are defined at both the asset level (`credentialSubject.credentials field`) and service level (`credentialsSubject.services[0].credentials field`).
{% code overflow="wrap" %}
```json
{
"@context": [
"https://www.w3.org/ns/credentials/v2"
],
"id": "did:ope:adb0746adc797cbf9bf72e65bd4c3107de67e33940624e473be21418ee387b03",
"version": "5.0.0",
"credentialSubject": {
"chainId": 11155111,
"metadata": {
"created": "2026-06-26T09:54:54Z",
"updated": "2026-06-26T09:54:54Z",
"type": "dataset",
"name": "test dataset - credentials - 1",
"description": {
"@value": "test dataset - credentials - 1",
"@direction": "ltr",
"@language": "en"
},
"tags": [],
"author": "",
"license": {
"name": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf",
"licenseDocuments": [
{
"name": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf",
"fileType": "text/html; charset=utf-8",
"sha256": "33f1b2a911308034b4d5aba53a197ddc51102c774002b45034e342fdc17598e9",
"additionalInformation": {
"size": 224919
},
"displayName": {
"@value": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf",
"@language": "en",
"@direction": "ltr"
},
"description": {
"@value": "",
"@language": "en",
"@direction": "ltr"
},
"mirrors": [
{
"type": "url",
"method": "get",
"url": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf"
}
]
}
]
},
"additionalInformation": {
"termsAndConditions": true
},
"copyrightHolder": "",
"providedBy": ""
},
"services": [
{
"id": "ae7883d0ea3d8f95db7b2e56d2397868d2320f6527bc6196fea4447884c15d7d",
"type": "access",
"files": "0x04941434fb61204e63121271fb0b3e036aa52b821b6b9dbdd7c1818bcc729f60fc5523de16c74b6ad543293a8f33a20b0d3a00d8ff4ad17d0a08fd61dcd66c76e746f6d8db1f8571ce31944c67fa46ccc247eaf230f25e200147f3f055f936298e7134523bdb46fa0875b1787c0a8476931005cee788a7206187ab01989176996389d2602ec28dae05d4499ae03a604335d96444074b0e7ae56e82b0f8c24a0db069c6ec6517eb062594e3e63003085197af2bcb1c0b0095131bcbd2393f5650ccf8a2e864a64ec5d90d1a6e09352d2bbfd87170c72693ecac4c9b735b409f05504477f4f8b659df0af854fa5f264b376e2ef816a5890fe172ad19ddd2b54f6484ed19d7b3040aa18d97c0e4e53aeaa21199164a5539425e2e1fe0cb3022f595e60b684499ad40d748b9d23ffab7a9c1a9992f0f8e731c0f1daf2518c68bb10a00a14727549e8ab7fdecf2cce445ae45ad691c76ec37afc9db2e95eee8f155f6bc81bb5efee2f5a774768b9ede84921050a689baa3f34d0b51",
"datatokenAddress": "0xeEaB3064435c7710e7637d50c26A4Cb365E753B0",
"serviceEndpoint": "https://ocean-node-vm3.oceanenterprise.io",
"timeout": 86400,
"name": "Service 1 ",
"description": {
"@value": "Service 1 desc",
"@direction": "ltr",
"@language": "en"
},
"state": 0,
"credentials": {
"allow": [
{
"type": "SSIpolicy",
"values": [
{
"request_credentials": [
{
"format": "jwt_vc_json",
"policies": [
{
"policy": "dynamic",
"args": {
"policy_name": "companyId",
"opa_server": "http://ocean-node-vm3.oceanenterprise.io:8181",
"policy_query": "data",
"rules": {
"rego": "package data.companyId\n\ndefault allow := false\n\nallow if {\n lower(input.credentialData.credentialSubject[\"gx:vatID\"]) == lower(input.parameter.param1)\n}"
},
"argument": {
"param1": "12345678"
}
}
}
],
"type": "gx:VatID"
}
]
}
]
},
{
"type": "address",
"values": [
{
"address": "*"
}
]
}
],
"deny": [],
"match_deny": "any"
}
}
],
"nftAddress": "0x4C918c866ba6399090711B47Cd07110E4aF886Aa",
"credentials": {
"allow": [
{
"type": "SSIpolicy",
"values": [
{
"request_credentials": [
{
"format": "jwt_vc_json",
"policies": [
"expired"
],
"type": "gx:LegalPerson"
},
{
"format": "jwt_vc_json",
"policies": [
{
"policy": "allowed-issuer",
"args": [
"did:GXCH"
]
}
],
"type": "gx:Issuer"
},
{
"format": "jwt_vc_json",
"policies": [
{
"policy": "dynamic",
"args": {
"policy_name": "countryGermany",
"opa_server": "http://ocean-node-vm3.oceanenterprise.io:8181",
"policy_query": "data",
"rules": {
"rego": "package data.countryGermany\n\ndefault allow := false\n\nallow if {\n lower(input.credentialData.credentialSubject[\"gx:countryCode\"]) == lower(input.parameter.param1)\n}"
},
"argument": {
"param1": "DE"
}
}
}
],
"type": "gx:LeiCode"
}
],
"vc_policies": [
"not-before",
"revoked-status-list",
"signature"
],
"vp_policies": [
{
"policy": "holder-binding"
},
{
"policy": "presentation-definition"
},
{
"policy": "minimum-credentials",
"args": "2"
},
{
"policy": "vp_required_credentials",
"args": "{\"required\":[{\"credential_type\":\"gx:LegalPerson\"},{\"any_of\":[\"gx:LeiCode\",\"gx:Issuer\"]}]}"
}
]
}
]
},
{
"type": "address",
"values": [
{
"address": "*"
}
]
}
],
"deny": [],
"match_deny": "any"
},
"stats": {
"allocated": 0,
"orders": 0,
"price": {
"value": 1,
"tokenSymbol": "EURC",
"tokenAddress": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4"
}
},
"datatokens": [
{
"address": "0xeEaB3064435c7710e7637d50c26A4Cb365E753B0",
"name": "Access Token",
"symbol": "OEAT",
"serviceId": "ae7883d0ea3d8f95db7b2e56d2397868d2320f6527bc6196fea4447884c15d7d"
}
]
},
"additionalDdos": [],
"type": [
"VerifiableCredential"
],
"issuer": "did:web:wallet2.demo.oceanenterprise.io:wallet-api:registry:publisher132",
"proof": {
"signature": "An0ocY932YWWM3NaDdyTmnERHkPkIp-Hqpl_EZOu80xNAScDXnyk38mqgUyrigTgiJMdyc75GxzpZYQAzjxe-w",
"header": {
"kid": "6fvEXSWtuRtxIKQtezO8wWW3EyEj4ouvSZripxo8J1U",
"typ": "JWT",
"alg": "ES256"
}
},
"indexedMetadata": {
"stats": [
{
"datatokenAddress": "0xeEaB3064435c7710e7637d50c26A4Cb365E753B0",
"name": "Access Token",
"symbol": "OEAT",
"serviceId": "ae7883d0ea3d8f95db7b2e56d2397868d2320f6527bc6196fea4447884c15d7d",
"orders": 0,
"prices": [
{
"type": "fixedrate",
"price": "1.0",
"token": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4",
"contract": "0xfa48673a7C36A2A768f89AC1ee8C355D5c367B02",
"exchangeId": "0xb3ae790b58d0168f3735cad5c93931966600964853175667b501fcd18f968d37"
}
]
}
],
"nft": {
"state": 0,
"address": "0x4C918c866ba6399090711B47Cd07110E4aF886Aa",
"name": "Data NFT",
"symbol": "OEC-NFT",
"owner": "0x00Dc9e712D3b31Ab5446A5A7CeaDe0a2901E6d26",
"created": "2026-06-26T09:56:00Z",
"tokenURI": ""
},
"event": {
"txid": "0x9c01d538f1cee7d00f5bae0582ecf5f533180f821671424fcde895f1abf06fdd",
"from": "0x00Dc9e712D3b31Ab5446A5A7CeaDe0a2901E6d26",
"contract": "0x4C918c866ba6399090711B47Cd07110E4aF886Aa",
"block": 11143144,
"datetime": "2026-06-26T09:56:00.000Z"
},
"purgatory": {
"state": false
}
},
"accessDetails": [
{
"type": "fixed",
"price": "1.0",
"addressOrId": "0xb3ae790b58d0168f3735cad5c93931966600964853175667b501fcd18f968d37",
"baseToken": {
"address": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4",
"name": "EURC",
"symbol": "EURC",
"decimals": 6
},
"datatoken": {
"address": "0xeEaB3064435c7710e7637d50c26A4Cb365E753B0",
"name": "Access Token",
"symbol": "OEAT",
"decimals": 0
},
"paymentCollector": "0x00Dc9e712D3b31Ab5446A5A7CeaDe0a2901E6d26",
"templateId": 2,
"isOwned": false,
"validOrderTx": "",
"isPurchasable": true,
"publisherMarketOrderFee": "0"
}
]
}
```
{% endcode %}
### Algorithm for computing
The asset is of type algorithm. It has two services - Algo 1 and Algo 2 - both usable only in a compute-to-data environment (`credentialSubject.services[].type` is `"compute"`).
The algorithms provided by Algo 1 and Algo 2 are written in JavaScript (`credentialSubject.algorithm.language` is `"js"`) and use the latest node.js image (`credentialSubject.algorithm.container.image` is `"node"`, `credentialSubject.algorithm.container.tag`is `"latest"`).
The asset allows network access when the algorithms are executed in a C2D environment (`credentialSubject.services[].compute.allowNetworkAccess` is `true`).
{% code overflow="wrap" %}
```json
{
"@context": [
"https://www.w3.org/ns/credentials/v2"
],
"id": "did:ope:c534e37e815b267d229c7051086f17c084ab72dce41af12df6f6daf900b30b16",
"version": "5.0.0",
"credentialSubject": {
"chainId": 11155111,
"metadata": {
"created": "2026-06-23T10:38:04Z",
"updated": "2026-06-24T09:37:29.998Z",
"type": "algorithm",
"name": "Test algo - cookies - SSI - C2D - 3",
"description": {
"@value": "Test algo - cookies - SSI - C2D - 3",
"@direction": "ltr",
"@language": "en"
},
"tags": [],
"author": "",
"license": {
"name": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf",
"licenseDocuments": [
{
"additionalInformation": {
"size": 224420
},
"sha256": "87b7148db85eb00fdb4e657827519d323be4b260c0264202638864d6f54a3731",
"mirrors": [
{
"method": "get",
"type": "url",
"url": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf"
}
],
"displayName": {
"@value": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf",
"@direction": "ltr",
"@language": "en"
},
"name": "https://github.com/MBadea17/testdata/blob/af26d4f968fdb6e1882c2a3cca16a1480ca44a9c/License%20Agreement.pdf",
"description": {
"@value": "",
"@direction": "ltr",
"@language": "en"
},
"fileType": "text/html; charset=utf-8"
}
]
},
"additionalInformation": {
"termsAndConditions": true
},
"algorithm": {
"language": "js",
"version": "0.1",
"container": {
"entrypoint": "node $ALGO",
"image": "node",
"tag": "latest",
"checksum": "sha256:d402fe9c95ecdcd8adb4a4125c032b40e6753a0a7c7cc74a659e7b0a90ef83ce"
}
},
"copyrightHolder": "",
"providedBy": ""
},
"services": [
{
"compute": {
"publisherTrustedAlgorithms": [
{
"filesChecksum": "*",
"containerSectionChecksum": "*",
"serviceId": "*",
"did": "*"
}
],
"publisherTrustedAlgorithmPublishers": [
"*"
],
"allowRawAlgorithm": false,
"allowNetworkAccess": true
},
"credentials": {
"allow": [],
"match_deny": "any",
"deny": []
},
"name": "Algo 1 ",
"files": "0x040dbdf3d97493316012ced90ae27ab1a6a549328dbfece81ef68fc50b7bea540afb6d40253a42db8dabbca327c039eb211e4fa6c8ceddd92e4e532f1f8b190619b939355e92e29c033314794fb4eede45fc3cff206ca450883ae6e43c3b5ebe9174cc741cb7a7e4118fe06824a1bf4fa708c8a75ce2ce325ecb1acc9e42def0f42bacc4afdedec734a4880e8e9f376f4a712787d3f8326ad3e9fc1e68844bebbf766156022ca3dcc3f52e327fb4468ab6a8ac6747cd0644bf5bce371ed65d3f8b8d1da612343dd854ce7f1093f0c9792be583698694099771aa6f7d1f3641a69299af42a644823b9f903bf7dc9feb7e50d552c2b8925d4214b576bade2a4db8dfdca58bf12550e6b358a82089152cc00ed16e8ed71220f45e79dcf3a32f91a70c7bde54f11c5773d0a4505dd0373fb3c0184816bedd90f40d324f27f12f4702774fb997b8d1bfd1ef32a5d9577cc9f0d3f1372aa1559af371e756b5acb971b3ec055408c1af80c99d2ff0ca22c5a636d4e692ab7bc8b9",
"description": {
"@value": "Algo 1 Algo 1 Algo 1 ",
"@direction": "ltr",
"@language": "en"
},
"id": "9b551945221a471a809695ede021c4d27db7d359a6ff3f413a1de8fd201d980e",
"datatokenAddress": "0x240E8715Abb05594331002ED3ECAA9a656ED5757",
"serviceEndpoint": "https://ocean-node-vm3.oceanenterprise.io",
"state": 0,
"type": "compute",
"timeout": 86400
},
{
"credentials": {
"allow": [],
"match_deny": "any",
"deny": []
},
"name": "Algo 2",
"description": {
"@value": "Algo 2 description",
"@direction": "ltr",
"@language": "en"
},
"files": "0x04958b4d8dfdf784b7aa9a31d1fad9ff50d776981ef683ebb65215c5c450d673ab0bf16991723bc776bd037d91eaeb97b41949f5f0e3b8c041cc0ce131b70e01a36975c161e0a2bc81edc966a031e42cd672f7718e5a37d41a2a7c05a453a1ec6239d121107d73a1d4aa478dc707b3d243c39e65df02d5cd8b009331a45f4454c9c6687bad80ba1112a89c797fb88ec58c3416b51b5888c8722b33b394f7ff17640c7648edbdcc065e78c004fcb1f00a44d57b55ae0748182a4b9e050e756ede3b0ef74dd073e65b96b2d78244d18358568790dc4ed756965833d92ffe29fdef2a555476a20937f9f68ee1c4eadcdfab91965a8be4e88ad90963b354837fbf7178c0c2400e42c1ebbcf7f21487ce01105eabe0ef9c63494e81e2ce5a35051ab43b39050af8ed839a204b5cb024ecf085f51195880b5dd04da59c0998dd0decf2c07108bdfa0acc18cd2e301ecdf5001043ec4dc9bdf409677239def47af82bf1d833a755b48cd5dd79c294893fe45d4717c95267d11a",
"id": "ae2367882fa6d10c006dcce30b4a2bdd70434f8348c0ed6431f2125b572b12f4",
"datatokenAddress": "0x9f0c0Ab7c5053F3C1194AF08a487560F19655D85",
"serviceEndpoint": "https://ocean-node-vm3.oceanenterprise.io",
"state": 0,
"type": "compute",
"timeout": 86400,
"consumerParameters": [
{
"default": "abcd",
"name": "param1",
"description": "Parameter 1",
"label": "Parameter 1",
"type": "text",
"required": false
},
{
"default": "1234",
"name": "param2",
"description": "Parameter 2",
"label": "Parameter 2",
"type": "number",
"required": true
}
]
}
],
"nftAddress": "0x24a4Dc380884BEfdaEFBc57f8403B1AbE1B36884",
"credentials": {
"allow": [
{
"values": [
{
"request_credentials": [
{
"format": "jwt_vc_json",
"policies": [],
"type": "gx:Issuer"
}
],
"vc_policies": [
"not-before",
"revoked-status-list"
]
}
],
"type": "SSIpolicy"
},
{
"values": [
{
"address": "*"
}
],
"type": "address"
}
],
"deny": [],
"match_deny": "any"
},
"stats": {
"allocated": 0,
"orders": 0,
"price": {
"value": 1,
"tokenSymbol": "EURC",
"tokenAddress": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4"
}
},
"datatokens": [
{
"symbol": "OEAT",
"address": "0x240E8715Abb05594331002ED3ECAA9a656ED5757",
"name": "Access Token",
"serviceId": "9b551945221a471a809695ede021c4d27db7d359a6ff3f413a1de8fd201d980e"
},
{
"symbol": "OEAT",
"address": "0x9f0c0Ab7c5053F3C1194AF08a487560F19655D85",
"name": "Access Token",
"serviceId": "ae2367882fa6d10c006dcce30b4a2bdd70434f8348c0ed6431f2125b572b12f4"
}
]
},
"additionalDdos": [],
"type": [
"VerifiableCredential"
],
"issuer": "did:web:wallet2.demo.oceanenterprise.io:wallet-api:registry:publisher132",
"proof": {
"signature": "9Sv9yP28X9thsg19sjvq03C5mJaY_XkWXtQhK3dBL5s3Clr8PeW4NDv-S5bWIJQN31r9BEdKTHm67UpQ3gza-w",
"header": {
"kid": "CqCLEltKrojmVXvWPApMYIbTupHhxI6dFwdJ8d2HUrk",
"typ": "JWT",
"alg": "ES256"
}
},
"indexedMetadata": {
"stats": [
{
"symbol": "OEAT",
"name": "Access Token",
"orders": 1,
"datatokenAddress": "0x240E8715Abb05594331002ED3ECAA9a656ED5757",
"serviceId": "9b551945221a471a809695ede021c4d27db7d359a6ff3f413a1de8fd201d980e",
"prices": [
{
"exchangeId": "0xfe538dc442017db7d6aff19f58c6012224ba8be8fabbbb4404ef9ea0ed07addf",
"price": "1.0",
"contract": "0xfa48673a7C36A2A768f89AC1ee8C355D5c367B02",
"type": "fixedrate",
"token": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4"
}
]
},
{
"symbol": "OEAT",
"name": "Access Token",
"orders": 0,
"datatokenAddress": "0x9f0c0Ab7c5053F3C1194AF08a487560F19655D85",
"serviceId": "ae2367882fa6d10c006dcce30b4a2bdd70434f8348c0ed6431f2125b572b12f4",
"prices": [
{
"exchangeId": "0x8510e6141bddd79ac640ac6ee5c8c85735c9036f0a864cdc2927630219c7b735",
"price": "1.0",
"contract": "0xfa48673a7C36A2A768f89AC1ee8C355D5c367B02",
"type": "fixedrate",
"token": "0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238"
}
]
}
],
"nft": {
"state": 0,
"address": "0x24a4Dc380884BEfdaEFBc57f8403B1AbE1B36884",
"name": "Data NFT",
"symbol": "OEC-NFT",
"owner": "0x00Dc9e712D3b31Ab5446A5A7CeaDe0a2901E6d26",
"created": "2026-06-24T09:38:36Z",
"tokenURI": ""
},
"event": {
"txid": "0x34e6ca9814b546c047ddc75682e9bf5c2aa374171020ebbbcc02d4816ae56ee7",
"from": "0x00Dc9e712D3b31Ab5446A5A7CeaDe0a2901E6d26",
"contract": "0x24a4Dc380884BEfdaEFBc57f8403B1AbE1B36884",
"block": 11129055,
"datetime": "2026-06-24T09:38:36.000Z"
},
"purgatory": {
"state": false
}
},
"accessDetails": [
{
"type": "fixed",
"price": "1.0",
"addressOrId": "0xfe538dc442017db7d6aff19f58c6012224ba8be8fabbbb4404ef9ea0ed07addf",
"baseToken": {
"address": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4",
"name": "EURC",
"symbol": "EURC",
"decimals": 6
},
"datatoken": {
"address": "0x240E8715Abb05594331002ED3ECAA9a656ED5757",
"name": "Access Token",
"symbol": "OEAT",
"decimals": 0
},
"paymentCollector": "0x00Dc9e712D3b31Ab5446A5A7CeaDe0a2901E6d26",
"templateId": 2,
"isOwned": false,
"validOrderTx": "",
"isPurchasable": true,
"publisherMarketOrderFee": "0"
},
{
"type": "fixed",
"price": "1.0",
"addressOrId": "0x8510e6141bddd79ac640ac6ee5c8c85735c9036f0a864cdc2927630219c7b735",
"baseToken": {
"address": "0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238",
"name": "USDC",
"symbol": "USDC",
"decimals": 6
},
"datatoken": {
"address": "0x9f0c0Ab7c5053F3C1194AF08a487560F19655D85",
"name": "Access Token",
"symbol": "OEAT",
"decimals": 0
},
"paymentCollector": "0x00Dc9e712D3b31Ab5446A5A7CeaDe0a2901E6d26",
"templateId": 2,
"isOwned": false,
"validOrderTx": "",
"isPurchasable": true,
"publisherMarketOrderFee": "0"
}
]
}
```
{% endcode %}
## The on-chain part of the DDO
On-chain, the following object is saved:
{% code overflow="wrap" %}
```javascript
const remoteAsset = {
remote: {
type: 'ipfs',
hash: ipfsHash
}
}
```
{% endcode %}
* the `type` field is 'ipfs', meaning that the referenced remote object is saved in IPFS
* the `hash` field contains the hash of the Content ID (CID) where the asset's DDO is saved in IPFS.
## References
### SHACL schema
* The SHACL schema used by the OE Node's indexer component to validate the DDO's at publishing or editing time is available here:
# Managing access to assets - to be updated
Fine-Grained Permissions Using Role-Based Access Control. You can Control who can publish, buy or browse data
an OE-enabled dataspace can be deployed in one of two security configurations:
1. SSI Security Disabled: In configurations where SSI security is disabled, access control relies solely on the consumer’s Web3 address. Access to an asset is granted if:
* The address is explicitly listed in the allow list, or
* The address is not present in the deny list
2. SSI Security Enabled: In a dataspace secured by Self-Sovereign Identity (SSI), access to assets is granted upon successful verification of:
* The consumer’s Web3 address
* The Verifiable Credentials required by each asset.
This dual-layered approach ensures that only authorized identities possessing the appropriate credentials can interact with sensitive resources.
A large part of Ocean is about access control, which is primarily handled by datatokens. Users can access a resource (e.g. a file) by redeeming datatokens for that resource. We recognize that enterprises and other users often need more precise ways to specify and manage access, and we have introduced fine-grained permissions for these use cases. Fine-grained permissions mean that access can be controlled precisely at two levels:
* [Marketplace-level permissions](#market-level-permissions) for browsing, downloading or publishing within a marketplace frontend.
* [Asset-level permissions](#asset-level-restrictions) on downloading a specific asset.
The fine-grained permissions features are designed to work in forks of Ocean Market. We have not enabled them in Ocean Market itself, to keep Ocean Market open for everyone to use. On the front end, the permissions features are easily enabled by setting environment variables.
### Introduction
Some datasets need to be restricted to appropriately credentialed users. In this situation there is tension:
1. Datatokens on their own aren’t enough - the datatokens can be exchanged without any restrictions, which means anyone can acquire them and access the data.
2. We want to retain datatokens approach, since they enable Ocean users to leverage existing crypto infrastructure e.g. wallets, exchange etc.
We can resolve this tension by drawing on the following analogy:
> Imagine going to an age 18+ rock concert. You can only get in if you show both (a) your concert ticket and (b) an id showing that you’re old enough.
We can port this model into Ocean, where (a) is a datatoken, and (b) is a credential. The datatoken is the baseline access control. It’s fungible, and something that you’ve paid for or had shared to you. It’s independent of your identity. The credential is something that’s a function of your identity.
The credential based restrictions are implemented in two ways, at the market level and at the asset level. Access to the market is restricted on a role basis, the user's identity is attached to a role via the role based access control (RBAC) server. Access to individual assets is restricted via allow and deny lists which list the ethereum addresses of the users who can and cannot access the asset within the DDO.
### Asset-Level Restrictions
For asset-level restrictions Ocean supports allow and deny lists. Allow and deny lists are advanced features that allow publishers to control access to individual data assets. Publishers can restrict assets so that they can only be accessed by approved users (allow lists) or they can restrict assets so that they can be accessed by anyone except certain users (deny lists).
When an allow-list is in place, a consumer can only access the resource if they have a datatoken and one of the credentials in the "allow" list of the DDO. Ocean also has complementary deny functionality: if a consumer is on the "deny" list, they will not be allowed to access the resource.
Initially, the only credential supported is Ethereum public addresses. To be fair, it’s more a pointer to an individual not a credential; but it has a low-complexity implementation so makes a good starting point. For extensibility, the Ocean metadata schema enables specification of other types of credentials like W3C Verifiable Credentials and more. When this gets implemented, asset-level permissions will be properly RBAC too. Since asset-level permissions are in the DDO, and the DDO is controlled by the publisher, asset-level restrictions are controlled by the publisher.
### Market-Level Permissions
For market-level permissions, Ocean implements a role-based access control server (RBAC server). It implements restrictions at the user level, based on the user’s role (credentials). The RBAC server is run & controlled by the marketplace owner. Therefore permissions at this level are at the discretion of the marketplace owner.
The RBAC server is the primary mechanism for restricting your users ability to publish, buy, or browse assets in the market.
#### Roles
The RBAC server defines four different roles:
* Admin
* Publisher
* Consumer
* User
**Admin/ Publisher**
Currently users with either the admin or publisher roles will be able to use the Market without any restrictions. They can publish, buy and browse datasets.
**Consumer**
A user with the consumer is able to browse datasets, purchase them, trade datatokens and also contribute to datapools. However, they are not able to publish datasets.
**Users**
Users are able to browse and search datasets but they are not able to purchase datasets, trade datatokens, or contribute to data pools. They are also not able to publish datasets.
**Address without a role**
If a user attempts to view the data market without a role, or without a wallet connected, they will not be able to view or search any of the datasets.
**No wallet connected**
When the RBAC server is enabled on the market, users are required to have a wallet connected to browse the datasets.
#### Mapping roles to addresses
Currently the are two ways that the RBAC server can be configured to map user roles to Ethereum addresses. The RBAC server is also built in such a way that it is easy for you to add your own authorization service. They two existing methods are:
1. Keycloak
If you already have a [Keycloak](https://www.keycloak.org/) identity and access management server running you can configure the RBAC server to use it by adding the URL of your Keycloak server to the `KEYCLOAK_URL` environmental variable in the RBAC `.enb` file.
2. JSON
Alternatively, if you are not already using Keycloak, the easiest way to map user roles to ethereum addresses is in a JSON object that is saved as the `JSON_DATA` environmental variable in the RBAC `.env` file. There is an example of the format required for this JSON object in `.example.env`
It is possible that you can configure both of these methods of mapping user roles to Ethereum Addresses. In this case the requests to your RBAC server should specify which auth service they are using e.g. `"authService": "json"` or `"authService": "keycloak"`
**Default Auth service**
Additionally, you can also set an environmental variable within the RBAC server that specifies the default authorization method that will be used e.g. `DEFAULT_AUTH_SERVICE = "json"`. When this variable is specified, requests sent to your RBAC server don't need to include an `authService` and they will automatically use the default authorization method.
#### Running the RBAC server locally
You can start running the RBAC server by following these steps:
1. Clone this repository:
```bash
git clone https://github.com/oceanprotocol/RBAC-Server.git
cd RBAC-Server
```
2. Install the dependencies:
```bash
npm install
```
3. Build the service
```bash
npm run build
```
4. Start the server
```bash
npm run start
```
#### Running the RBAC in Docker
When you are ready to deploy the RBAC server to
1. Replace the KEYCLOAK\_URL in the Dockerfile with the correct URL for your hosting of [Keycloak](https://www.keycloak.org/).
2. Run the following command to build the RBAC service in a Docker container:
```bash
npm run build:docker
```
3. Next, run the following command to start running the RBAC service in the Docker container:
```bash
npm run start:docker
```
4. Now you are ready to send requests to the RBAC server via postman. Make sure to replace the URL to `http://localhost:49160` in your requests.
# Supported networks & currencies
All the public networks to which the Ocean Enterprise contracts are deployed, and the currencies in which the published assets and C2D resources can be listed.
* [Supported networks](/developers/networks/supported-networks)
* [Supported currencies](/developers/networks/supported-currencies)
# Supported Networks
## Supported Networks
Ocean Enterprise smart contracts are deployed across multiple public networks, including several production chains and several testnets.
The file [`address.json`](https://github.com/oceanprotocol/contracts/blob/v4main/addresses/address.json) holds up-to-date deployment addresses for all Ocean contracts.
### Networks Summary
The networks where Ocean Enterprise smart contracts are deployed are:
**Production Networks:**
* Ethereum Mainnet
* Optimism (OP) Mainnet
**Test Networks:**
* Ethereum Sepolia
* Optimism (OP) Sepolia
### Production Networks
The smart contracts deployed by O.E.C. in the production networks and used by default by the Ocean Enterprise components are available at the following addresses.
* **Ethereum Mainnet**
### Test Networks
The smart contracts deployed by O.E.C. in the test networks and used by default by the Ocean Enterprise components are available at the following addresses.
* **Ethereum Sepolia**
***
# Fees
The Ocean Enterprise Collective defines various fees for creating a sustainability loop.
One transaction may have fees going to several entities, such as the marketplace operator where the asset was published, the Ocean Node provider, and the Ocean Enterprise Collective e.V.
* **Marketplace**: the marketplace where the asset is published or consumed
* **Provider**: the Ocean Node facilitating asset consumption. May serve up data, run C2D jobs, etc.
* **Ocean Enterprise Collective**: for developing and maintaining the OE code base
Fee Type
Value
Marketplace
set by the marketplace operator for asset publishing and/or consumption
Provider
set by the Ocean Node operator
Ocean Enterprise Collective
set by OEC eV at 1.9% of the asset and compute job price with a minimum value of 1 cent
{% hint style="info" %}
Stay up-to-date with the latest information! The values within the system are regularly updated. We recommend verifying the most recent values directly from the [contracts](https://github.com/oceanprotocol/contracts) and the [market](https://github.com/oceanprotocol/market).
{% endhint %}
# Deployment Guides
Learn how to deploy Ocean Enterprise in your environment.
This chapter explains how to install and configure the components of the Ocean Enterprise software stack. All components run in Docker containers on a Linux operating system. Deploying the OE components requires solid familiarity with Linux, Docker Engine, and Docker Compose.
As described in the [Dataspace Configuration Options](/developers/architecture-1) chapter, the OE Stack supports two deployment modes - with SSI-based access control enabled or disabled. Because the required components and installation order vary by configuration, consult the dedicated chapter on the installation sequence for each configuration.
Each deployment subchapter is structured into four parts:
* *Prerequisites*: lists the hardware, software, and other requirements for running the component\ **Note**: The hardware specifications provided represent the minimum configuration identified during our testing. Actual requirements vary based on workload characteristics such as the number of concurrent requests and expected response times. We recommend starting with an estimated configuration based on your anticipated workload, monitoring system performance over time, and adjusting resources accordingly.
* *Deployment Steps*: describes the tasks required to perform to install and configure the component.
* *Post installation steps*: tasks that must be completed for the component to function properly
* *Environment Variables*: explains the purpose and usage of each environment variable needed by the component
This chapter includes the following information:
* [Deployment Modes](/infrastructure/deployment-modes)
* [OE Node Installation and Configuration](/infrastructure/oe-node-installation-and-configuration)
* [Marketplace Installation and Configuration](/infrastructure/marketplace-installation-and-configuration)
* [Policy Server and Policy Server Proxy Installation and Configuration](/infrastructure/policy-server-and-policy-server-proxy-installation-and-configuration)
* [SSI Stack Installation and Configuration](/infrastructure/ssi-stack-installation-and-configuration)
# Deployment modes
The OE stack supports two deployment modes, determined by whether the dataspace uses SSI‑based access control.
## Dataspace with SSI-based access control disabled
### Configuration example
In a dataspace where SSI‑based access control is disabled, only two OE components are required: the OE Node and the marketplace. The table below provides the assumed URLs for each element.
| Component | URL |
| ----------- | ----------------------------------- |
| OE Node | |
| Marketplace | |
To ensure correct operation, configure the relevant environment variable in each component, using the examples shown in the table below.
| Component | Environment variable | Value |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------- | --------------------------------- |
| **OE Node** | [POLICY\_SERVER\_URL](/infrastructure/oe-node-installation-and-configuration#policy_server_url) | null |
| **Marketplace** | [NEXT\_PUBLIC\_PROVIDER\_URL](/infrastructure/marketplace-installation-and-configuration#next_public_provider_url) | |
| | [NEXT\_PUBLIC\_METADATACACHE\_URI](/infrastructure/marketplace-installation-and-configuration#next_public_metadatacache_uri) | |
| | [NEXT\_PUBLIC\_SSI\_ENABLED](/infrastructure/marketplace-installation-and-configuration#next_public_ssi_enabled) | false |
### Installation sequence
The recommended deployment order for this setup is:
1. [Install and configure the OE Node](/infrastructure/oe-node-installation-and-configuration)
2. [Install and configure the marketplace](/infrastructure/marketplace-installation-and-configuration)
## Dataspace with SSI-based access control enabled
### Configuration example
In a dataspace with SSI‑based access control enabled, all OE components are required. The table below provides the assumed URLs for each element.
| Component | URL |
| ------------------- | ------------------------------------- |
| OE Node | |
| Marketplace | |
| Policy Server | |
| Policy Server Proxy | |
| SSI Wallet | |
| Verifier | |
| OPA Server | |
To ensure correct operation, configure the relevant environment variable in each component, using the examples shown in the table below.
| Component | Environment variable | Value |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- |
| **Policy Server** | [MODE\_PS](/infrastructure/policy-server-and-policy-server-proxy-installation-and-configuration#mode_ps) | 1 |
| | [MODE\_PROXY](/infrastructure/policy-server-and-policy-server-proxy-installation-and-configuration#mode_proxy) | 0 |
| | [OCEAN\_NODE\_URL](/infrastructure/policy-server-and-policy-server-proxy-installation-and-configuration#ocean_node_url) | |
| | [WALTID\_VERIFIER\_URL](/infrastructure/policy-server-and-policy-server-proxy-installation-and-configuration#waltid_verifier_url) | |
| | [WALTID\_VERIFY\_RESPONSE\_REDIRECT\_URL](/infrastructure/policy-server-and-policy-server-proxy-installation-and-configuration#waltid_verify_response_redirect_url) | |
| | [WALTID\_VERIFY\_PRESENTATION\_DEFINITION\_URL](/infrastructure/policy-server-and-policy-server-proxy-installation-and-configuration#waltid_verify_response_redirect_url) | |
| **Policy Server Proxy** | [MODE\_PS](/infrastructure/policy-server-and-policy-server-proxy-installation-and-configuration#mode_ps) | 0 |
| | [MODE\_PROXY](/infrastructure/policy-server-and-policy-server-proxy-installation-and-configuration#mode_proxy) | 1 |
| | [OCEAN\_NODE\_URL](/infrastructure/policy-server-and-policy-server-proxy-installation-and-configuration#ocean_node_url) | |
| **OE Node** | [POLICY\_SERVER\_URL](/infrastructure/oe-node-installation-and-configuration#policy_server_url) | |
| **Marketplace** | [NEXT\_PUBLIC\_PROVIDER\_URL](/infrastructure/marketplace-installation-and-configuration#next_public_provider_url) | |
| | [NEXT\_PUBLIC\_METADATACACHE\_URI](/infrastructure/marketplace-installation-and-configuration#next_public_metadatacache_uri) | |
| | [NEXT\_PUBLIC\_SSI\_ENABLED](/infrastructure/marketplace-installation-and-configuration#next_public_ssi_enabled) | true |
| | [NEXT\_PUBLIC\_SSI\_POLICY\_SERVER](/infrastructure/marketplace-installation-and-configuration#next_public_ssi_policy_server) | |
| | [NEXT\_PUBLIC\_OPA\_SERVER\_URL](/infrastructure/marketplace-installation-and-configuration#next_public_opa_server_url) | |
| | [NEXT\_PUBLIC\_SSI\_WALLET\_API](/infrastructure/marketplace-installation-and-configuration#next_public_ssi_wallet_api) | |
### Installation sequence
The recommended deployment order for this setup is:
1. [Install and configure the SSI Stack](/infrastructure/ssi-stack-installation-and-configuration)
2. [Install the Policy Server](/infrastructure/policy-server-and-policy-server-proxy-installation-and-configuration)
3. [Install and configure the OE Node](/infrastructure/oe-node-installation-and-configuration)
4. [Install and configure the Policy Server Proxy](/infrastructure/policy-server-and-policy-server-proxy-installation-and-configuration)
5. [Install and configure the marketplace](/infrastructure/marketplace-installation-and-configuration)
# Compatibility Matrix
This table shows the compatibility list between the versions of the OE technology stack components.
| Marketplace | OE Node | Policy Server | SSI Stack |
| --------------- | ---------------- | --------------- | -------------- |
| v1.0.0 - v1.1.2 | v0.2.3 | v1.0.0 | gaiax-0.1.1-OE |
| v1.1.3 | v1.0.3 | v1.0.0 | gaiax-0.1.1-OE |
| v1.2.0 | v2.1.0, v2.1.1 | v1.0.0 | gaiax-0.1.1-OE |
| v1.3.0 | v2.1.0, v2.1.1 | v1.1.0, v1.1.1 | gaiax-0.1.1-OE |
| v1.3.1 | v2.1.0, v2.1.1 | v1.1.0 - v1.2.0 | gaiax-0.1.1-OE |
| v1.4.0 | v3.0.1 | v1.2.0 | gaiax-0.1.1-OE |
| v1.4.1 - v1.4.3 | v3.0.3 - v3.1.11 | v1.2.0 - v1.3.2 | gaiax-0.1.1-OE |
| v1.4.4-v1.4.5 | v3.1.12 - v3.2.1 | v1.2.0 - v1.3.2 | gaiax-0.1.1-OE |
# OE Node installation and configuration
## Prerequisites
### Hardware requirements
The minimum hardware requirements for the server that will run the OE Node are:
* number of cores: 2
* RAM: 16 GB
* disk: 50 GB
### Software requirements
* **Operating System:** Any Linux distribution supported by the Docker Engine and Docker Compose products. For guidance on compatible platforms, see the [Docker Compose supported platforms](https://docs.docker.com/desktop/setup/install/linux/) and [Docker Engine supported platforms](https://docs.docker.com/engine/install/) documentation
* **For OE Node v3.0.1 and newer:** A Linux distribution with library `glibc` v2.38 or newer. To check the current version of glibc, run the following command:
{% code overflow="wrap" %}
```shellscript
ldd --version
```
{% endcode %}
* **Software products:**
* Docker Engine
* Docker Compose
### **Other requirements**
* **Blockchain RPC provider**: Use a service such as Alchemy, Infura, or Chainstack. Ensure that your subscription tier supports a sufficient number of requests per second to meet the node demand.
* **IPFS gateway provider**: Use a gateway such as Pinata, Cloudflare, or Filebase. Verify that your subscription tier provides adequate storage capacity, file limits, and request throughput for your expected workload. \ **Note:** Make sure the IPFS gateway used by the OE Node is a **public gateway** so the node can retrieve the CIDs that were pinned during asset publishing.
## Pre-installation steps
Make sure you review the [Compatibility Matrix](/infrastructure/compatibility-matrix) to ensure that the version is compatible with the other components.
## Deployment steps
The OE Node uses Elasticsearch as the underlying database for its indexer. Elasticsearch can be deployed together with the OE Node or installed separately.
There are multiple ways to install and run the OE Node, but this guide focuses on two primary approaches: using Docker Compose or PM2.
### Use Docker Compose to install and run OE Node
To install and configure the OE Node using Docker Compose, perform the following steps:
1. The OE Node repository is located [here](https://github.com/OceanProtocolEnterprise/ocean-node). Clone the OE Node repository.
```sh
git clone https://github.com/OceanProtocolEnterprise/ocean-node.git && cd ocean-node
```
2. Copy `.env.elasticsearch.example` to `.env.elasticsearch`
```sh
cp .env.elasticsearch.example .env.elasticsearch
```
3. Edit the *.env.elasticsearch* file and set the `ELASTIC_PASSWORD` parameter to the password required to connect to the ElasticSearch instance.
```shellscript
nano .env.elasticsearch
```
4. Copy `.env.node.example` to `.env.node`
```sh
cp .env.node.example .env.node
```
5. Edit the *.env.node* file and set the OE Node environment variables according to your configuration (see the [Environment Variables](#environment-variables) chapter for details on how to set them).
```sh
nano .env.node
```
**Note**: Make sure the password set in the `DB_PASSWORD` parameter matches the password configured for the Elasticsearch instance in step 4.
6. Start the services
```sh
docker compose up -d
```
On the first run, the script creates both the Elasticsearch and OE Node containers. Because the OE Node depends on Elasticsearch reaching a specific ready state, it may take some time before the OE Node container starts.
**Note:** This installs the latest available version of the OE Node. To install a specific version, edit the `docker-compose.yml` file and set the desired version tag.
### Use PM2 to run the OE Node
In this configuration, the OE Node runs as a process on the host machine, and it's managed by pm2.
Preinstallation tasks:
1. Make sure you have the following tools installed on your Linux system:
* [node.js](https://nodejs.org/en/download): the required version of node.js is listed in the `.nvmrc` file in the [OE Node repository](https://github.com/OceanProtocolEnterprise/ocean-node). Make sure this is the default version. To this end, you can use the [nvm ](https://github.com/nvm-sh/nvm?tab=readme-ov-file#installing-and-updating)tool.
* [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm)
* [pm2](https://pm2.keymetrics.io/). Optionally, you can install pm2-logrotate to easily manage the OE node logs.
2. Start Elasticsearch in a Docker container on the host machine:
```shellscript
docker run -d \
--name elasticsearch \
-p 9200:9200 \
-e "discovery.type=single-node" \
-e "ELASTIC_PASSWORD=your_secure_password" \
-e "xpack.security.enabled=true" \
docker.elastic.co/elasticsearch/elasticsearch:8.19.12
```
To install and run the OE Node using pm2, perform the following steps:
1. The OE Node repository is located [here](https://github.com/OceanProtocolEnterprise/ocean-node). Clone the OE Node repository.
```sh
git clone https://github.com/OceanProtocolEnterprise/ocean-node.git && cd ocean-node
```
2. Copy `.env.example` to `.env`
```sh
cp .env.example .env
```
3. Edit the *.env* file to set the environment variables specific to your configuration (please refer to the [Environment Variables](#environment-variables) chapter for how to set the variables).
```shellscript
nano .env
```
6. Load the environment variables in the current session
```sh
source .env
```
6. Start OE Node process in pm2
```sh
pm2 start npm --name "oe-node" -- run start
```
7. Once the process is started, verify its state.
```sh
pm2 ls
```
8. Verify the logs to make sure the node started well
```sh
pm2 logs "oe-node"
```
## **Post installation steps**
* If the OE Node is not configured to use HTTPS directly, deploy it behind a reverse proxy responsible for TLS termination and secure request forwarding. The proxy should enforce HTTPS for all external traffic and route decrypted requests to the OE Node's internal port.
* Ensure that the OE Node operates in a network environment that permits outbound communication to the configured Policy Server, Policy Server Proxy, and Marketplace
* For OE Nodes that provide a paid C2D environment, verify that the associated web3 address maintains sufficient native‑token funds on the connected blockchain to cover gas fees for withdrawals from the escrow account. Monitor and replenish the OE Node’s balance regularly.
## Environment variables
In this chapter, the key environment variables required to configure the OE Node are highlighted. The full list of available environment variables is provided in the documentation for the Community Edition of the node, accessible [here](https://github.com/oceanprotocol/ocean-node/blob/main/docs/env.md).
### Private Key
#### PRIVATE\_KEY
**Description:** Sets the private key used by the OE Node to encrypt and decrypt assets.
**Values:** String
**Example:** `"0x1d751ded5a32226054cd2e71261039b65afb9ee1c746d055dd699b1150a5befc"`
**Default Value:** `null`
### Blockchain RPC
#### RPCS
**Description:** Sets the list of blockchains, by blockchain ID (e.g., 1 - Ethereum, 11155111 - Eth Sepolia), to which the OE Node connects to retrieve assets. If not specified otherwise in the `INDEXER_NETWORKS` variable, the indexer will connect to all the blockchains listed here.
Also, for each blockchain, two things are specified:
* `"rpc"` : The RPC provider URL. Use the RPC URL supplied by the RPC provider.
* `"startBlock"` : The block number from which the indexer will search for events related to the asset creation or update. Verify the
**Values:** JSON map of chainId to object
**Example:** `{"11155111":{"rpc":"https://eth-sepolia.g.alchemy.com/","chainId":11155111,"network":"sepolia","chunkSize":50,"startB
lock":9802079},"11155420":{"rpc":"https://opt-sepolia.g.alchemy.com/","chainId":11155420,"network":"optimism_sepolia","chunkSize": 50,"startBlock":36735314}}`
**Default Value:** `{}`
### Decentralized File Systems
#### IPFS\_GATEWAY
**Description:** Sets the URL of the IPFS gateway used to fetch the asset's DDO. Use the URL supplied by the IFPS provider. Make sure the IPFS gateway is public; otherwise will not be able to access CIDs pinned by other services, such as the marketplace.
**Values:** String (URL)
**Example:** `https://ipfs.io/`
**Default Value:** `null`
### Elasticsearch connection
#### DB\_URL
**Description:** Sets the URL for connecting to the Elasticsearch instance.
**Values:** String (URL)
**Example:** `http://elastic:@localhost:9200/` (if Elasticsearch is deployed on the same hostmachine as OE Node)
**Default Value:** `null`
#### DB\_USERNAME
**Description:** Sets the user name for connecting to the Elasticsearch instance.
**Values:** String
**Example:** `"elastic"`
**Default Value:** `null`
#### DB\_PASSWORD
**Description:** Sets the password for connecting to the Elasticsearch instance. Make sure you use the same password you set when you started the Elasticsearch container.
**Values:** String
**Example:** `"elastic"`
**Default Value:** `null`
### Node fees
#### FEE\_TOKENS
**Description:** Sets the tokens used for the node fees for each blockchain the OE Node is connected to.
**Values:** JSON array of string (chainId) to string (token address) mapping
**Example:** `{"11155111":"0x1B083D8584dd3e6Ff37d04a6e7e82b5F622f3985","11155420":"0xf26c6C93f9f1d725e149d95f8E7B2334a406aD10"}`
**Default Value:** `null`
#### FEE\_AMOUNT
**Description:** Sets the absolute value of the fee and the unit to which the fee is applied. However, applying the fee per unit is currently not implemented in OE Node, so the fee is applied when an asset is purchased, regardless of its size.
**Values:** JSON object
**Example:** `{"amount":1,"unit":"MB"}`
**Default Value:** `null`
### Policy Server
#### POLICY\_SERVER\_URL
**Description:** Sets the URL of the Policy Server used by the OE Node to perform the verification (address-based and SII-based) on asset access attempts. If no URL is set, then SSI verification is disabled and the OE Node performs only address-based verification.
**Values:** String (URL)
**Example:** `"https://ps3.demo.oceanenterprise.io/"`
**Default Value:** `null`
#### POLICY\_SERVER\_API\_KEY
**Description:** Sets the API KEY used by Policy Server to authenticate API requests. Set the same key that was used in the [POLICY\_SERVER\_API\_KEY](/infrastructure/policy-server-and-policy-server-proxy-installation-and-configuration#policy_server_api_key) variable of the corresponding Policy Server. If API requests authentication is not enabled on the Policy Server side, leave this variable null.
**Values:** string
**Example:** `mrgcorhTzA1Ey2WRhZAK8tkw4zBrIgQ757toUz3fXvfHh8Ua`
**Defaul Value:** `null`
### Compute Environment
**DOCKER\_COMPUTE\_ENVIRONMENT**
**Description:** Sets the Docker-based compute environment of the OE Node.
**Value:** JSON list of objects
**Example:**
* *For OE Node up to v2.1.1*
{% code overflow="wrap" %}
```json
[{"socketPath":"/var/run/docker.sock","paymentClaimInterval":120,"resources":[{"id":"myGPU","description":"NVIDIA GeForce GTX 1060 3GB","type":"gpu","total":4,"init":{"deviceRequests":{"Driver":"nvidia","DeviceIDs":["GPU-294c6802-bb2f-fedb-f9e0-a26b9142dd81"],"Capabilities":[["gpu"]]}}},{"id":"disk","total":4}],"storageExpiry":604800,"maxJobDuration":3600,"fees":{"11155111":[{"feeToken":"0x1B083D8584dd3e6Ff37d04a6e7e82b5F622f3985","prices":[{"id":"cpu","price":1},{"id":"gpu","price":4},{"id":"ram","price":1},{"id":"disk","price":1}]},{"feeToken":"0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4","prices":[{"id":"cpu","price":0.1},{"id":"gpu","price":0.4},{"id":"ram","price":0.1},{"id":"disk","price":0.1}]},{"feeToken":"0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238","prices":[{"id":"cpu","price":0.15},{"id":"gpu","price":0.6},{"id":"ram","price":0.15},{"id":"disk","price":0.15}]}],"11155420":[{"feeToken":"0xf26c6C93f9f1d725e149d95f8E7B2334a406aD10","prices":[{"id":"cpu","price":1},{"id":"gpu","price":4},{"id":"ram","price":1},{"id":"disk","price":1}]},{"feeToken":"0x5fd84259d66Cd46123540766Be93DFE6D43130D7","prices":[{"id":"cpu","price":0.15},{"id":"gpu","price":0.6},{"id":"ram","price":0.15},{"id":"disk","price":0.15}]}]},"free":{"maxJobDuration":1800,"maxJobs":3,"resources":[{"id":"myGPU","description":"NVIDIA GeForce GTX 1060 3GB","type":"gpu","total":1,"init":{"deviceRequests":{"Driver":"nvidia","DeviceIDs":["GPU-294c6802-bb2f-fedb-f9e0-a26b9142dd81"],"Capabilities":[["gpu"]]}}},{"id":"cpu","max":1},{"id":"myGPU","max":1},{"id":"ram","max":0.5},{"id":"disk","max":0.5}]}}]
```
{% endcode %}
Here's the structured format of the same value.
```json
[
{
"socketPath": "/var/run/docker.sock",
"paymentClaimInterval": 120,
"resources": [
{
"id": "myGPU",
"description": "NVIDIA GeForce GTX 1060 3GB",
"type": "gpu",
"total": 4,
"init": {
"deviceRequests": {
"Driver": "nvidia",
"DeviceIDs": ["GPU-294c6802-bb2f-fedb-f9e0-a26b9142dd81"],
"Capabilities": [["gpu"]]
}
}
},
{ "id": "disk", "total": 4 }
],
"storageExpiry": 604800,
"maxJobDuration": 3600,
"fees": {
"11155111": [
{
"feeToken": "0x1B083D8584dd3e6Ff37d04a6e7e82b5F622f3985",
"prices": [
{ "id": "cpu", "price": 1 },
{ "id": "gpu", "price": 4 },
{ "id": "ram", "price": 1 },
{ "id": "disk", "price": 1 }
]
},
{
"feeToken": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4",
"prices": [
{ "id": "cpu", "price": 0.1 },
{ "id": "gpu", "price": 0.4 },
{ "id": "ram", "price": 0.1 },
{ "id": "disk", "price": 0.1 }
]
},
{
"feeToken": "0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238",
"prices": [
{ "id": "cpu", "price": 0.15 },
{ "id": "gpu", "price": 0.6 },
{ "id": "ram", "price": 0.15 },
{ "id": "disk", "price": 0.15 }
]
}
],
"11155420": [
{
"feeToken": "0xf26c6C93f9f1d725e149d95f8E7B2334a406aD10",
"prices": [
{ "id": "cpu", "price": 1 },
{ "id": "gpu", "price": 4 },
{ "id": "ram", "price": 1 },
{ "id": "disk", "price": 1 }
]
},
{
"feeToken": "0x5fd84259d66Cd46123540766Be93DFE6D43130D7",
"prices": [
{ "id": "cpu", "price": 0.15 },
{ "id": "gpu", "price": 0.6 },
{ "id": "ram", "price": 0.15 },
{ "id": "disk", "price": 0.15 }
]
}
]
},
"free": {
"maxJobDuration": 1800,
"maxJobs": 3,
"resources": [
{
"id": "myGPU",
"description": "NVIDIA GeForce GTX 1060 3GB",
"type": "gpu",
"total": 1,
"init": {
"deviceRequests": {
"Driver": "nvidia",
"DeviceIDs": ["GPU-294c6802-bb2f-fedb-f9e0-a26b9142dd81"],
"Capabilities": [["gpu"]]
}
}
},
{ "id": "cpu", "max": 1 },
{ "id": "myGPU", "max": 1 },
{ "id": "ram", "max": 0.5 },
{ "id": "disk", "max": 0.5 }
]
}
}
]
```
The configuration described by this value provides free and paid compute environments. The free compute environment has a maximum job duration of 30 minutes, a maximum number of 3 simultaneous jobs, and limited resources (1 CPU, 1 GPU, 0.5GB of RAM, and 0.5GB of disk). The paid environment has more resources to allocate and allows a maximum job duration of 60 minutes.
* *For OE Node v3.0.1 or newer*
{% code overflow="wrap" %}
```json
[{"socketPath":"/var/run/docker.sock","paymentClaimInterval":120,"environments":[{"id":"environment 1","storageExpiry":604800,"maxJobDuration":3600,"minJobDuration":60,"resources":[{"id":"myGPU","description":"NVIDIA GeForce GTX 1060 3GB","type":"gpu","total":4,"init":{"deviceRequests":{"Driver":"nvidia","DeviceIDs":["GPU-294c6802-bb2f-fedb-f9e0-a26b9142dd81"],"Capabilities":[["gpu"]]}}},{"id":"cpu","min":1,"max":1,"total":1},{"id":"ram","min":0,"max":2,"total":2},{"id":"disk","min":0,"max":2,"total":4}],"fees":{"11155111":[{"feeToken":"0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4","prices":[{"id":"cpu","price":0.1},{"id":"gpu","price":0.4},{"id":"ram","price":0.1},{"id":"disk","price":0.1}]},{"feeToken":"0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238","prices":[{"id":"cpu","price":0.15},{"id":"gpu","price":0.6},{"id":"ram","price":0.15},{"id":"disk","price":0.15}]}],"11155420":[{"feeToken":"0xf26c6C93f9f1d725e149d95f8E7B2334a406aD10","prices":[{"id":"cpu","price":1},{"id":"gpu","price":4},{"id":"ram","price":1},{"id":"disk","price":1}]},{"feeToken":"0x5fd84259d66Cd46123540766Be93DFE6D43130D7","prices":[{"id":"cpu","price":0.15},{"id":"gpu","price":0.6},{"id":"ram","price":0.15},{"id":"disk","price":0.15}]}]},"free":{"maxJobDuration":1800,"maxJobs":3,"resources":[{"id":"myGPU","description":"NVIDIA GeForce GTX 1060 3GB","type":"gpu","total":1,"init":{"deviceRequests":{"Driver":"nvidia","DeviceIDs":["GPU-294c6802-bb2f-fedb-f9e0-a26b9142dd81"],"Capabilities":[["gpu"]]}}},{"id":"cpu","max":1},{"id":"myGPU","max":1},{"id":"ram","min":0,"max":1},{"id":"disk","max":0.5}]}},{"id":"environment 2","storageExpiry":604800,"maxJobDuration":3600,"minJobDuration":60,"resources":[{"id":"myGPU","description":"NVIDIA GeForce GTX 1060 3GB","type":"gpu","total":2,"init":{"deviceRequests":{"Driver":"nvidia","DeviceIDs":["GPU-294c6802-bb2f-fedb-f9e0-a26b9142dd81"],"Capabilities":[["gpu"]]}}},{"id":"cpu","min":1,"max":1,"total":1},{"id":"ram","min":0,"max":2,"total":2},{"id":"disk","min":0,"max":2,"total":4}],"fees":{"11155111":[{"feeToken":"0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4","prices":[{"id":"cpu","price":0.08},{"id":"gpu","price":0.3},{"id":"ram","price":0.08},{"id":"disk","price":0.08}]},{"feeToken":"0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238","prices":[{"id":"cpu","price":0.1},{"id":"gpu","price":0.5},{"id":"ram","price":0.1},{"id":"disk","price":0.1}]}],"11155420":[{"feeToken":"0xf26c6C93f9f1d725e149d95f8E7B2334a406aD10","prices":[{"id":"cpu","price":1},{"id":"gpu","price":4},{"id":"ram","price":1},{"id":"disk","price":1}]},{"feeToken":"0x5fd84259d66Cd46123540766Be93DFE6D43130D7","prices":[{"id":"cpu","price":0.15},{"id":"gpu","price":0.6},{"id":"ram","price":0.15},{"id":"disk","price":0.15}]}]},"free":{"maxJobDuration":900,"maxJobs":2,"resources":[{"id":"myGPU","description":"NVIDIA GeForce GTX 1060 3GB","type":"gpu","total":1,"init":{"deviceRequests":{"Driver":"nvidia","DeviceIDs":["GPU-294c6802-bb2f-fedb-f9e0-a26b9142dd81"],"Capabilities":[["gpu"]]}}},{"id":"cpu","max":1},{"id":"myGPU","max":1},{"id":"ram","min":0,"max":1},{"id":"disk","max":0.4}]}}]}]
```
{% endcode %}
Here's the structured format of the same value.
{% code overflow="wrap" %}
```json
[
{
"socketPath": "/var/run/docker.sock",
"paymentClaimInterval": 120,
"environments": [
{
"id": "environment 1",
"storageExpiry": 604800,
"maxJobDuration": 3600,
"minJobDuration": 60,
"resources": [
{
"id": "myGPU",
"description": "NVIDIA GeForce GTX 1060 3GB",
"type": "gpu",
"total": 4,
"init": {
"deviceRequests": {
"Driver": "nvidia",
"DeviceIDs": ["GPU-294c6802-bb2f-fedb-f9e0-a26b9142dd81"],
"Capabilities": [["gpu"]]
}
}
},
{ "id": "cpu", "min": 1, "max": 1, "total": 1 },
{ "id": "ram", "min": 0, "max": 2, "total": 2 },
{ "id": "disk", "min": 0, "max": 2, "total": 4 }
],
"fees": {
"11155111": [
{
"feeToken": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4",
"prices": [
{ "id": "cpu", "price": 0.1 },
{ "id": "gpu", "price": 0.4 },
{ "id": "ram", "price": 0.1 },
{ "id": "disk", "price": 0.1 }
]
},
{
"feeToken": "0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238",
"prices": [
{ "id": "cpu", "price": 0.15 },
{ "id": "gpu", "price": 0.6 },
{ "id": "ram", "price": 0.15 },
{ "id": "disk", "price": 0.15 }
]
}
],
"11155420": [
{
"feeToken": "0xf26c6C93f9f1d725e149d95f8E7B2334a406aD10",
"prices": [
{ "id": "cpu", "price": 1 },
{ "id": "gpu", "price": 4 },
{ "id": "ram", "price": 1 },
{ "id": "disk", "price": 1 }
]
},
{
"feeToken": "0x5fd84259d66Cd46123540766Be93DFE6D43130D7",
"prices": [
{ "id": "cpu", "price": 0.15 },
{ "id": "gpu", "price": 0.6 },
{ "id": "ram", "price": 0.15 },
{ "id": "disk", "price": 0.15 }
]
}
]
},
"free": {
"maxJobDuration": 1800,
"maxJobs": 3,
"resources": [
{
"id": "myGPU",
"description": "NVIDIA GeForce GTX 1060 3GB",
"type": "gpu",
"total": 1,
"init": {
"deviceRequests": {
"Driver": "nvidia",
"DeviceIDs": ["GPU-294c6802-bb2f-fedb-f9e0-a26b9142dd81"],
"Capabilities": [["gpu"]]
}
}
},
{ "id": "cpu", "max": 1 },
{ "id": "myGPU", "max": 1 },
{ "id": "ram", "min": 0, "max": 1 },
{ "id": "disk", "max": 0.5 }
]
}
},
{
"id": "environment 2",
"storageExpiry": 604800,
"maxJobDuration": 3600,
"minJobDuration": 60,
"resources": [
{
"id": "myGPU",
"description": "NVIDIA GeForce GTX 1060 3GB",
"type": "gpu",
"total": 2,
"init": {
"deviceRequests": {
"Driver": "nvidia",
"DeviceIDs": ["GPU-294c6802-bb2f-fedb-f9e0-a26b9142dd81"],
"Capabilities": [["gpu"]]
}
}
},
{ "id": "cpu", "min": 1, "max": 1, "total": 1 },
{ "id": "ram", "min": 0, "max": 2, "total": 2 },
{ "id": "disk", "min": 0, "max": 2, "total": 4 }
],
"fees": {
"11155111": [
{
"feeToken": "0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4",
"prices": [
{ "id": "cpu", "price": 0.08 },
{ "id": "gpu", "price": 0.3 },
{ "id": "ram", "price": 0.08 },
{ "id": "disk", "price": 0.08 }
]
},
{
"feeToken": "0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238",
"prices": [
{ "id": "cpu", "price": 0.1 },
{ "id": "gpu", "price": 0.5 },
{ "id": "ram", "price": 0.1 },
{ "id": "disk", "price": 0.1 }
]
}
],
"11155420": [
{
"feeToken": "0xf26c6C93f9f1d725e149d95f8E7B2334a406aD10",
"prices": [
{ "id": "cpu", "price": 1 },
{ "id": "gpu", "price": 4 },
{ "id": "ram", "price": 1 },
{ "id": "disk", "price": 1 }
]
},
{
"feeToken": "0x5fd84259d66Cd46123540766Be93DFE6D43130D7",
"prices": [
{ "id": "cpu", "price": 0.15 },
{ "id": "gpu", "price": 0.6 },
{ "id": "ram", "price": 0.15 },
{ "id": "disk", "price": 0.15 }
]
}
]
},
"free": {
"maxJobDuration": 900,
"maxJobs": 2,
"resources": [
{
"id": "myGPU",
"description": "NVIDIA GeForce GTX 1060 3GB",
"type": "gpu",
"total": 1,
"init": {
"deviceRequests": {
"Driver": "nvidia",
"DeviceIDs": ["GPU-294c6802-bb2f-fedb-f9e0-a26b9142dd81"],
"Capabilities": [["gpu"]]
}
}
},
{ "id": "cpu", "max": 1 },
{ "id": "myGPU", "max": 1 },
{ "id": "ram", "min": 0, "max": 1 },
{ "id": "disk", "max": 0.4 }
]
}
}
]
}
]
```
{% endcode %}
The configuration described by this value provides two different environments on the same host: *environment 1* and *environment 2*. Each environment has two sub-environments: paid and free. For each environment, the available resources are listed, as well as the price of each resource, for each blockchain to which the node is connected.
For details on how to set this variable, refer to the information available [here](https://github.com/oceanprotocol/ocean-node/blob/main/docs/env.md#compute).
If you want the C2D environment to provide GPU resources, please refer to [this guide](https://github.com/oceanprotocol/ocean-node/blob/main/docs/GPU.md) on how to set it up.
**Default Value:** `null` (i.e., no C2D environment provided by the node).
### OE Node Ownership
#### NODE\_OWNER\_INFO
**DOCKER\_COMPUTE\_ENVIRONMENT**
**Description:** Sets information about the owner of the OE Node
**Value:** JSON object.
**Example:** The recommended structure of this field is provided in the example below.
{% code overflow="wrap" %}
```json
{"imprint":{"legalName": "Ocean Enterprise Collective", "email": "info@oceanenterprise.io", "url": "https://www.oceanenterprise.io", "address":"Ocean Enterprise Collective e.V., Carmerstrasse 18, 10623 Berlin, Germany"}, "termsAndConditions":{"url":"https://www.oceanenterprise.io/terms-and-conditions#terms-and-conditions"}, "privacyPolicy":{"url": "https://www.oceanenterprise.io/terms-and-conditions#div-privacy"}
```
{% endcode %}
**Default Value:** `null`
# Marketplace installation and configuration
This chapter describes the installation and configuration of the OE Marketplace
* [Marketplace installation](/infrastructure/marketplace-installation-and-configuration/marketplace-installation)
* [Configure Market-level authentication](/infrastructure/marketplace-installation-and-configuration/configure-market-level-authentication)
* [Configure federated market-level authentication](/infrastructure/marketplace-installation-and-configuration/configure-federated-market-level-authentication)
# Marketplace installation
## Prerequisites
### Hardware requirements
The minimum hardware requirements for the server hosting the marketplace are:
* number of cores: 1
* RAM: 8 GB
* disk: 50 GB
### Software requirements
* **Operating System:** Any Linux distribution supported by the Docker Engine and Docker Compose products. For guidance on compatible platforms, see the [Docker Compose supported platforms](https://docs.docker.com/desktop/setup/install/linux/) and [Docker Engine supported platforms](https://docs.docker.com/engine/install/) documentation
* **Software products:**
* Docker Engine
* Docker Compose
### **Other requirements**
* **Blockchain RPC provider**: Use a service such as Alchemy, Infura, or Chainstack. Ensure that your subscription tier supports a sufficient number of requests per second to meet the marketplace demand.
* **IPFS gateway provider**: Use a gateway such as Pinata, Cloudflare, or Filebase. Verify that your subscription tier provides adequate storage capacity, file limits, and request throughput for your expected workload.
* **OE Node operational**: The marketplace needs an operational OE Node to run properly.
## Pre-installation steps
Make sure you review the [Compatibility Matrix](/infrastructure/compatibility-matrix) to ensure that the version is compatible with the other components.
## Deployment steps
There are two ways of installing and running the market: using Docker Compose or Docker Engine.
### Option 1 - Use Docker Compose to install and run the market
To install and configure the marketplace, perform the following steps:
1. The marketplace repository is located [here](https://github.com/OceanProtocolEnterprise/market). Clone the marketplace repository (alternatively, copy only the `docker-compose.yml` and `.env.example` file from the repository).
```sh
git clone https://github.com/OceanProtocolEnterprise/market.git && cd market
```
2. Copy `.env.example` to `.env`
```sh
cp .env.example .env
```
3. Edit the *.env* file to set the environment variables specific to your configuration (please refer to the [Environment Variables](#environment-variables) chapter for how to set the variables).
```sh
nano .env
```
4. Start the marketplace service
```sh
docker compose up -d
```
The marketplace will start in a Docker container and will be accessible via HTTP on port 8008.
**Note:** This installs the latest available version of the market. To install a specific version, edit the `docker-compose.yml` file and set the desired version tag. If you do so, please verify the Compatibility Matrix.
### Option 2 - Use Docker to install and run the market
To install and configure the marketplace, perform the following steps:
1. The marketplace repository is located [here](https://github.com/OceanProtocolEnterprise/market). Clone the marketplace repository (alternatively, copy only the `.env.example` file from the repository).
```sh
git clone https://github.com/OceanProtocolEnterprise/market.git
```
2. Copy `.env.example` to *`.env`*
```sh
cp .env.example .env
```
3. Edit the *.env* file to set the environment variables specific to your configuration (please refer to the [Environment Variables](#environment-variables) chapter for how to set the variables).
```sh
nano .env
```
4. Start the marketplace service
```sh
docker run --name oe-market --env-file .env -p 8008:8008 -d oceanenterprise/market:latest
```
The marketplace will start in a Docker container and will be accessible via HTTP on port 8008.
## **Post installation steps**
* Deploy the marketplace server behind a reverse proxy responsible for TLS termination and secure request forwarding. The proxy should enforce HTTPS for all external traffic and route decrypted requests to the internal application port.
* Place the marketplace in a network environment that allows outbound communication to the configured OE Node. Depending on your architecture, the marketplace must also be able to reach the default SSI wallet instance and the Policy Server Proxy to function correctly.
## Environment Variables
### OE Node
#### NEXT\_PUBLIC\_PROVIDER\_URL
**Description:** Sets the base URL of the OE Node used by the marketplace. This node will be used by the marketplace to encrypt the asset description at the publishing time, to decrypt the asset description at consumption time, and as the C2D environment provider.
**Values:** string (URL)
**Example:** `https://ocean-node-vm3.oceanenterprise.io/`
**Default Value:** `https://ocean-node-vm3.oceanenterprise.io/`
#### NEXT\_PUBLIC\_METADATACACHE\_URI
**Description:** Sets the base URL of the OE Node where the metadata cache is stored. From this cache, the assets listed in the marketplace's catalogue are read. Set it to the same value as `NEXT_PUBLIC_PROVIDER_URL`.
**Values:** string (URL)
**Example:** `https://ocean-node-vm3.oceanenterprise.io/`
**Default Value:** `https://ocean-node-vm3.oceanenterprise.io/`
#### NEXT\_PUBLIC\_NODE\_URI\_INDEXED
**Description:** Configures the list of OE nodes whose assets will be shown in the marketplace's catalogue. Only the assets published by the OE nodes in this list will be displayed in the catalogue.
**Values:** JSON array of strings (URL)
**Example:** `["https://ocean-node-vm3.oceanenterprise.io/", ""https://ocean-node-vm3.oceanenterprise.io/""]`
**Default Value:** the value of `NEXT_PUBLIC_PROVIDER_URL` variable or `"https://ocean-node-vm3.oceanenterprise.io"`
***
### Blockchain RPC
#### NEXT\_PUBLIC\_NODE\_URI\_MAP
**Description:** Sets the list of blockchains to which the marketplace connects to publish and retrieve assets. Also, for each blockchain, the RPC provider URL is set.
**Values:** JSON map of chainId to RPC URL
**Example:** `{"11155111":"https://eth-sepolia.g.alchemy.com/v2/", "11155420":"https://opt-sepolia.g.alchemy.com/v2/}`
**Default Value:** `{}`
#### NEXT\_PUBLIC\_NODE\_URI
**Description:** Sets the default RPC provider URL when no per-chain override is provided in `NEXT_PUBLIC_NODE_URI_MAP`.
**Values**: string (URL)
**Example:** `https://eth-sepolia-testnet.api.pocket.network/`
**Default Value:** `https://eth-sepolia-testnet.api.pocket.network/`
***
### IPFS
#### NEXT\_PUBLIC\_IPFS\_GATEWAY
**Description:** Sets the URL of the IPFS gateway used to fetch the asset's DDO.
**Values:** String (URL)
**Example:** `https://ipfs.io/`
**Default Value:** `null`
#### NEXT\_PUBLIC\_IPFS\_UPLOAD\_URL
**Description:** Sets the API endpoint that the marketplace uses to upload content to your configured IPFS provider. Consult your IPFS gateway’s documentation to ensure you supply the correct endpoint and required parameters.
**Values:** String (URL)
**Example:** `https:/api.pinata.cloud/pinning/pinJSONToIPFS/`
**Default Value:** `null`
#### NEXT\_PUBLIC\_IPFS\_DELETE\_URL
**Description:** Sets the API endpoint the marketplace uses to request content deletion from your configured IPFS provider. Check your IPFS gateway’s documentation to ensure you provide the correct endpoint and required parameters.
**Values:** String (URL)
**Example:** `https://api.pinata.cloud/pinning/unpin`
**Default Value:** `null`
#### IPFS\_JWT
**Description:** Sets the access key to the IPFS gateway provider account used to upload and retrieve files on IPFS.
**Values:** string (JWT)
**Example:** `eyJhbGciOi...`
**Default Value:** `null`
#### NEXT\_PUBLIC\_IPFS\_UNPIN\_FILES
**Description:** Specifies if an existing license file published in IPFS is deleted or not when a new license file is uploaded
**Values:** `true/false`
**Example:** `true`
**Default Value:** `false`
***
### Currencies and Market Fees
The marketplace can apply two types of fees cumulatively: a fixed fee `(NEXT_PUBLIC_CONSUME_MARKET_ORDER_FEE_MAP)` and a variable, percentage‑based fee `(NEXT_PUBLIC_CONSUME_MARKET_FEE)`. Using both fee types gives the marketplace operator greater flexibility in defining the overall fee policy
#### NEXT\_PUBLIC\_ALLOWED\_ERC20\_ADDRESSES
**Description:** Defines the token address for the currency tokens accepted by the marketplace, for each blockchain the market is connected to.
Ensure that the listed addresses are supported by the O.E.C. smart contracts; unsupported entries will cause asset publishing to fail. Consult [this chapter](/developers/networks) for the latest list of supported currencies. If none of the currency tokens configured in this variable is supported by the O.E.C. smart contracts, an error message is displayed when users connect to the market.
**Values:** JSON map of chainId to a list of token addresses.
**Example:** `{"11155111":["0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4","0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238"]}` i.e., for Sepolia blockchain, the supported currencies are EURC and USDC.
**Default Value:** `{}`
#### NEXT\_PUBLIC\_CONSUME\_MARKET\_ORDER\_FEE\_MAP
**Description:** Defines the fixed market fee applied when an asset is purchased through the marketplace, whether for download or for use in a C2D job. The fee is expressed as an absolute number, written with the number of decimals used by each of the currency tokens defined in `NEXT_PUBLIC_ALLOWED_ERC20_ADDRESSES`.
**Value:** JSON map of chainId to a list of maps (token address to fee value).
**Example:** `{"11155111":[{"token":"0x08210F9170F89Ab7658F0B5E3fF39b0E03C594D4","amount":"2000000"},{"token":"0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238","amount":"1000000"}]}` , i.e., for the Ethereum Sepolia blockchain, the applicable fixed fees are: 2 EURC for assets priced in EURC and 1 USDC for assets priced in USDC.
**Default Value:** `{}`
#### NEXT\_PUBLIC\_CONSUME\_MARKET\_FEE
**Description**: Defines the variable fee applied when an asset is purchased through the marketplace, whether for download or for use in a C2D job. The fee is represented as a decimal value (for example, `0.1` corresponds to a `10%` fee, and `1` corresponds to a `100%` fee). This fee is applied to all prices, regardless of the currency.
**Example:** `0.15`, meaning that a variable fee of 15% of the asset price is applied.
**Default Value:** `0`
#### NEXT\_PUBLIC\_MARKET\_FEE\_ADDRESS
**Description:** Defines the address where the market fees are collected.
**Example:** `0x0db00a90deee402256cb1df89f3e14d6b9130fdd`
**Default Value:** OEC Fee Collector address
***
### SSI
#### NEXT\_PUBLIC\_SSI\_ENABLED
**Description:** Whether the SSI-based access control is active or not in the marketplace. If the OE Node used by the marketplace (the one listed in the `NEXT_PUBLIC_PROVIDER_URL` variable) has SSI-based access control activated (i.e., the variable `POLICY_SERVER_URL` is not null), then this variable must be set to `true`. If not, this variable must be set to `false`.
**Values:** `true/false`
**Example:** `true`
**Default Value:** `false`
#### NEXT\_PUBLIC\_SSI\_POLICY\_SERVER
**Description:** Used only if `NEXT_PUBLIC_SSI_ENABLED=true`. Sets the base URL of the Policy Server used by the marketplace. The value must be the same as that set in the POLICY\_SERVER\_URL of the node used by the marketplace (the one listed in the `NEXT_PUBLIC_PROVIDER_URL` variable)
**Values:** string (URL)
**Example:** `https://ocean-node-vm3.oceanenterprise.io`
**Default Value:** `null`
#### NEXT\_PUBLIC\_SSI\_WALLET\_API
**Description:** Used only if `NEXT_PUBLIC_SSI_ENABLED=true`. Sets the base URL of the default SSI wallet instance. When users log in to the marketplace, this is the default SSI wallet to which they connect, in case they don't provide their own wallet instance URL.
**Values:** string (URL)
**Example:** `https://wallet.demo.oceanenterprise.io`
**Default Value:** `null`
#### NEXT\_PUBLIC\_SSI\_DEFAULT\_POLICIES\_URL
**Description:** Used only if `NEXT_PUBLIC_SSI_ENABLED=true`. Sets the URL from where the list of default static policies that will be applied to all requested Verifiable Credentials is read. The URL must contain a list of valid static policies, one policy per line. For reference, see
**Values:** string (URL)
**Example:** `https://raw.githubusercontent.com/OceanProtocolEnterprise/policy-server/refs/heads/main/default-verification-policies`
**Default Value:** `null`
#### NEXT\_PUBLIC\_OPA\_SERVER\_URL
**Description:** Used only if `NEXT_PUBLIC_SSI_ENABLED=true`. Sets the base URL of the OPA Server used by the verifier for custom SSI policies evaluation.
**Values:** string (URL)
**Example:** `http://ocean-node-vm3.oceanenterprise.io:8181`
**Default Value:** `null`
***
### Dataspace
#### NEXT\_PUBLIC\_DATASPACE
**Description:** Sets the identifier of the dataspace associated with the marketplace. This has two effects:
* All assets published through the marketplace will automatically receive this dataspace identifier.
* The marketplace will display only the assets whose dataspace identifier matches this value.
By default, the value of this variable is set to `null`. In this state, no filtering is applied to the assets displayed, and no dataspace identifier is added to an asset’s description
**Values:** string
**Example:** `"oceanenteprise"`
**Default Value:** `null`
### Market-level authentication
#### NEXT\_PUBLIC\_AUTH\_ENABLED
**Description:** Sets the marketplace user authentication. If true, user authentication is enabled; if false, user authentication is disabled.
**Values:** boolean
**Example:** `true`
**Default Value:** `false`
#### NEXT\_PUBLIC\_AUTH\_PROVIDER
**Description:** If marketplace authentication is enabled, this variable sets the authentication method. Currently, the only accepted method is OIDC.
**Values:** string
**Example:** `oidc`
**Default Value:** `oidc`
#### NEXT\_PUBLIC\_OIDC\_ISSUER
**Description:** Sets the URL of the OIDC Identity Provider that verifies user identity and issues security tokens (ID tokens) for authentication.
**Values:** string (URL)
**Example:** `https://idpserver.oceanenteprise.io/application/o/market-demo`
**Default Value:** `null`
#### NEXT\_PUBLIC\_OIDC\_CLIENT\_ID
**Description:** Sets OIDC client ID for the marketplace application. This value is defined on the OIDC Identity Provider when the configuration for the marketplace application is created.
**Values:** string
**Example:** `4abc8afdda73b95545b9a`
**Default Value:** `null`
#### OIDC\_CLIENT\_SECRET
**Description:** Sets OIDC client secret for the marketplace application. This value is defined on the OIDC Identity Provider when the configuration for the marketplace application is created.
**Values:** string
**Example:** `4cec8afdse3401j438943u4`
**Default Value:** `null`
#### NEXT\_PUBLIC\_OIDC\_SIGNUP\_FLOW
**Description:** Sets the name of the sign-up flow defined in the Authentik server that will be run to register users to the marketplace.
**Value:** string
**Example:** `demo-market-signup-flow`
Default Value: `null`
### Legal Docs
#### NEXT\_PUBLIC\_IMPRINT\_URL
**Description:** Sets the URL from where the Imprint document will be read. The document must be in Markdown format. If this environment variable is set to null, the marketplace will use the default OEC Imprint document.
**Value:** string (URL)
**Example:** `https://raw.githubusercontent.com/OceanProtocolEnterprise/legaldocs/refs/heads/main/market/Imprint.md`
Default Value: `null`
#### NEXT\_PUBLIC\_TC\_URL
**Description:** Sets the URL from where the Terms and Conditions document will be read. The document must be in Markdown format. If this environment variable is set to null, the marketplace will use the default OEC Terms and Conditions document.
**Value:** string (URL)
**Example:** `https://raw.githubusercontent.com/OceanProtocolEnterprise/legaldocs/refs/heads/main/market/TermsAndConditions.md`
Default Value: `null`
#### NEXT\_PUBLIC\_PP\_URL
**Description:** Sets the URL from where the Privacy Policy document will be read. The document must be in Markdown format. If this environment variable is set to null, the marketplace will use the default OEC Privacy Policy document.
**Value:** string (URL)
**Example:** `https://raw.githubusercontent.com/OceanProtocolEnterprise/legaldocs/refs/heads/main/market/PrivacyPolicy.md`
Default Value: `null`
#### NEXT\_PUBLIC\_CP\_URL
**Description:** Sets the URL from where the Cookie Policy document will be read. The document must be in Markdown format. If this environment variable is set to null, the marketplace will use the default OEC Cookie Policy document.
**Value:** string (URL)
**Example:** `https://raw.githubusercontent.com/OceanProtocolEnterprise/legaldocs/refs/heads/main/market/CookiePolicy.md`
Default Value: `null`
#### NEXT\_PUBLIC\_DPUA\_URL
**Description:** Sets the URL from where the Data Portal Usage Agreement document will be read. The document must be in Markdown format. If this environment variable is set to null, the marketplace will use the default OEC Data Portal Usage Agreement document.
**Value:** string (URL)
**Example:** `https://raw.githubusercontent.com/OceanProtocolEnterprise/legaldocs/refs/heads/main/market/DataPortalUsageAgreement.md`
Default Value: `null`
### Others
#### NEXT\_PUBLIC\_ENCRYPT\_ASSET
**Description:** Defines whether the asset's DDO is encrypted at publishing time
Values: `true/false`
**Example:** `true`
**Default Value:** `false`
#### NEXT\_PUBLIC\_HIDE\_ONBOARDING\_MODULE\_BY\_DEFAULT
**Description:** Defines whether or not the onboarding guide is hidden for new users. By default, the onboarding guide is displayed. By setting this variable to `true`, The onboarding guide is not displayed by default.
**Value:** `true/false`
**Example:** `true`
**Default Value:** `false`
#### NEXT\_PUBLIC\_SSI\_UI\_URL
**Description:** Defines the URL of the SSI wallet user interface provided by the marketplace operator. This URL is used in the onboarding guide to direct participants to the interface where they can add the DIDs and VCs required to access dataspace assets.
**Value:** string (URL)
**Example:** `https://wallet2-ui.oceanenterprise.io`
**Default Value:** `null`
# Configure market-level authentication
## Introduction
For dataspaces where controlling access to resources is essential, operators can enable user authentication on the marketplace to ensure that only verified participants interact with sensitive data and services. The Ocean Enterprise Marketplace supports secure, standards‑based authentication through OpenID Connect (OIDC).
We used the Authentik server (available at ) as the Identity Provider (IdP) for the OE Marketplace, handling:
* User authentication
* User registration
* Session management
* Single Sign-On (SSO)
* Single Logout (SLO)
Once configured, users can securely access the marketplace using the credentials registered in Authentik. The following diagram shows the OIDC authentication flow between the user, Ocean Market, and Authentik.
In this configuration, there is a single Authentik server where users reside. The OE Marketplace is configured to use the Authentik server as the OpenID Provider.
* When the user accesses the OE Marketplace via the browser (step 1), OE Marketplace prepares a URL with parameters for the Authentik server, which the user's browser is redirected to (step 2)
* The Authentik server authenticates the user (step 3) and generates an authorization code
* The Authentik server then redirects the client (the user's browser) back to the OE Marketplace, along with that authorization code (step 4). In the background, the OE Marketplace then sends that same authorization code in a request authenticated by the `client_id` and `client_secret` to the Authentik server. Finally, the Authentik server responds by sending an Access Token, saying this user has been authorized, and optionally a Refresh Token.
This guide explains how to configure Authentik as the OpenID Connect (OIDC) Identity Provider for the Ocean Enterprise Marketplace. The configuration consists of:
1. Creating an OIDC Provider
2. Creating an Application
3. Connecting the Application to Ocean Market
4. Verifying the OIDC endpoints
## Preconditions
Before starting, ensure:
* Authentik is installed and accessible (see ). Make sure it is configured with a qualified digital certificate.
* Ocean Market frontend is deployed (see [this chapter](/infrastructure/marketplace-installation-and-configuration/marketplace-installation))
* You have administrator access to Authentik.
* You know your Ocean Market callback URL.\
Example callback URL: `https://market.example.com/auth/callback`
## Steps
* [Configure the Authentik provider and application](/infrastructure/marketplace-installation-and-configuration/configure-market-level-authentication/configure-the-authentik-provider-and-application)
* [Configure the marketplace to use OIDC authentication](/infrastructure/marketplace-installation-and-configuration/configure-market-level-authentication/configure-the-oe-marketplace-to-use-oidc-authentication)
* [Authentication Flows and User Enrollment in Authentik](/infrastructure/marketplace-installation-and-configuration/configure-market-level-authentication/configure-authentication-and-user-enrollment-flows-in-authentik)
* [Configure User Groups and Application Access Control](/infrastructure/marketplace-installation-and-configuration/configure-market-level-authentication/configure-user-groups-and-application-access-control)
# Configure the Authentik provider and application
## Log in to the Authentik Admin console
1\. Open your Authentik admin panel
Example: `https://your-authentik-domain:8443`
2\. Log in using an administrator account.
## Create an OAuth2 / OIDC provider
1\. In the Authentik admin panel, navigate to `Applications → Providers`
2\. Select `Create`
3\. Select `OAuth2 / OpenID Provider`
## Configure the provider
4\. Press Next and enter the following configuration:
**Basic Configuration**
* Name: `ocean-market-provider`
* Authorization Flow: `default-provider-authorization-implicit-consent`
***
**Protocol settings**
* Client Type: `Confidential`
* Client ID: Use the generated value
* Client Secret: Use the generated value
* Redirect URIs
* Add the Ocean Market callback URL: `https://market.example.com/auth/callback`
* Use `Strict Matching`
* Signing Key: select the key associated with the qualified certificate configured in Authentik
***
**Advanced flow settings**
* Authentication flow: `default-authentication-flow`
* Invalidation flow: use the default setting
***
**Advanced protocol settings**
* Scopes: add the following to Selected Scopes
* openid
* profile
* email
* offline\_access
These scopes allow OE Marketplace to retrieve user identity information
***
5\. Click Finish to save the provider
***
## Create the Ocean Market Application
1\. Navigate to `Applications->Applications`
2\. Click Create and enter the following information:
* Application Name: `Ocean Market`
* Slug:`ocean-market`
* Provider: `ocean-market-provider`
3\. Click Create
***
## Retrieve OIDC Credentials
1\. Click the created provider
2\. Copy the following values
* Client ID
* Client Secret (displayed only in Edit mode)
* OpenID Configuration Issuer (example: `https://ocean-node-vm2.oceanenterprise.io:8443/application/o/ocean-market/`)
* OpenID Token URL (example: `https://ocean-node-vm2.oceanenterprise.io:8443/application/o/token/`)
These values are required in the Ocean Market environment configuration.
***
## Verify the OIDC Configuration
1\. Open the provider discovery endpoint (`https://your-authentik-domain:8443/application/o/ocean-market/.well-known/openid-configuration`)
2\. If configured correctly, Authentik returns the OIDC metadata as JSON. This confirms that the provider is correctly configured.
# Configure the OE marketplace to use OIDC authentication
## Configure OE Market Environment Variables
1\. Add the following environment variables to OE Marketplace (in the `.env` file):
{% code overflow="wrap" %}
```shellscript
EXT_PUBLIC_AUTH_ENABLED=true
NEXT_PUBLIC_AUTH_PROVIDER=oidc
NEXT_PUBLIC_OIDC_ISSUER=
NEXT_PUBLIC_OIDC_CLIENT_ID=
OIDC_CLIENT_SECRET=
NEXT_PUBLIC_OIDC_REDIRECT_URI=
NEXT_PUBLIC_OIDC_TOKEN_URL=
NEXT_PUBLIC_OIDC_SIGNUP_FLOW= # Optional: only needed if your OIDC provider has a separate signup flow
```
{% endcode %}
2\. Restart the OE Marketplace with the new environment variables
## Expected results
After completing this configuration:
1. Users can log in from Ocean Market.
2. Authentik authenticates the user.
3. The user is redirected back to OE Market.
4. OE Market receives the OIDC tokens and creates the session.
# Configure authentication and user enrollment flows in Authentik
This guide explains how to configure authentication flows in Authentik for Ocean Market.
The flow configuration defines how users:
* Log in to Ocean Market
* Register new accounts
* Complete user enrollment
* Start authenticated sessions
By the end of this guide, users will be able to:
* Sign in using existing credentials
* Create accounts through self-service registration
* Be automatically redirected back to Ocean Market after authentication
## Preconditions
Before starting, ensure the following requirements are met:
* Authentik Provider and Application are already configured
* Ocean Market OIDC integration is working.
* The provider uses: `default-authentication-flow`
## Steps
### 1. Configure the Login Flow
The OE Market uses Authentik’s authentication flow to handle user login.
1\. Navigate to `Flows and Stages -> Flows`
2\. Open `default-authentication-flow` . This flow is used by the OIDC provider created in the previous guide.
3\. Select Stage Bindings and Edit `default-authentication-identification` (Type Identification Stage).
4\. Configure the following:
* Stage-specific settings
* User fields: check `Username` and `Email`. This allows users to log in using either their username or email address.
* Password Stage: `default-authentication-password`
This allows users to log in using either their username or email address.
5\. Save the changes.
\
6\. In the Stage Binding view, make sure the flow includes the `default-authentication-mfa-validation` and `default-authentication-login` stages, as shown in the image below.
### 2. Configure the Registration Flow
To allow users to create accounts without administrator intervention, create a self-service registration flow.
#### Create the registration flow
1\. Navigate to `Flows & Stages → Flows → Create`
2\. In the Create Flow form, configure the following attributes:
* Name: `self-service-registration`
* Title: `Sign-up`
* Slug: `self-service-registration`
* Designation: `Enrollment`
3\. Click `Create`.
#### Add registration stages to the registration flow
1\. Open the newly created flow
2\. Navigate to `Stage Bindings`
3\. Add the following stages in this order by pressing `Bind Existing Stage`:
* Stage name: `default-source-enrollment-prompt`. This stage identifies the new user.
* Type: `Prompt Stage`
* Order: `10`
* Within this stage, configure the following fields:
* **Stage-specific settings**
* *Fields*: select the following attributes:
* Username (`default-user-settings-field-username`);
* Email (`default-user-settings-field-email`);
* Name (`default-user-settings-field-name`);
* Password (`default-user-settings-field-password`);
* Re-enter password (`default-user-settings-field-password-repeat`);
* Stage name: `default-source-enrollment-write`. This stage creates the user account in Authentik.
* Type: `User Write Stage`
* Order: `20`
* Within this stage, configure the following fields:
* **Stage-specific settings**
* Select `Create users when required`
* Select `Create users as inactive`
* User Type: `Internal`
* Do not configure policies or group assignments at this stage
* Stage name: `email-account-confirmation`. This stage creates the user account in Authentik.
* Type: `Email Stage`
* Order: `30`
* Within this stage, configure the following fields:
* **Stage-specific settings**
* Select `Activate pending users on success`
* Template: `Account Confirmation`
* **Connection settings**
* In case you didn't set the SMTP configuration at the Authentik server level, you can set the parameters in this group
\
4\. Add the following stage by pressing `Create and bind Stage`
* Stage name: `after-signup-redirect`. This stage redirects the user to the application login page.
* Type: `Redirect Stage`
* Order: `40`
* Within this stage, configure the following fields:
* **Stage-specific settings**
* Mode: `Static`
* Target URL: the login URL of the marketplace (i.e. `https://market.demo.oceanenterprise.io/auth/login`)
In the end, the stages of the registration flow should look similar to the image below.
### 3. Enable Sign-Up on Login Screen
1\. Open `default-authentication-flow`
2\. Navigate to `Stage Bindings` and edit `default-authentication-identification` (Identification Stage)
3\. Configure the following fields:
* **Flow Settings**
* Enrollment Flow: `self-service-registration`
4\. Press Update to save the changes.
### 4. Test the configuration
To test the configuration, perform the following:
**User login test:**
* Open Ocean Market login page
* Click Login with Authentik
* Authenticate
* Verify the user is redirected back to Ocean Market
**User Registration test:**
* Open Ocean Market signup page
* Click Sign up with Authentik
* Create a new account
* Verify the user is created in Authentik
* Verify successful login and redirect back to Ocean Market
**Expected Result**
* After completing this configuration:
* Existing users can log in
* New users can self-register
* Users are automatically authenticated
* Ocean Market receives the OIDC token and creates the session
# Configure User Groups and Application Access Control
This guide explains how to configure user groups and access control in Authentik for Ocean Market.
In Authentik, user groups allow administrators to:
* Organize users by role
* Control application access
* Assign administrative privileges
* Manage marketplace permissions
By the end of this guide, administrators will be able to:
* Create user groups
* Assign users to groups
* Restrict access to Ocean Market
* Separate administrative users from standard users
## Access Control Model
Ocean Market uses role-based access control through Authentik groups.
The recommended initial structure is:
| **Group** | **Purpose** |
| ------------------ | -------------------------- |
| marketplace-users | Standard marketplace users |
| marketplace-admins | Marketplace administrators |
Standard users can access the marketplace and perform normal operations.
Administrative users can access the marketplace and manage platform operations.
## Preconditions
Before starting, ensure the following requirements are met:
* Authentik Provider and Application are configured.
* Authentication and registration flows are working.
* Users can successfully log in to Ocean Market.
## Steps
### 1. Create a standard user group
1\. Navigate to `Directory → Groups` and click New Group.
2\. Configure the following attributes:
* Name: `marketplace-users`
* Parent: Leave empty
* Attributes: Leave the default values unless custom metadata is required
3\. Click `Create Group`
### 2. Create an administrator group
1\. Navigate to `Directory → Groups` and click New Group.
2\. Configure the following attributes:
* Name: `marketplace-admins`
* Parent: Leave empty
* Attributes: Leave the default values unless custom metadata is required
3\. Click `Create Group`
### 3. Assign existing users to groups
1\. Navigate to `Directory → Users`
2\. Click a user name to open the user details page
3\. Select the `Groups` tab
4\. Click `Add to existing group`
5\. Click the plus sign to open the list of groups
6\. From the list, select `marketplace-users` for a standard user or `marketplace-admins` for an administrator
7\. Click `Add` to assign the user to the group. The list of groups will close.
8\. Click `Add` in the Add Group window to save the changes.
### 4. Automatic group assignment during user signup
To automatically assign new users to a marketplace group during registration, do the following:
1\. Navigate to `Flows & Stages → Flows` and select the sign-up flow created earlier (`self-service-registration`)
2\. Select the `Stage Bindings` tab
3\. Edit `User Write Stage`
4\. Configure the following field:
Group: `marketplace-users`
5\. Click `Update` to save the stage.
This ensures that every new user created through self-service registration automatically receives marketplace access.
### 5. Restrict Application Access
To allow only users in the `marketplace-users` group to access the Ocean Market application, do the following:
1\. Navigate to `Applications → Applications`
2\. Open `Ocean Market`
3\. Select the `Policies / Group / User Bindings` tab
4\. Click `Bind existing Policy / Group / User`
5\. In the `Create Binding` window, select the `Group` tab
6\. In the `Group` field, select the `marketplace-users` group that should have access to the application. Leave the other fields with their default values.
7\. Click `Create` to save the changes.
# Configure federated market-level authentication
WORK IN PROGRESS
# SSI Stack installation and configuration
The SSI stack used in Ocean Enterprise is based on the [walt.id Identity Infrastructure Community Stack](https://walt.id/identity-infrastructure). The following software components of the Identity Infrastructure are used in Ocean:
* SSI Wallet: API endpoints that implement SSI wallet functionality (managing DIDs and VCs, presenting VCs).
* SSI Wallet User Interface: The graphical interface for the wallet APIs, allowing users to manage DIDs and VCs.
* SSI Verifier: API endpoints that implement the SSI verifier functionality (initiate OIDC presentation sessions, verify the responses for a verification request, get information about OIDC presentation sessions)
* OPA server: API endpoints of the policy engine, used for custom policy evaluation
## Prerequisites
### Hardware requirements
The minimum hardware requirements for the server hosting the SSI stack components are:
* number of cores: 1
* RAM: 4 GB
* disk: 25 GB
### Software requirements
* **Operating System:** Any Linux distribution supported by the Docker Engine and Docker Compose products. For guidance on compatible platforms, see the [Docker Compose supported platforms](https://docs.docker.com/desktop/setup/install/linux/) and [Docker Engine supported platforms](https://docs.docker.com/engine/install/) documentation
* **Software products:**
* Docker Engine
* Docker Compose
* git
## Pre-installation steps
Make sure you review the [Compatibility Matrix](/infrastructure/compatibility-matrix) to ensure that the version is compatible with the other components.
Before installing the SSI stack components, determine the network segments where each service will run. Consider the following communication requirements:
* The verifier-api must be able to reach both the Policy Server and the OPA Server.
* The wallet-api must be able to communicate with the waltid-dev-wallet and the Policy Server Proxy
Depending on your configuration, you can choose to deploy all SSI components on a single server or deploy individual components on separate servers.
## Deployment steps
### Option 1 - Deploy the entire SSI stack
To install and configure the SSI stack, perform the following steps:
1. The OE version of the SSI stack is located [here](https://github.com/OceanProtocolEnterprise/waltid-identity/). Clone the repository.
```shellscript
git clone https://github.com/OceanProtocolEnterprise/waltid-identity.git && cd waltid-identity
```
2. Switch to the `OE` branch.
```shellscript
git checkout OE
```
3. Change the current directory to `docker-compose`
```shellscript
cd docker-compose
```
4. Start the Docker SSI services containers
```shellscript
docker compose up -d
```
This command will pull the correct versions of the Docker images used by OE and start the containers. This command will also start other services not used by the OE stack, such as the web portal, the issuer, and the demo wallet.
Note: the OPA server is not automatically started by this command.
5. Start the OPA server.
```shellscript
docker compose up opa-server -d
```
### Option 2 - Deploy an individual component
Each component is defined as a service in the `docker-compose.yaml` file, as follows:
* `wallet-api`: SSI Wallet
* `waltid-dev-wallet`: SSI Wallet User Interface
* `verifier-api`: SSI Verifier
* `opa-server`: OPA Server
To deploy an individual component, perform the following steps:
1. The OE version of the SSI stack is located [here](https://github.com/OceanProtocolEnterprise/waltid-identity/). Clone the repository.
```shellscript
git clone https://github.com/OceanProtocolEnterprise/waltid-identity.git && cd waltid-identity
```
2. Switch to the `OE` branch.
```shellscript
git checkout OE
```
3. Change the current directory to `docker-compose`
```shellscript
cd docker-compose
```
4. Start the service. For instance, to start the `wallet-api` service, run the following command
```shellscript
docker compose up wallet-api -d
```
This command pulls the appropriate version of the component’s Docker image and starts its container.
## **Post installation steps**
* Deploy the SSI stack components behind a reverse proxy responsible for TLS termination and secure request forwarding. The proxy should enforce HTTPS for all external traffic and route decrypted requests to the internal application port.
* After installation, the components work seamlessly with the rest of the OE stack and require no additional configuration. However, for advanced configuration or ongoing maintenance of the SSI Stack components, consult the official [walt.id documentation](https://docs.walt.id/community-stack/home).
## TCP ports
The following TCP ports are used by default by the SSI stack components:
* wallet-api: 7001
* waltid-dev-wallet: 7104
* verifier-api:7003
* opa-server: 8181
You can change the ports by editing the `/docker-compose/.env` file.
# Policy Server and Policy Server Proxy installation and configuration
## Prerequisites
### Hardware requirements
The minimum hardware requirements for the server hosting the marketplace are:
* number of cores: 1
* RAM: 2 GB
* disk: 0.5 GB
### Software requirements
* **Operating System:** Any Linux distribution supported by the Docker Engine and Docker Compose products. For guidance on compatible platforms, see the [Docker Compose supported platforms](https://docs.docker.com/desktop/setup/install/linux/) and [Docker Engine supported platforms](https://docs.docker.com/engine/install/) documentation
* **Software products:**
* Docker Engine
* Docker Compose
## Pre-installation steps
Make sure you review the [Compatibility Matrix](/infrastructure/compatibility-matrix) to ensure that the version is compatible with the other components.
## Deployment steps
There are two ways to install and run the Policy Server: using Docker Compose or the Docker Engine.
### Option 1 - Use Docker Compose to install and run the Policy Server
To install and configure the Policy Server, perform the following steps:
1. The Policy Server repository is located [here](https://github.com/OceanProtocolEnterprise/policy-server).
```shellscript
git clone https://github.com/OceanProtocolEnterprise/policy-server.git && cd policy-server
```
2. Change the current directory to `docker-compose` .
```shellscript
cd docker-compose
```
3. Copy `.env.example` to `.env`
```sh
cp .env.example .env
```
4. Edit the `.env` file to set environment variables specific to your configuration (please refer to the [Environment Variables](#environment-variables) chapter for how to set them).
```sh
nano .env
```
5. Start the Policy Server service
```sh
docker compose up -d
```
The Policy Server will start in a Docker container and will be accessible via HTTP on port 8001 on the host system.
### Option 2 - Use Docker to install and run the Policy Server
To install and configure the marketplace, perform the following steps:
1. The Policy Server repository is located [here](https://github.com/OceanProtocolEnterprise/policy-server).
```shellscript
git clone https://github.com/OceanProtocolEnterprise/policy-server.git && cd policy-server
```
2. Copy `.env.example` to `.env`
```sh
cp .env.example .env
```
3. Edit the `.env` file to set environment variables specific to your configuration (please refer to the [Environment Variables](#environment-variables) chapter for how to set them).
```sh
nano .env
```
4. Start the Policy Server service.
```sh
docker run --name policy-server --env-file .env -p 8001:3000 -v ./certs:/etc/ssl/certs:ro -d oceanenterprise/policy-server:latest
```
The Policy Server will start in a Docker container and will be accessible via HTTP on port 8001 on the host system.
## **Post installation steps**
* Deploy the policy server behind a reverse proxy responsible for TLS termination and secure request forwarding. The proxy should enforce HTTPS for all external traffic and route decrypted requests to the internal application port.
* Place the policy server in a network environment that allows outbound communication to the configured OE Node and SSI Verifier.
## Environment Variables
### Operation Mode
The Policy Server component can run in two modes:
* as an actual Policy Server: implements the Policy Server functionality, as described [here](/developers/oe-software-stack-components#policy-server);
* as a Policy Server Proxy: implements the Policy Server Proxy functionality, as described [here](/developers/oe-software-stack-components#policy-server-proxy).
**Note**: While both modes can run within the same component, deploying them on separate servers is recommended to clearly isolate front‑end traffic from back‑end traffic.
#### MODE\_PS
**Description:** Indicates whether Policy Server mode is enabled.
* Value `"1"`: the Policy Server mode is enabled
* Value `"0"`: the Policy Server mode is disabled
**Values:** string (`"1"` or `"0"`)
**Example:** `"1"`
**Default Value:** `N/A`
#### MODE\_PROXY
**Description:** Indicates whether Policy Server Proxy mode is enabled.
* Value `"1"`: the Policy Server Proxy mode is enabled
* Value `"0"`: the Policy Server Proxy mode is disabled
**Values:** string (`"1"` or `"0"`)
**Example:** `"1"`
**Default Value:** `N/A`
### OE Node
#### OCEAN\_NODE\_URL
**Description:** Sets the base URL of the OE Node used by the policy server. The policy server will receive authorization requests from this OE Node and will send back either an authorization response (allow/deny) or other messages received from the Verifier. Make sure the OE Node has the corresponding `POLICY_SERVER_URL` variable set to the policy server's URL.
**Values:** string (URL)
**Example:** `https://ocean-node-vm3.oceanenterprise.io/`
**Default Value:** `N/A`
### SSI Verifier
#### AUTH\_TYPE
**Description:** Sets the type of authorization used by the policy server. The only possible value now is `waltid`, meaning that the authorization is based on the walt.id Identity Suite components.
**Values:** string
**Example:** `waltid`
**Default Value:** `waltid`
#### WALTID\_VERIFIER\_URL
**Description:** Sets the base URL of the verifier component used by this policy server. For an access request to an asset, the policy server forwards the requested credentials and the verification policies to the verifier component, which initiates a presentation session.
**Values:** string (URL)
**Example:** `https://verifier2.demo.oceanenterprise.io/`
**Default Value:** `N/A`
### Policy Server Proxy
#### WALTID\_VERIFY\_RESPONSE\_REDIRECT\_URL
**Description:** Sets the redirect URL for the verify calls performed by the SSI Wallet. The URL must include the base URL of the Policy Server Proxy, followed by `/verify/\$id`.
**Values:** string (URL)
**Example:** `https://psproxy1.demo.oceanenterprise.io/verify/\$id/`
**Default Value:** `N/A`
#### WALTID\_VERIFY\_PRESENTATION\_DEFINITION\_URL
**Description:** Sets the redirect URL for the presentation definition calls performed by the SSI Wallet. The URL must include the base URL of the Policy Server Proxy, followed by `/pd/\$id`.
**Values:** string (URL)
**Example:** `https://psproxy1.demo.oceanenterprise.io/pd/\$id/`
**Default Value:** `N/A`
### Default Verification Policies
The Policy Server can be configured to apply additional static verification policies beyond those provided by the OE Node in a verification request. The verification policies can be applied to the Verifiable Credential presented by the SSI Wallet or to the Verifiable Presentation that embeds the Verifiable Credentials submitted by the SSI Wallet.
The list of static verification policies is available [here](https://docs.walt.id/community-stack/verifier/credential-verification/policies/static-verification-policies).
#### DEFAULT\_VC\_POLICIES
**Description:** Sets the default static policies applied to the Verifiable Credentials submitted by the SSI Wallet for verification.
**Values:** list of strings
**Example:** `"expired","signature","revoked-status-list","not-before"`
**Default Value:** `[]`
#### DEFAULT\_VP\_POLICIES
**Description:** Sets the default static policies applied to the Verifiable Presentation submitted by the SSI Wallet for verification.
**Values:** list of strings
**Example:** `"expired","signature","revoked-status-list","not-before"`
**Default Value:** `[]`
### SSI Verification Response
#### WALTID\_SUCCESS\_REDIRECT\_URL
**Description:** Sets the redirect URL to return when all verification policies are passed.
**Values:** string (URL)
**Example:** `"https://example.com/success?id=$id"`
**Default Value:** `""`
#### WALTID\_ERROR\_REDIRECT\_URL
**Description:** Sets the redirect URL to return when a verification policy failed.
**Values:** string (URL)
**Example:** `"https://example.com/error?id=$id"`
**Default Value:** `""`
### Action Validation based on web3 address
This group of variables configures the policy server to validate certain OE Node actions by checking the Web3 addresses of both the node and the consumer initiating the request.
When configured with a Policy Server, the OE Node calls it to validate certain actions, passing the OE Node's address from which the action request was received and the consumer's address that initiated the request.
The following actions are validated against the lists described in this section: `encrypt`, `decrypt`, `initiate`, `download`, and `startCompute`.
#### POLICY\_SERVER\_NODE\_ACCESS\_LIST
**Description:** Sets the list of OE Nodes web3 addresses from which the action requests are accepted.
The policy server compiles the list of accepted nodes by merging the list in this environment variable and the list retrieved from `POLICY_SERVER_NODE_ACCESS_LIST_URL`. If the resulting list is null, action validation based on the OE Node's address is disabled. If it's not null, only action requests coming from nodes in this list are accepted.
**Values:** list of strings (comma separated)
**Example:** `"0x1111,0x2222"`
**Default Value:** `null`
#### POLICY\_SERVER\_NODE\_ACCESS\_LIST\_URL
**Description:** Sets the URL from where the list of node web3 addresses from which the action requests are accepted is loaded. The web3 addresses listed here must be separated by a new line character (one address per line).
The policy server compiles the list of accepted nodes by merging the list retrieved from this variable and the list defined in `POLICY_SERVER_NODE_ACCESS_LIST`. If the resulting list is null, action validation based on the OE Node's address is disabled. If it's not null, only action requests coming from nodes in this list are accepted.
**Values:** string (URL)
**Example:** `https://raw.githubusercontent.com/MBadea17/testdata/refs/heads/main/trustedNodes`
**Default Value:** `null`
#### POLICY\_SERVER\_CONSUMER\_ACCESS\_LIST
**Description:** Sets the list of consumer web3 addresses from which the action requests are accepted.
The policy server compiles the list of accepted consumers by merging the list in this environment variable and the list retrieved from `POLICY_SERVER_CONSUMER_ACCESS_LIST_URL`. If the resulting list is null, action validation based on the consumer's address is disabled. If it's not null, only action requests coming from consumers in this list are accepted.
**Values:** list of strings (comma separated)
**Example:** `"0x3333,0x4444"`
**Default Value:** `null`
#### POLICY\_SERVER\_CONSUMER\_ACCESS\_LIST\_URL
**Description:** Sets the URL from where the list of consumers' web3 addresses from which the action requests are accepted is loaded. The web3 addresses listed here must be separated by a new line character (one address per line).
The policy server compiles the list of accepted consumers by merging the list retrieved from this variable and the list defined in `POLICY_SERVER_CONSUMER_ACCESS_LIST`. If the resulting list is null, action validation based on the consumer's address is disabled. If it's not null, only action requests coming from consumers in this list are accepted.
**Values:** string (URL)
**Example:** `https://raw.githubusercontent.com/MBadea17/testdata/refs/heads/main/trustedNodes`
**Default Value:** `null`
####
### Logs
#### ENABLE\_LOGS
**Description:** Indicates whether the logging is enabled.
* Value `"1"`: logging is enabled
* Value `"0"`: logging is disabled
**Values:** string (`"1"` or `"0"`)
**Example:** `"1"`
**Default Value:** `"0"`
### TCP Port
#### PORT
**Description:** Defines the port on which the application listens inside the container. In the `docker-compose.yml` file, the host port 8001 is mapped to the default container port (3000). In case you changed the default value, make sure you update the port mapping in the `docker-compose.yml` file.
**Values:** number
**Example:** `3000`
**Default Value:** `3000`
### API Requests Authentication
#### POLICY\_SERVER\_API\_KEY
**Description:** Defines the key used by the Policy Server to authenticate requests. If no value is provided, request authentication is disabled. If a key is provided, use the same key in the [POLICY\_SERVER\_API\_KEY ](/infrastructure/oe-node-installation-and-configuration#policy_server_api_key) variable of the corresponding OE Node.
**Values:** string
**Example:** `mrgcorhTzA1Ey2WRhZAK8tkw4zBrIgQ757toUz3fXvfHh8Ua`
Defaul Value: `null` (request authentication disabled)
#### ADMIN\_API\_KEY
**Description:** Sets the API key that protects the administrative endpoints of the Policy Server. The caller must set this value in the `X-API-KEY` header to be authenticated. If the value is null, key authentication is disabled.
The administrative endpoints of the Policy Server are:
* **`listAcceptedNodes`**: list the web3 addresses of the accepted OE Nodes (from `POLICY_SERVER_NODE_ACCESS_LIST` and `POLICY_SERVER_NODE_ACCESS_LIST_URL`)
* **`listAcceptedConsumers`**: list the web3 addresses of the accepted consumers (from `POLICY_SERVER_CONSUMER_ACCESS_LIST` and `POLICY_SERVER_CONSUMER_ACCESS_LIST_URL`)
* **`reloadAcceptedNodes`** : reload the lists from `POLICY_SERVER_NODE_ACCESS_LIST_URL`
* **`reloadAcceptedConsumers`** : reload the lists from `POLICY_SERVER_CONSUMER_ACCESS_LIST_URL`.
**Values:** string
**Example:** `abcd1234`
**Default Value:** `null`
### HTTPS connection
Set the following environment variables to enable HTTPS connections on the Policy Server.
**Note**: The Policy Server start commands shown in this guide mount the `certs` directory from the repository into the container at `/etc/ssl/certs/`. To enable HTTPS with minimal setup, place your certificate files in this directory and adjust the environment variable to reference the correct certificate file name.
#### HTTP\_CERT\_PATH
**Description:** Sets the location where the TLS certificate of the Policy Server resides. If the value is null, the HTTPS connection is not enabled. Make sure that the referenced file includes both the digital certificate and the intermediate certificate.
Please note that the
**Values:** string
**Example:** `/etc/ssl/certs/cert.pem`
**Default Value:** `null`
#### HTTP\_KEY\_PATH
**Description:** Sets the location where the private key file of the TLS certificate resides. If the value is null, the HTTPS connection is not enabled.
**Values:** string
**Example:** `/etc/ssl/certs/key.pem`
**Default Value:** `null`