Dataspaces with SSI-based access control enabled
This page shows single-node and multi-node topologies for dataspaces that perform SSI-based verification for asset- and service-level access.
Dataspace with SSI-based access control enabled — single OE Node
In this configuration, both the OE Node and the Marketplace are enabled to perform SSI‑based verification for asset‑level and service‑level access control. Implementing SSI verification introduces additional operational complexity, as it requires deploying and integrating several supporting components on both the Dataspace Operator and Dataspace Participant sides.
The architecture of a dataspace with SSI verification enabled is shown in the diagram below.
For SSI credential verification, the OE Node relies on the Policy Server component. When a consumer requests access to a specific asset service, the OE Node forwards the request to the Policy Server, which determines whether the user is authorized. To make this decision, the Policy Server leverages several specialized components that validate Verifiable Credentials against defined policy rules: the Verifier, the OPA Server, the SSI Wallet API, and the Policy Server Proxy.
Characteristics
This dataspace with SSI-based access control enabled has the following characteristics:
Open marketplace access: The marketplace is publicly accessible—any user can connect to publish or consume assets, with no access restrictions enforced at the marketplace level.
Web3-based authentication: Users access the marketplace through a non‑custodial Web3 wallet (such as MetaMask). Each user is uniquely identified within the marketplace by the Web3 address used during connection.
SSI wallet authentication: To access the Verifiable Credentials and DIDs required for SSI policy verification, the user must authenticate with the SSI wallet instance using the Web3 address stored in their non‑custodial Web3 wallet (such as MetaMask).
Credential checks based on wallet addresses and SSI policies: Asset‑level and service-level access control is enforced by validating the user’s Web3 address and evaluating the SSI policies defined in the asset description. During SSI policy verification, the consumer is prompted to submit the required Verifiable Credentials, which are then assessed against the rules specified in the asset’s DDO.
Unrestricted catalogue visibility: All assets indexed by the OE node appear in the marketplace catalogue, without additional filtering or dataspace‑specific segmentation.
User Flows
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 and operates their own SSI wallet instance within the dataspace. This ensures full control over private keys, decentralized identifiers (DIDs), and Verifiable Credentials (VCs), and prevents the marketplace operator from having access to sensitive identity material.
A shared SSI wallet instance may be offered by the marketplace operator for participants who have not yet provisioned their own wallet. However, this option is intended only for onboarding or non‑critical usage. In a fully operational production setup, every participant is expected to manage their own DIDs and VCs through a locally controlled SSI wallet instance to maintain proper security, trust boundaries, and compliance.
The SSI wallet URL is set when the user first connects to the Marketplace. It is saved in the Marketplace cookies. If the dataspace operator sets a default SSI wallet instance, it is provided when the user first connects.
Publishing an asset
When SSI policy verification is enabled in the marketplace, users can define SSI‑based access credentials for their assets and services during asset creation or editing.
Upon publishing an asset, the system automatically creates a corresponding NFT on the blockchain. The OE Node then encrypts the asset’s Decentralized Document (DDO), stores the encrypted DDO in IPFS, and records the resulting IPFS content identifier on‑chain. Afterward, the OE Node indexes the asset, making it discoverable and available for consumption through the Marketplace.
Controlling access to assets
In this configuration, the OE Node delegates asset access control to its configured Policy Server. When a participant attempts to consume an asset's service, the OE Node forwards the request to the Policy Server. The request includes access control rules defined at the asset and service levels, and the participant's Web3 address. Using this information, the Policy Server determines whether the participant is authorized, denied, or, if SSI-based access policies apply, required to 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 OE Node, and the Policy Server Proxy.
Once this exchange is complete, the participant sees a list of Verifiable Credentials in the Marketplace UI. These credentials satisfy the presentation requirements. The participant selects credentials to submit, and the SSI Wallet packages them into a Verifiable Presentation. The presentation 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.
Dataspace configuration
Configuration example
In a dataspace with SSI‑based access control enabled, all components related to SSI verification are required. The table below provides the assumed URLs for each element presented in the architecture diagram.
Marketplace
https://market.oceanenterprise.io
OE Node
https://node.oceanenterprise.io
Policy Server
https://ps.oceanenterprise.io
Policy Server Proxy
https://proxy.oceanenterprise.io
Shared SSI Wallet
https://wallet.oceanenterprise.io
Verifier
https://verifier.oceanenterprise.io
OPA Server
http://opa.oceanenterprise.io:8181
To ensure correct operation, configure the relevant environment variables for each component, using the examples shown in the table below.
Configuration steps
The recommended deployment order for this setup is:
Dataspace with SSI-based access control enabled — multiple OE Nodes
In this configuration, the Marketplace is connected to multiple OE Nodes, which may be deployed either by the dataspace operator or by individual participants. Both the Marketplace and all OE Nodes are configured to enforce SSI‑based verification for asset‑level and service‑level access control.
The Marketplace aggregates and displays a consolidated catalog of all assets registered across the OE Nodes in the dataspace. Additionally, it allows users to publish new assets to a specific OE Node, giving participants full control over where their assets are hosted and managed.
The architecture of this type of dataspace is illustrated in the diagram below.
In this configuration, each OE Node requires its own Policy Server and Policy Server Proxy deployment. For example, OE Node DO1 uses Policy Server DO1 together with Policy Server Proxy DO1.
Multiple Policy Servers can share the same Verifier for SSI policy validation (e.g., Policy Server DO1 and Policy Server DO2 both use Verifier DO01). Alternatively, a Policy Server may operate with a dedicated Verifier (e.g., Policy Server DO3 uses Verifier DO3, and Policy Server DP1 uses Verifier DP1).
All Verifiers use the same instance of the OPA Server—specifically OPA Server DO1—to perform custom SSI policy validation.
Characteristics
This dataspace with SSI-based access control enabled has the following characteristics:
Open marketplace access: The Marketplace is publicly accessible—any user can connect to publish or consume assets, with no access restrictions enforced at the Marketplace level.
Web3-based authentication: Users access the Marketplace through a non‑custodial Web3 wallet (such as MetaMask). Each user is uniquely identified within the Marketplace by the Web3 address used during connection.
SSI wallet authentication: To access the Verifiable Credentials and DIDs required for SSI policy verification, the user must authenticate with the SSI wallet instance using a non‑custodial Web3 wallet (such as MetaMask).
Federated catalogue: The Marketplace connects to all OE Nodes defined in the dataspace and provides a consolidated asset catalogue.
Unrestricted catalogue visibility: All assets indexed by an OE Node appear in the Marketplace catalogue, without additional filtering or dataspace‑specific segmentation.
Credential checks based on wallet addresses and SSI policies: Asset‑level and service-level access control is enforced by validating the user’s Web3 address and evaluating SSI policies defined in the asset description.
Decentralized SSI policy validation components: Each OE Node independently verifies SSI policies for its own assets using local components, specifically its Policy Server and Policy Server Proxy. Dataspace actors may deploy their own Verifier instance or reuse an existing one.
User Flows
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 and operates their own SSI wallet instance within the dataspace. This ensures full control over private keys, decentralized identifiers (DIDs), and Verifiable Credentials (VCs), and prevents the marketplace operator from having access to sensitive identity material.
A shared SSI wallet instance may be offered by the marketplace operator for participants who have not yet provisioned their own wallet. However, this option is intended only for onboarding or non‑critical usage. In a fully operational production setup, every participant is expected to manage their own DIDs and VCs through a locally controlled SSI wallet instance to maintain proper security, trust boundaries, and compliance.
The SSI wallet URL is set when the user first connects to the Marketplace. It is saved in the Marketplace cookies. If the dataspace operator sets a default SSI wallet instance, it is provided when the user first connects.
Publishing an asset
Publishing an asset works similarly to the single-node dataspace. When publishing, the user can choose the OE Node that encrypts the data. After publishing, the asset is indexed by the OE Nodes.
Controlling access to assets
In this configuration, the OE Node delegates asset access control to the Policy Server. When a participant attempts to consume an asset's service, the OE Node forwards the request to the Policy Server. The request includes access control rules defined at the asset and service levels, and the participant's Web3 address. Using this information, the Policy Server determines whether the participant is authorized, denied, or, if SSI-based access policies apply, required to 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 OE Node, and the Policy Server Proxy.
Once this exchange is complete, the participant sees a list of Verifiable Credentials in the Marketplace UI. These credentials satisfy the presentation requirements. The participant selects credentials to submit, and the SSI Wallet packages them into a Verifiable Presentation. The presentation 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.
Dataspace configuration
Configuration example
The table below provides the assumed URLs for each element presented in the architecture diagram.
Marketplace
https://market.oceanenterprise.io
OE Node DO1
https://node1.oceanenterprise.io
OE Node DO2
https://node2.oceanenterprise.io
OE Node DO3
https://node3.oceanenterprise.io
OE Node DP1
https://node1.ds-participant.io
Policy Server DO1
https://ps1.oceanenterprise.io
Policy Server DO2
https://ps2.oceanenterprise.io
Policy Server DO3
https://ps3.oceanenterprise.io
Policy Server DP1
https://ps1.ds-participant.io
Policy Server Proxy DO1
https://proxy1.oceanenterprise.io
Policy Server Proxy DO2
https://proxy2.oceanenterprise.io
Policy Server Proxy DO3
https://proxy3.oceanenterprise.io
Policy Server Proxy DP1
https://proxy1.ds-participant.io
Shared SSI Wallet
https://wallet.oceanenterprise.io
Verifier DO1
https://verifier1.oceanenterprise.io
Verifier DO3
https://verifier3.oceanenterprise.io
Verifier DP1
https://verifier1.ds-participant.io
OPA Server
http://opa.oceanenterprise.io:8181
To ensure correct operation, configure the relevant environment variable in each component, using the examples shown in the table below.
OE Node DO1
POLICY_SERVER_URL
https://ps1.oceanenterprise.io
OE Node DO2
POLICY_SERVER_URL
https://ps2.oceanenterprise.io
OE Node DO3
POLICY_SERVER_URL
https://ps3.oceanenterprise.io
OE Node DP1
POLICY_SERVER_URL
https://ps1.ds-participant.io
Marketplace
NEXT_PUBLIC_PROVIDER_URL
https://node.oceanenterprise.io
NEXT_PUBLIC_NODE_URI_INDEXED
["https://node1.oceanenterprise.io","https://node2.oceanenterprise.io","https://node3.oceanenterprise.io","https://node1.ds-participant.io"]
NEXT_PUBLIC_METADATACACHE_URI
["https://node1.oceanenterprise.io","https://node2.oceanenterprise.io","https://node3.oceanenterprise.io","https://node1.ds-participant.io"]
NEXT_PUBLIC_SSI_ENABLED
true
NEXT_PUBLIC_OPA_SERVER_URL
http://opa.oceanenterprise.io:8181
NEXT_PUBLIC_SSI_WALLET_API
https://wallet.oceanenterprise.io
Configuration steps
The recommended deployment order for this setup is:
1.
Install and configure the SSI Stack in the Dataspace Operator's environment
Install and configure the SSI Stack in the Dataspace Participant's environment
2.
Install and configure the policy servers in the Dataspace Operator's environment
Install and configure the policy servers in the Dataspace Participant's environment
3.
Install and configure the OE Nodes in the Dataspace Operator's environment
Install and configure the OE Node in the Dataspace Participant's environment
4.
Install and configure the Policy Server Proxies in the Dataspace Operator's environment
Install and configure the Policy Server Proxy in the Dataspace Participant's environment
Last updated