Identity and Access Management – System Specification

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 the 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 documents.
• 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 provides both “User-centric Authentication” and “Service-centric Authentication” capabilities.

Inside, we can find:

• “User-centric Authentication” component, responsible for providing the management of Self-Sovereign Identity based on DID and VC and the compatibility with OIDC standards.
• “Service-centric Authentication” component, responsible for providing authentication and authorization of users and clients 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 pushes it to the Marketplace
Data Owner	The actor that generates the data, and therefore the ultimate owner of the data. Data Owners have to accept Data Requests to generate contracts which leads to sharing the data with Data Consumers
Data Consumer	Consumes data shared from Data Owners Has to create Data Requests through Data Discovery in order for 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 that 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, or even a concept. Typically, the Subject is also the Controller.
Verifiable Credentials Management	A verifiable Credential is a tamper-evident credential that has authorship that can be cryptographically verified through 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 my Identity Provider.
Delegate DID	As a User, I want to delegate my DID so that I can make other DID able to act on my 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 the 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 the data asset signature.
Authenticate DID	As a Relying Party I want to authenticate DID so I can verify DID ownership Relying on Party: Data Marketplace/Data Provider.
Create Verifiable Credential	As Data Marketplace I want to create a Verifiable Credential so I can provide 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 a User, I want to receive a Verifiable Credential so I can access Data Marketplace.
Store Verifiable Credential	As a User, I want to store a Verifiable Credential so I use to 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 a User, I want to share a Verifiable Credential so I can attest something to Relying Party.
Verify Verifiable Credential	As a User, I want to receive a Verifiable Credential to access Data Marketplace.
Keep track of issued Verifiable Credentials	As an Issuer, I want to keep track of issued verifiable Credentials so that I can monitor and revoke them.
Revoke Verifiable Credential	As an Issuer, I want to revoke 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 client’s RP: Data Marketplace, Data Provider.

Service-centric Authentication

Name	Description
Existing Identity Provider integration	Run a standard OpenID Connect relying 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.

Sequence Diagrams

The following diagrams describe the processes involving the components of the SSI & IAM subsystems –

The diagrams assume that the user created and controls with his crypto wallet a distributed identity using Ethereum DID Management

 Identity Authentication

The following process describes how a self-sovereign identity is authenticated as managed by a crypto wallet using Ethereum DID Management.

The User-centric Authentication component creates a challengeRequest to retrieve the user’s DID, then check the challengeResponse (signed by the user’s wallet) to verify if the user controls the DID retrieving the corresponding DID Document.

User Registration

The following process describes how a client application can register a self-sovereign identity as an i3Market user issuing a verifiable credential attesting to his role.

After DID Authentication and the verification of additional information disclosed by the user, the client app issues a verifiable credential for that DID which attest to the role of the user (Data Consumer, Data Provider, or both).

The user’s wallet stores the credential locally and updates the DID document.

OIDC Authorization (Authentication code + PKCE)

The following process describes how a client application can be authorized by an i3Market user to access a protected API and obtain information about the user using a standard OpenID Connect Authentication code flow with PKCE.

Free* Open Source Software Tools for SMEs, Developers and Large Industries Building/Enhancing their Data Marketplaces.

When the client application tries to call a protected resource without a valid access_token it is redirected to the OIDC IAM authorization endpoint and then to User-centric Authentication authorization endpoint showing the login page.

When the user logs in with is wallet an id_token is created with the DID and the VC associated to the requested scopes and an authentication code is provided to the client to call the token endpoint and receive a valid access_token, a refresh token ad the id_token.

Solution Design

User-centric authentication

In order to provide authentication and authorization with distributed identity and verifiable credentials, we implemented two Node.js micro services. The Verifiable Credential micro service provides the APIs that implement the core functions to manage verifiable credentials, namely issuing, verifying and revoking verifiable credentials, and a utility function. The OIDC SSI Auth micro service provides the API to perform the authorization code flow with PKCE using verifiable credentials as proof method.

