Self-Sovereign Identities (SSI) – an incubating feature

Self-Sovereign Identities (SSI) is the underlying standard for the new E-ID in Switzerland and the EUDI in the European Union. The standard is still evolving, and many questions regarding the protocols and formats will only be answered in the next couple of months or even years.

Nevertheless, the concept of Self-Sovereign Identities is a game changer in how citizens, customers, and employees share data with authorities and companies. To allow customers to explore these new opportunities, we have implemented a functionally rich yet still simple solution for Self-Sovereign Identities in Airlock IAM.

Self-Sovereign Identities is an incubating feature. It is intended to implement proof-of-concept use cases and it is expected that the plugins provided will change fundamentally and without further notice in future releases of Airlock IAM.

Self Sovereign Identities (SSI) or decentralized identities are a new paradigm in identity management that puts the end-user in control of all personal data.

• The end-user, called holder in SSI terminology, operates a wallet app on the mobile device. This wallet stores personal data, called verifiable credentials in SSI terminology and it also implements the SSI protocol to interact with issuers and verifiers.
• Issuers are actors in the SSI system that provide the holder with verifiable credentials. Issuers are meant to be the authoritative source of information and to provide personal data attributes, called claims in SSI terminology, in a verifiable format.
• Verifiers are actors in the SSI system that request claims from holders. It is the holder's decision whether or not to approve this request and to provide the verifier with a verifiable presentation. If the request is approved, the verifier obtains the data and irrefutable proof about the issuer of the data.

A simple SSI use case would be the state issuing a driver's license as a verifiable credential into the holder's wallet.

A policeman could ask for the presentation of the driver's license. If the holder accepts this request, the policeman's system will automatically check that the license is valid, has not been tampered with, and that the issuer is considered trustworthy.

To use the SSI steps in IAM flows an additional component needs to be deployed and this component must also be reachable from the Internet.

• Important properties of the system architecture are:
• There is no direct communication between the wallet app and the Airlock IAM flows.
• The wallet communicates with an ACA.Py (Aries Cloud Agent) over SSI protocols and through a ngrok reverse proxy tunnel.
• The system browser communicates over REST API calls with the Airlock IAM flows.
• The SSI plugins in Airlock IAM connect to the ACA.Py instance over SSI protocols.
• Both Airlock IAM and ACA.Py use their own databases.

The architecture with ngrok as a tunnel is suitable for a test setup and should be amended for a production use case.

Currently, there are multiple competing technologies to specify and implement the SSI protocols and verifiable credential formats. Airlock IAM uses the technology from the Hyperledger Aries project:

Hyperledger Aries is your complete toolkit for decentralized identity solutions and digital trust. Issue, store, and present verifiable credentials with maximum privacy preservation, and establish confidential, ongoing communication channels for rich interactions. It supports multiple protocols, credential types, ledgers, and registries. It has frameworks in multiple development languages, interoperability tools, and profiles to help everything seamlessly work together.
Source: Hyperledger Aries

• The current implementation of SSI in Airlock IAM has been tested with the following ledgers:
• British Columbia Test Ledger
• Public Sandbox Trust Infrastructure

Since the implementation is based on Hyperledger Aries, other ledgers could also be used.

As shown in the architecture overview, integrating a ledger with Airlock IAM requires an additional component to run in parallel.

• Airlock IAM has been tested with ACA.Py:
• See Hyperledger Aries Cloud Agent - Python (ACA.Py) on GitHub for more details.

• The following are known limitations of the SSI implementation:
• It is not possible to manage or create credential schemas or credentials definitions with Airlock IAM.
• It is not possible to reuse existing connections. All flows must be initiated with a QR Code to establish a new connection between a wallet and ACA.Py.
• It is not possible to configure self-registration to obtain claims from a verifiable presentation and pre-fill a data edit step.
• There is currently no support for a mobile-only use case. To establish a connection, the end-user must be able to scan the QR code presented by Airlock IAM in a browser window.