Table of Contents
Identity and access management
Objectives
The following are the high level capabilities provided by the SSI & IAM Subsystem:
- User-centric authentication: authentication of users based on Self Sovereign Identity paradigm
- Service-centric authentication: authentication of clients and users based on a standard OIDC/OAuth Identity and Access management system
Context
SSI & IAM Subsystem block interacts with following two building blocks:
- Data storage system, the Semantic Engine System will use the Data Storage system, in particular the Decentralized Data Storage component, for recording DID document.
- Backplane system, the SSI & IAM Subsystem will be used from the Backplane system for authenticating and authorizing users and clients.
- Data Access system, the SSI & IAM Subsystem will be used from the Data Access system for authenticating and authorizing users and clients.

Building blocks

The SSI & IAM subsystem is in charge of providing both “User-centric Authentication” and “Service-centric Authentication” capabilities.
Inside, we can find:
- “User-centric Authentication” component, responsible of providing the management of Self-Sovereign Identity based on DID and VC and the compatibility with OIDC standard.
- “Service-centric Authentication” component, responsible of providing authentication and authorization of users and client with standard OIDC/OAuth flows, integrating the User-centric Authentication component.
Technical Requirements
Actors
Name | Description |
Data Provider | Actor who receives raw data from Data Owners and push it to the Marketplace |
Data Owner | Actor that generates the data, and therefore ultimate owner of the data. Data Owners has to accept Data Requests to generate contracts which leads to share the data with Data Consumers |
Data Consumer | Consumes data shared from Data Owners Has to create Data Requests through the Data Discovery in order to Data Owners to accept them. Data Consumers receive only the data they want |
Administrator | Manages the Marketplace and its users |
User Centric Authentication
Name | Description |
DID Management | A decentralized system which enables several key actions by three distinct entities: the Controller, the Relying Party, and the Subject. Controllers create and control DIDs, while Relying Parties rely on DIDs as an identifier for interactions related to the DID Subject. The Subject is the entity referred to by the DID, which can be anything: a person, an organization, a device, a location, even a concept. Typically, the Subject is also the Controller. |
Verifiable Credentials Management | Verifiable Credential is a tamper-evident credential that has authorship that can be cryptographically verified though a proof It can be used to share and prove something about the identity of a User |
OIDC client compatibility | Staying backward compatible with existing OIDC clients and OPs that implement the OIDC specification to reach a broader community. Adding scopes and validation rules based on VC for OIDC clients to make full use of DIDs. Not relying on any intermediary such as a traditional centralized public or private OP while still being OIDC-compliant. |
Name | Description |
Create DID | As Subject I want to create a DID so I can manage my identity Subject: Data Consumer, Data Provider, Data Owner. |
Present DID | As a User I want to present my DID to a Relying Party so that I can identify myself User: Data Consumer, Data Provider, data Owner Relying Party: Data Marketplace, Data Provider. |
Rotate DID | As a User I want to change the ownership of my DID so that I can maintain my Identity if I change Identity Provider. |
Delegate DID | As a User I want to delegate my DID so that I can make other DID able to act on behalf of me. |
Recover DID | As a User I want to recover my DID so that I can maintain my Identity even if I lose my proof of control User: Data Consumer, Data Provider, Data Owner. |
Sign Assets | As a User I want to sign my assets so that I can demonstrate the authenticity of the asset User: Data Consumer, Data Provider, Data Owner. |
Verify Asset Signature | As a User I want to verify asset signature so that I can authenticate the asset User: Data Consumer. |
Deactivate DID | As a User I want to deactivate my DID so that I can delete my Identity User: Data Consumer, Data Provider, Data Owner. |
Resolve DID | As a Data Marketplace I want to resolve DID so I can retrieve from DID Document the information to authenticate DID Subject and verify data asset signature. |
Authenticate DID | As a Relying Party I want to authenticate DID so I can verify DID ownership Relying Party: Data Marketplace/Data Provider. |
Create Verifiable Credential | As Data Marketplace I want to create a Verifiable Credential so I can provide to a User an attestation of her role. |
Issue Verifiable Credential | As Data Marketplace I want to issue a Verifiable Credential so I can attest something about my Users. |
Receive Verifiable Credential | As User I want to receive a Verifiable Credential so I can access Data Marketplace. |
Store Verifiable Credential | As User I want to store a Verifiable Credential so I use keep it and use it towards any Relying Party. |
Request Verifiable Credential | As Data Marketplace/Data Provider I want to request Verifiable Credentials for the authenticated user so I can give the right access to my resources. |
Share Verifiable Credential | As User I want to share a Verifiable Credential so I can attest something towards Relying Party. |
Verify Verifiable Credential | As User I want to receive a Verifiable Credential so I can access Data Marketplace. |
Keep track of issued Verifiable Credentials | As a Issuer I want to keep track of issued verifiable Credentials so that I can monitor and revoke them. |
Revoke Verifiable Credential | As a Issuer I want to revoke a Verifiable Credentials so that it cannot be used. |
OIDC Authentication | As a Relying Party (RP) I want to authenticate users based on OIDC standards so that I don’t have to change my OIDC clients RP: Data Marketplace, Data Provider. |
Service-centric Authentication
Name | Description |
Existing Identity Provider integration | Run a standard OpenID Connect relaying party (or OAuth2 client) on the backplane API. |
Name | Description |
Existing Identity Provider authentication | As a Data Marketplace I want to authenticate my users using approved external Identity Providers. |
Go to the beginning of the page
Other resources of interest
Home
We are a community of experienced developers who understand that it is all about changing the perception of data economy via marketplaces support.
i3-MARKET Architecture
Take a look at the main building blocks and their hierarchy.
Data Access API
The secure Data Access API enables data providers secure registration…
Data Storage
The Decentralised storage shall provide highest available security guarantees…
Smart Contracts, Wallets & Accounting
i3-M Wallet is a set of technologies that facilitate the management of their identity to…
Crypto Token and Monetization System
The Data Monetization subsystem is in charge of providing “Standard Payments”…
Semantic Engine
We developed and implemented dedicated software components for Semantic Engine System as…
Specification Deployment
i3-MARKET architecture specification is based on the 4+1 architectural view model approach. One of…
Developers Quickstart SDK
Once a marketplace is part of i3-MARKET, it can issue credentials to its consumers, providers, and…
Documentation
Full Developers Documentation