To implement the solution, we have chosen Veramo, a framework that replaces the previous implementation of the uPort library, which is deprecated

Both components (OIDC SSI Auth and Verifiable Credential micro service) integrate the Veramo framework and take advantage of its features to manage DID and verifiable credentials.

I3-Market Network is composed by different Data Marketplaces running an instance of the i3-Market Backplane connector. Each of them has its own OIDC SSI Auth Service and its own Verifiable Credential micro service to generate, verify and revoke verifiable credentials. In relation to the roles of the W3C Recommendations on verifiable credentials, the OIDC SSI Auth Service is the verifier, the Verifiable Credential micro service is the issuer (with some extra features) and the user is clearly the holder of his verifiable credentials. Each instance of the Verifiable Credential micro service has its own DID and private key used to sign verifiable credentials. In this way, each verifiable credential, has as its issuer the DID of the micro service that generated it. Similarly, for revocation, only the micro service that generated a credential has the privilege to revoke it.

The user save the Verifiable Credentials in his wallet and give an explicit consent to share them with the OIDC SSI Auth Service when requested during the authentication phase.

DID Management

DID Management is provided by Hyperledger BESU blockchain and the Veramo ethr-did library.

This library conforms to ERC-1056 and is intended to use Ethereum addresses as fully self-managed Decentralized Identifiers (DIDs).

Ethr-DID provides a scalable identity method for Ethereum addresses that gives any Ethereum address the ability to collect on-chain and off-chain data.

This particular DID method relies on the Ethr-Did-Registry. The Ethr-DID-Registry is a smart contract that facilitates public key resolution for off-chain (and on-chain) authentication. It also facilitates key rotation, delegate assignment and revocation to allow 3rd party signers on a key’s behalf, as well as setting and revoking off-chain attribute data. These interactions and events are used in aggregate to form a DID’s DID document using the Ethr-Did-Resolver.

It supports the proposed Decentralized Identifiers spec from the W3C Credentials Community Group.

This library has been integrated both in OIDC SSI Auth and Verifiable Credentials micro services to resolve and authenticate DID interacting with the user’s wallet.

The library has been used by the Verifiable Credentials micro service to create and manage the distributed identity issuing the credentials while the Distributed Identities of the users must be created and managed by user’s wallet.

Verifiable Credential management

For the verifiable credential management the Verifiable Credentials micro service uses the Veramo framework to generate the credentials and call the i3-Market Wallet API to provide the credential to the user.

Issue a Verifiable credential

The first scenario in which a Data Marketplace issue a Verifiable Credential to a user is the registration process. In this scenario the micro service has to authenticate the DID of the user and then issue for this DID a verifiable credential that certifies the role of the user, which can be a data consumer, a data provider or both. The workflow for the registration process is described in the figure below. The entities involved are the following

• the Identity Holder, that is the i3Market user
• the User Agent, that is also the Client of the OIDC (i3Market Data Marketplace website)
• the i3-market wallet, which is the wallet in which credentials are stored
• the Verifiable Credential micro service (i3Market Data Marketplace instance)
• the i3Market Data Marketplace backend

At the beginning, the user enters his registration data (1), relating to a data consumer user or a data provider. When a user is registered as a data consumer or data provider, he is registered for all the sites of the i3Market Network. For this reason, these two verifiable credentials are issued exclusively by the i3Market Data Marketplace entity. These data are entered on registration forms in a dedicated section of the i3Market Data Marketplace.

In order to know for which DID the verifiable credential should be issued, the i3Market Data Marketplace must obtain the DID of the user. This part of the flow involves the wallet-protocol session API, which is specifically designed to open a secure connection (“paring”) with the wallet (see deliverable D3.4 for more details), using a generated OTP, to retrieve the DID of the user. In particular, the i3Market Data Marketplace performs a GET to the issue API of the Verifiable Credentials micro service (2) passing as parameters a callbackUrl (which indicates the URL where to redirect the user after the issue of the credential) and the credential formatted as JSON encoded object.

