Table of Contents
Identity and Access Management System
Today users’ identities and related data are stored in siloes, centralised servers across organizations and are vulnerable to hacking. Repetitive account creation for different applications (e.g. marketplaces), and personal information (often outdated) stored in various services are some other drawbacks of that approach. Distributed/Self-sovereign identities supported by decentralised systems come as a solution for those issues and facilitate interoperability ensuring security and compliance with the privacy regulation.
The objective of the i3-Market Identity and Access Management system is to provide a user-centric authentication based on Self-sovereign Identity (SSI) and following standardization efforts like W3C Decentralised Identifiers (https://w3c-ccg.github.io/did-spec) and W3C Verifiable Claims Working Group (https://www.w3.org/2017/vc), but also to allow wide commercial acceptance and compliance, maintaining compatibility with wide adopted standards like OpenID Connect (OIDC) and current service-centric authentication.
The reference implementation of the i3-Market IAM system is based on the selected open-source technologies for SSI (Uport), OIDC (panva/node-oidc-provider) and standard IAM (Keycloak).
The user-centric authentication is provided by the Verifiable Credentials micro service and the OIDC SSI Provider micro service developed using Uport libraries, while the service-centric authentication is provided by Keycloak
The choice of Uport as SSI technology has been driven from the maturity and readiness level respect of the other state of the art technologies evaluated (Hyperledger Aries, Sidetree) and for the compatibility to the blockchain chosen for i3-Market (Hyperledger BESU).
At this moment Uport has been dismissed and replaced by Veramo technology so the User-centric Authentication component will be migrated to this new technology for the second release (R2) of the project.
Moreover current official European Commission’s initiatives about Blockchain and Self-Sovereign Identity like EBSI and ESSIF will be evaluated to verify possible integrations or synergies.
Decentralised Identity (DID)
Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID identifies any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) that the controller of the DID decides that it identifies. In contrast to typical, federated 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.
OAuth 2.0
The OAuth 2.0 authorization framework is a protocol that allows a user to grant a third-party web site or application access to the user’s protected resources [3]. In this framework, a client requests access to resources controlled by the resource owner and hosted by the resource server. Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token, and optionally, a refresh token. An access token is a basically a string denoting a specific scope, lifetime, and other attributes. Since access tokens have a lifetime, they can expire. The refresh tokens contain the information needed to obtain a new access token. Therefore, whenever an access token required to access a specific resource and the access token has expired, the client can use a refresh token to obtain a new access token issued by the authorization server. The access token is provided by the client to access the protected resources hosted by the resource server. When an application authenticates with OAuth to the third-party web site or application, it specifies the scopes that are needed for that application.
If the user authorizes those scopes, then the access token will represent these authorized scopes and it can be used to access the protected resources.
JSON Web Token (JWT)
The JSON Web Token (JWT) is an open standard (RFC 7519) that defines a schema in JSON format for exchanging information between various services [2]. The generated token can be signed (with a secret key that only those who generate the token know) using the HMAC algorithm, or using a pair of keys (public / private) using the RSA or ECDSA standards. JWTs are widely used to authenticate requests in Web Services and OAuth 2.0 authentication mechanisms where the client sends an authentication request to the server, the server generates a signed token and returns it to the client who, from that moment on, will use to authenticate subsequent requests. The structure of the token consists of 3 fundamental parts:
- Header
- Payload
- Signature
The header contains two main information: the type of token (in this case valued to JWT because it is a JSON Web Token) and the type of encryption algorithm used.
{
“alg”: “HS256”,
“typ”: “JWT”
}
The payload contains the interchange information. It is possible to categorize them into three blocks:
- registered parameters: they are predefined properties that indicate information about the token (issuer, audience, expiration, issued at, subject)
- private parameters: here it is possible to enter new fields, such as verifiable claims, having full extensibility thanks to the JSON structure
- public parameters: they refer to parameters defined in the IANA JSON Web Token Registry, they can be compiled at will by paying attention to the content that is entered to avoid conflicts with the registered and private parameters
{
“iss”: “app_name”,
“name”: “Mario Rossi”,
“iat”: 1540890704,
exp”: 1540918800,
“user”: {
“profile”: “editor”
}
}
The token is generated by encoding the header and payload in base 64 and joining the two results by separating them by a “.”, then the algorithm indicated in the header is applied to the string obtained using a secret key. It is possible to verify and unpack a JWT online using the official website.
Fortunately, it is not necessary to re-implement the encryption logic, there are many libraries to generate JWT depending on the programming language. Security is guaranteed by the fact that the token is signed with a server-side secret key, so if it is corrupted or modified by an external agent, it will not pass validation.
OpenID Connect (OIDC)
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management, when it makes sense for them.
Self-Sovereign Identity (SSI) and Blockchain
Today users’ identities and related data are stored in siloes, centralised servers across organizations and are vulnerable to hacking. Repetitive account creation for different applications (e.g. marketplaces), and personal information (often outdated) stored in various services are disadvantage of that approach.
Self-sovereign identities supported by decentralised systems come as a solution for the following issues:
- Identity and personal data are stored with the user
- Claims and attestations can be issued and verified between users and trusted parties
- Users selectively permission access to data
- Data only needs to be verified a single time
Blockchain technology, proving decentralization, immutability and cryptographic security, allow the creation of credentials that could be issued and verified without the need of a central certification authority and could be owned by the end users and directly shared with third party without involving the credential issuer.
Verifiable Credentials (VC)
As in the physical world, a credential is a set of information that identify an entity. In particular, the information represents:
- Information related to identifying the subject of the credential (for example, a photo, name, or identification number)
- Information related to the issuing authority (for example, a city government, national agency, or certification body)
- Information related to the type of credential this is (for example, a Dutch passport, an American driving license, or a health insurance card)
- Information related to specific attributes or properties being asserted by the issuing authority about the subject (for example, nationality, the classes of vehicle entitled to drive, or date of birth)
- Evidence related to how the credential was derived
- Information related to constraints on the credential (for example, expiration date, or terms of use).
A verifiable credential can represent all of the same information that a physical credential represents. The addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts.
Holders of verifiable credentials can generate verifiable presentations and then share these verifiable presentations with verifiers to prove they possess verifiable credentials with certain characteristics.
Both verifiable credentials and verifiable presentations can be transmitted rapidly, making them more convenient than their physical counterparts when trying to establish trust at a distance.
Verifiable credentials are useful in a Self-Sovereign Identity ecosystem because they assert information about the user to whom a credential is issued and can be directly verified by any third party with involving the Issuer. In the context of the project, users are asked to disclose verifiable credentials, which attest particular attributes issued by a specific Data Marketplace. The certified attributes and permissions are used to obtain an OAuth access token that allows the use of Backplane services or access to resources in the marketplace. Verifiable credentials are therefore used as proof method in the authorization flow. If a credential is valid, it means that the user is authorized to access a resource or service that requires the holding of that credential. For this reason, a service that generates verifiable credentials is necessary. Once a verifiable credential is saved by users in their wallets, anyone who receives the verifiable credential and has access to the DID of the users can then confirm that the verifiable credential has been issued by a trusted server and has not been revoked for some reason.
Free* Open Source Software Tools for SMEs, Developers and Large Industries Building/Enhancing their Data Marketplaces.
For more detail and source code please refer below link.
