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.
Figure 1 – Backplane architecture

Building blocks

Figure 2 – SSI & IAM Components

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

NameDescription
Data ProviderActor who receives raw data from Data Owners and push it to the Marketplace
Data OwnerActor 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 ConsumerConsumes 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
AdministratorManages the Marketplace and its users
Table 1 – Actors of the system

User Centric Authentication

NameDescription
DID ManagementA 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 ManagementVerifiable 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 compatibilityStaying 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.
Table 2 – User-centric Authentication Epics

NameDescription
Create DIDAs Subject I want to create a DID so I can manage my identity Subject: Data Consumer, Data Provider, Data Owner.
Present DIDAs 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 DIDAs a User I want to change the ownership of my DID so that I can maintain my Identity if I change Identity Provider.
Delegate DIDAs a User I want to delegate my DID so that I can make other DID able to act on behalf of me.
Recover DIDAs 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 AssetsAs 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 SignatureAs a User I want to verify asset signature so that I can authenticate the asset User: Data Consumer.
Deactivate DIDAs a User I want to deactivate my DID so that I can delete my Identity User: Data Consumer, Data Provider, Data Owner.
Resolve DIDAs 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 DIDAs a Relying Party I want to authenticate DID so I can verify DID ownership Relying Party: Data Marketplace/Data Provider.
Create Verifiable CredentialAs Data Marketplace I want to create a Verifiable Credential so I can provide to a User an attestation of her role.
Issue Verifiable CredentialAs Data Marketplace I want to issue a Verifiable Credential so I can attest something about my Users.
Receive Verifiable CredentialAs User I want to receive a Verifiable Credential so I can access Data Marketplace.
Store Verifiable CredentialAs User I want to store a Verifiable Credential so I use keep it and use it towards any Relying Party.
Request Verifiable CredentialAs 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 CredentialAs User I want to share a Verifiable Credential so I can attest something towards Relying Party.
Verify Verifiable CredentialAs User I want to receive a Verifiable Credential so I can access Data Marketplace.
Keep track of issued Verifiable CredentialsAs a Issuer I want to keep track of issued verifiable Credentials so that I can monitor and revoke them.
Revoke Verifiable CredentialAs a Issuer I want to revoke a Verifiable Credentials so that it cannot be used.
OIDC AuthenticationAs 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.
Table 3 – User-centric Authentication User Stories

Service-centric Authentication

NameDescription
Existing Identity Provider integrationRun a standard OpenID Connect relaying party (or OAuth2 client) on the backplane API.
Table 4 – Service-centric Authentication Epics

NameDescription
Existing Identity Provider authenticationAs a Data Marketplace I want to authenticate my users using approved external Identity Providers.
Table 5 – Service-centric Authentication User Stories

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