When the i3Market Data Marketplace initiates this API call, the Verifiable Credential micro service use the “pairing” protocol to connect to the wallet and ask for an OTP to connect to the i3Market Smart Wallet(3).

The user generates a new OTP, using the related wallet function and presents it to the Verifiable Credential to start a secure session(4).

Then the Verifiable Credential send a share request to retrieve user DID(5).

At this point the user receives the disclosure request through the wallet and decide whether to accept or not to share the requested identity (DID) (6)

If the user agrees to share the DID (7), the i3Market Smart Wallet sends the following access token to the Verifiable Credentials micro service (8) via callback. At this point the verifiable credentials service decode the access token to extract the DID of the user who has authenticated.

The second part of the flow relates to the issue of a verifiable credential to certify that the user is a data consumer. At a high level, issuing a verifiable credential involves two steps:

• Cryptographically signing the credential data
• Send the signed credential as a JWT to the i3-market Smart Wallet

In order to create a verifiable credential, the Verifiable Credential micro service performs an internal API call to the POST /credential/issue/{DID} endpoint (9), communicating the user’s DID just retrieved and the credential as form-data in the following format:

The i3Market Data Marketplace may request the issuance of credentials only relating to the registration process, i.e., data consumer and data provider. All other credentials, relating to the purchase of assets or services, can be requested by Data Providers. When the API is called, the Verifiable Credential micro service performs the Veramo createVerifiableCredential function, provided by the DID Agent of the Veramo Core library.

When the i3-market Smart Wallet receives the credential, it verifies its signature. Each Signed Message has an “iss” attribute that contains a DID of the issuer. To resolve the public key of the message, a did-resolver is used. Veramo DID Agent currently supports many DID methods, such as “did:ethr”( based on ERC-1056), “did:web” (in conjunction with blockchain-based DID, can bootstrap trust using a web domain’s existing reputation) and “did:key” (self-certifying DID method, which does not require any external utility such as Blockchain). More details about supported DID methods can be found in Veramo documentation.

Being Hyperledger Besu the reference blockchain, the users’ DID is “did:ethr”.

After the signature verification, the wallet asks the user to accept the credential (10). When the user accepts the credential (11), it will be saved in his wallet and then be present and visible in the resources tab, that contains the list of the credentials registered in the app.

At this point the user will be redirect to the callbackUrl, previously specified.

Once a user has saved some credentials in his wallet, he can disclose them in authentication requests, in order to certify that he holds the credentials needed to access resources or services.

Revoke a Verifiable credential

As part of the process of working with verifiable credentials, it is not only necessary to issue credentials, but sometimes it is also necessary to revoke them. The ability to revoke a credential when it is no longer valid is a core function in a verifiable credential ecosystem. For example, suppose an i3Market data provider issues a credential to access a service, and a data consumer violates the terms of use. The data provider determines that the user has violated the terms of use and, consequently, wants to suspend the access to the service. In this way, the status of the verifiable credential needs to be changed and the next time a relying party checks the status, they will be able to see that the user is no longer valid and consequently not authorized to access the service. In order to satisfy this requirement, an API to revoke credentials has been implemented and the workflow to revoke a credential is described with the figure below.

At the beginning of the flow, the data provider calls the API of the verifiable credentials micro service (1) communicating that a specific credential belonging to a user must be marked as revoked. The verifiable credential to be revoked is passed through the body parameter in the form { “JWT”: “eyJhbGc …”}.

As an implementation choice, it was decided that only those who issued a credential are allowed to revoke it. To satisfy this requirement, a check is made, if the issuer of the credential is the address of the issuer then it proceeds, otherwise it immediately blocks the flow. When the verifiable credentials micro service receives the API call, it writes the credential hash through a transaction in a smart contract named RevocationRegistry (2), in order to keep track of the action performed. Since the i3Market blockchain is an Ethereum-type blockchain, the smart contract is written in solidity and its code is the following:

The smart contract RevocationRegistry provides two functions:

• a public function to revoke a credential
• a public function to check if a credential is in the revocation list, i.e., it has been revoked.

The revoke function takes as input a string of 32 characters, and writes a record associating it with the sender of the transaction, i.e., the address commits the line. In order to always have 32 characters, the credential before being marked on the smart contract is processed by a SHA-3 cryptographic hash algorithm and the 32-character digest is written on the smart contract.

The data structure of the smart contract is a private array of digest-address associations, named revocations (line 5). Whenever a credential is added to the register, it is mapped via the credential digest and the issuer of the transaction, i.e., the message sender. On that mapping, the block number is written, i.e., the transaction counter id.

As an implementation choice, it was decided that only the service that issued a verifiable credential can revoke it. This is to prevent third parties from revoking verifiable credentials that they have not issued. In fact, it is reasonable that only the provider who grants access to the service can eventually revoke it.

As it is possible to notice from the smart contract code, another requirement to be able to add a verifiable credential in the smart contract is the fact that it is not already present in the register (line 8), i.e., in the corresponding mapping there is not a block number indicating which transaction added the credential. If it has not already been added, then it is possible to write it (line 9). When upthe transaction is successfully added, an event is emitted (line 11), which communicates the issuer of the transaction and the digest of the newly added credential in the register (line 17).

A possible problem is the fact that this smart contract trusts that what is written to the registry is actually a valid digest of a credential in JWT format. In this implementation, there is no kind of access control list that allows only some addresses to write in the smart contract. In fact, once a smart contract is deployed in blockchain, its public methods can be called from any valid address. It is therefore possible that any address can call these methods and write non-consistent information to the register. This problem can be solved with a list of trusted issuers of transactions. In fact, it is possible to consider an issuer as trusted if it also implements the correct cryptographic hash algorithms on the verifiable credential before writing it to the register. These security enhancements will be added at a later stage of the project.

Verify a Verifiable credential

The verification is the process of evaluation of a verifiable credential, in order to determine whether it is authentic and timely valid for the issuer or the presenter. This process includes the following checks:

• the credential conforms to the specification
• the proof method is satisfied, i.e., the cryptographic mechanism used to prove that the information in a verifiable credential was not tampered
• the credential is not marked as revoked in the smart contract registry.

The Veramo credential library provides the methods for the first two checks, while for the third it is necessary to implement a call to the smart contract registry. The flow for verifying a credential is described in the figure below.

In the implemented solution, in step 1) the data provider calls the verifiable credentials micro service, specifying the credential in JWT format to be verified in the request body. Since verifying the presence of a verifiable credential on the registry is an operation that does not change the status of the credential, this can be done by any instance of the micro service. In step 2) the verifiable credentials micro service checks that the issuer is valid and that the credential is in a format that complies with the data provider’s specifications. If there is no problem with the credential, then it computes the hash of the credential using a SHA-3 cryptographic hash algorithms, which produces a 32-character digest. Then, in step 3), the Verifiable Credential micro service calls the ‘revoked’ method of the smart contract registry, specifying the issuer of the verifiable credential and the 32-character digest. The credential issuer is specified in the JWT and since only the issuer of a credential has the permissions to revoke it, it is sufficient to check that only his address, associated with the credential, is not present in the register. As it is possible to see in the solidity code of the smart contract, detailed in the previous section, this method returns the block number when it was revoked by `issuer`, or 0 if it was not. In this way it is possible to know if the credential has been revoked or not. This information is then returned as a response to the data provider, who will decide for himself what the next steps will be, for example requesting the issuance of a new valid credential or informing the user that he can no longer request access to that data or service. This API is used in the integration of the OIDC identity provider. In fact, to authenticate a user on the basis of the revealed credentials, a further check on the registry is necessary to ensure that the credential is not revoked.

OIDC compatibility

The use of verifiable credentials allows the distributed and decentralized management of users. In particular, users can use verifiable credentials issued as a certificate to obtain a token necessary to access specific services or protected resources within the marketplace. In order to retrieve the verifiable credentials and use them in an authorization process, a certified open source Open ID Connect provider has been enhanced with wallet API library. In this way, users can be authenticated and authorized based on the verifiable credentials they hold.

In step (1), the user wants to access a resource or service in the marketplace. The resources and services are made available by data providers, who expect to receive a valid access token and id token, with the necessary scope to access the resource or service. So, the first thing a data provider website does is to initialize the authentication ow (2). The authentication with Authorization Code flow + PKCE is done through an OAuth 2.0 SDK, which first generates a code verifier and a code challenge. Specifically, the OAuth 2.0 SDK creates a cryptographically-random code verifier and from this generates a code challenge. After that, the authorization code + PKCE ow is initialized with the first call /authorize. The main difference of this Open ID Connect provider compared to traditional ones is that it requires the disclosure of verifiable credentials. To specify the credentials to be revealed, the scope field is used.

The Open ID Connect provider has the following static scopes:

• openid: Mandatory for the Open ID Connect standard. It returns the sub field of the id token, and its value is the user did.
• profile: It adds information about the user profile into the id token.
• vc: It adds the field verifiable claims into the id token. Useful when the relying party wants to check any information about the verifiable claims asked.

Compared to the standard scope of Open ID Connect, the scopes added are vc and vce. On the other hand, the standard email scope, which returns the user’s email, is not present.

There are two different types of scopes:

• vc:vc name: It asks the user for the specific verifiable claim vc name. It is optional, so the user can decide whether to append it or not. If the issuer of the verifiable claim is not trusted, it will be added into untrusted verifiable claims array of the id token. These arrays are described in the end of this section.
• vce:vc name: It asks the user for the essential verifiable claim with name: vc name. It is mandatory, so if the user does not provide it or the issuer is untrusted, the login and consent process will be cancelled.

After specifying in the scope field which credentials need to be disclosed, the OAuth SDK initializes the authentication process, performing the call to the /authorize endpoint (3).

Service-centric authentication

Service-centric authentication is the component responsible for authentication and authorization on the Service Provider side.

It provides standard authentication for administrative users and the ability to configure clients for accessing Backplane services as a Marketplace administrator.

For this purpose, an open source and OIDC certified Identity and Access Management system has been chosen: Keycloak.

Keycloak provides a useful and user-friendly interface to configure users, groups, clients, roles, scopes, federated identity providers to manage OIDC authentication and OAuth2 authorization.

It is also possible to use Keycloak Admin REST API to create users and clients using an administrative client.

Backplane services are configured to accept the access_token issued by the Data Marketplace Keycloak instance so clients configured in the Keycloak instance could obtain an access_token, though one of the possible OAuth flows (client credentials, authentication code, username/password), to call Backplane services acting as a Marketplace administrator.

Moreover, the Keycloak instance is configured to accept the OIDC SSI Auth micro service as federated Identity Provider, so it is able to manage the user-centric authentication in order to authenticate i3Market users and authorize clients to operate on behalf of the i3Market user.

Providing username and password the user log in as Marketplace user, otherwise using “I3Market Identity” login the Authentication Code flow described in paragraph 5.3 and 6.1.6 is initiated to authenticate the user and authorize the client.

At the end of the flow Keycloak provides the client the access token to invoke Backplane services.

The whole history of the users’ accesses could be found using the “Events” function, while the “Sessions” function shows the users currently logged in.

Interfaces Description

The interfaces of the final version of Verifiable Credential micro service and OIDC SSI Auth micro service, composing the User-centric Authentication component, are presented below.

Selected Technologies

To implement the solution, we have chosen to use Veramo, a framework that replaces the previous implementation of the uPort library, which is deprecated.

Both components (OIDC SSI Auth and Verifiable Credential micro service) integrate the Veramo framework and take advantage of its features to manage DID and verifiable credentials.

The table below shows a summary for the evaluation of the candidate technologies towards i3-Market requirements.

Table 6: Technology evaluation

DID management

Requirements	Veramo (uPort)	Hyperledger Indy/Aries	Ocean protocol	Sidetree
Create DID	Yes	Yes	Yes	Yes
Present DID	Yes	Yes	Yes	Yes
Rotate DID	Yes	Yes	Yes	Yes
Recover DID	Yes	Yes	Yes	Yes
Update DID	Yes	Yes	Yes	Yes
Resolve DID	Yes	Yes	Yes	Yes
Authenticate DID	Yes	Yes	Yes	Yes
Deactivate DID	Yes	Yes	Yes	Yes
Sign Asset	Yes	Yes	Yes	No*
Verify Asset Signature	Yes	Yes	Yes	No*

Verifiable Credential management

Requirements	Veramo (uPort)	Hyperledger Indy/Aries	Ocean protocol	Sidetree
Request VC	Yes	Yes	Yes	No*
Create VC	Yes	Yes	Yes	No*
Receive VC	Yes	Yes	Yes	No*
Store VC	Yes	Yes	Yes	No*
Verify VC	Yes	Yes	Yes	No*
Share VC	Yes	Yes	Yes	No*
Keep track of issued VC	Yes	Yes	Yes	No*
Revoke VC	Yes	Yes	Yes	No*

OIDC compatibility

Requirements	Veramo (uPort)	Hyperledger Indy/Aries	Ocean protocol	Sidetree
OIDC Authentication	Yes (with some effort)	Yes(VCAuthN)	Yes (with some effort)	No*

Sidetree is a protocol that enables W3C Decentralized Identifier (DID) implementations over different ledgers, but existing implementations are in beta, i.e., may not be mature enough for production use yet. Moreover it does not cover Verifiable Claim management features.

Ocean Protocol is a complete project with its own PoA blockchain, off-chain Data Storage, metadata management, Smart Contract Management, Payments and so on.

It should be taken into account as a reference project for i3Market but it can’t be used as a whole technology.

UPort and Hyperledger Indy/Aries are both valid technologies to use for implementing i3-Market SSI Identity and Access Management solution.

UPort is better documented and has a lot of libraries and apps already available and tested by the a considerably big community but documentation for the adoption of the libraries/SDK in a custom deployment is often outdated if not missing and ease of adoption of the uPort technology relies mainly on the use of their deployed ecosystems. However it should be easier to customize and integrate in i3Market solution.

In fact Hyperledger Indy still relies solely on the Indy-SDK that can be tricky as it carries a lot of heavy-weight assumptions like the need to use ZeroMQ, which browsers are not compatible with because it requires RAW TCP access to communicate with the node.

Moreover the use of Rust programming language to write the Indy-SDK could make difficult to customizing them. Aries specifications and tools could be used to create custom SDK and agents that will be able to interface both with Indy and Ethereum blockchain.

Conclusions

Motivations

I3-Market aims to create a network of Data Marketplaces, to improve data exchange between Data Consumers and Data Providers and to promote the born of new data services, ensuring the necessary level of trust and respecting privacy principles.

To achieve this goals any client in the network must be able to authenticate i3-Market users and the latter must be uniquely identified across the whole network.

Moreover i3-Market must provide trust and privacy “by design”, implementing data minimization, explicit user consent, limitations on Purposes, accuracy of data, integrity and confidentiality.

Current centralized and federated models don’t permit to reach these goals in an efficient and dynamic way because of big issues related to integration, trust and privacy.

For these motivations, we decide to adopt a self-sovereign identity management model, an emerging digital identity solution that uses distributed ledger and cryptography technologies to implement a user-centric authentication model respecting privacy principles “by design”.

In fact, through the use of Distributed Identifier (DID) and Verifiable Credentials (VC) users can create and manage their own identities, control their personal data and credentials and share them with an explicit consent, selecting only the necessary ones.

I3-market users are uniquely identified by DID and the VCs shared by the users could be easily verified by third part application without involving the credential issuer, avoiding any integration between i3-market stakeholders.

Technical contribution

One of the major challenges for a wide adoption of SSI technology is to hide the complexity of DID authentication and Verifiable credentials management for existing business applications and IAM system.

As reported in chapter 7 state-of-the-art SSI technologies are still work in progress and even the most stable and best documented, Veramo (previously uPort) and Hyperledger Indy, are difficult to be customized and integrated in a third part system.

Moreover these technologies only provide DID authentication and VC collection and disclosure while the authorization part is completely delegated to the third part system.

In an authorization scenario such as the one defined in the i3-Market specifications, we need a more secure authorization flow, capable of issuing specific authorization tokens for each service, based on the credentials held by a user in his wallet.

So, by extending a certified open source OIDC provider with Veramo technology we have created a new certified OIDC provider that requires verifiable credentials as scope in an Authorization Code + PKCE flow which will then be revealed through the i3-Market Smart Wallet application. Thanks to this new implementation, it is possible to authorize users based on the credentials obtained through the most secure authorization flows (code flow + PKCE), in order to issue access tokens that contain the credential information revealed by the user. Furthermore, our OIDC authorization server is very flexible and we can support the integration with other wallets and open-source technologies for SSI. This new OIDC SSI Auth service could be easily used by business applications through a standard OIDC client library and federated in existing IAM system (like Keycloak) as external OIDC provider, mapping verifiable credentials claims with roles and scopes taken in to account for authorization policies.

Appendix A State of the art

This appendix reports the evaluation of SOTA technologies identified for the implementation of the i3-MARKET Identity and Access management building block based on Self Sovereign Identity. Starting from the information contained in the deliverable D2.1 the identified technologies were mapped and evaluated against building block requirements specified in the previous chapters, describing in detail how they provide each requirement and identifying PROS and CONS of each technology.

UPort (UPC)

uPort has evolved to a constellation of different services targeted to self-sovereign identity and secure and scalable data exchanges. uPort was one of the first SSI technologies for the Ethereum ecosystem and it is likely to be the most widely used, mainly because it has a complete ecosystem of libraries and mobile apps that actually ease its adoption.

Hyperledger Indy/Aries

Hyperledger Indy is a decentralized identity implementation including support for a ledger, DIDs and verifiable credentials created from Sovrin source code.

Distributed Ledger

• indy-node
• indy-plenum

Client Tools

• indy-sdk (superseded by project arise)
• indy-agent (superseded by project arise)

Shared Components

• indy-hipe
• ursa

Ocean Protocol

DID management in Ocean Protocol is supported as follow: each Ocean user, asset, and group of users (clan) gets an identity in the form of a DID (Decentralized Identifier) and associated DDOs (DID Descriptor Objects) improving in this way discoverability and usability of data assets.

Sidetree

Sidetree is a protocol that enables W3C Decentralized Identifier (DID) implementations. Sidetree protocol implementations can rely on existing ledgers (e.g., Bitcoin, Ethereum or any other) for anchoring DID management operations. The security properties of corresponding DID Method is dependent on the ledger. Sidetree protocol implementations can be fully open, permissionless and do not need an additional consensus mechanism. The system works without trusted authorities and intermediaries.

User-centric authentication component is integrated in a standard OIDC IAM as federated Identity Provider.

For more detail and source code please refer below link.

Go to the beginning of the page

Other resources of interest

Documentation

Full Developers Documentation