On SSI-enabled IdP Solutions
How to combine Identity Provider (IdP) infrastructure with cloud & edge SSI wallets
Many people in the decentralized identity world are working on brown field implementation scenarios to drive adoption of Self-sovereign Identity (SSI) wallet technology. In these scenarios existing X.509 PKI or federated identity solutions are combined with cloud and edge SSI wallets.
This blogpost summarizes capabilities and use cases we are addressing at Spherity with focus on hybrid solutions for integrating federated identity IdP and SSI solutions. The article is structured along hybrid design patterns for the following uses cases:
- Enterprise wallet and business system authentication using OAuth 2.0 token (authentication of system users)
- Single Sign-on (SSO) for organisational wallets of enterprise business users
- Multi-tenancy custody SSI business solutions
- SSI-enabled IdP with cloud custody employee wallets
- Acquiring credentials from issuers and inheriting verifiable credentials from IdP assertions for SSI wallet users
- Authentication of unknown SSI wallet users against an SSI-enabled IdP and creation of new IdP assertions
- Open ID Connect (ODIC) for credential and presentation exchange
Some of these use cases are simple and straight forward in terms of blending both technology stacks together. The simplest use case is the “Enterprise Wallet and Business System Authentication using OAuth 2.0 token” (1.). This use cases focuses on the authentication of ‘system users’ while all other use cases are typically addressing human users.
In the most advanced use case “First Implementer’s Drafts of OpenID Connect SIOPV2 and OIDC4VP Specifications” (7.) there is a lot of research and early standardization work involving the OpenID Foundation ongoing. This use case is however of special interest and value as an extension strategy by adding SSI to existing OIDC infrastructure could lead to rapid adoption.
As there are multiple flavours and implementation alternatives most of our solutions are either product specific implementation or custom-built ecosystem solutions for a given use domain. We are explaining our Spherity wallet solution options and configurations in the following paragraphs.
Hybrid models of X.509 certificates and SSI wallets are out of scope of this article.
Our Work at Spherity
Our product focus at Spherity is on use cases (1.) to (5.). We established solutions for multiple field tests and are now releasing a commercial product for supply chain use cases using solution components of (1.) to (3.) while having built pilot solutions for (4.) and (5.). In the meantime, we are doing research on (6.) and (7.).
Most of this work involves the following technology capabilities of our Spherity Wallet solution:
Our wallets support the following non-functional requirements (NFRs):
NFR001: Authentication & Authorization; Only the authorized user of an enterprise can access the Wallet application via an user front-end.
NFR002: Security — Data Authorization & Encryption; Data at rest and in transit shall be protected, any sensitive data must be encrypted and protected.
NFR003: Security — Non-repudiation; The system must prevent the initiator (user) of a transaction from later disputing the creation of a given transaction.
NFR004: Security — Key Management & Rotation; Key rotation best practices applied to regularly change signing and encryption keys.
NFR005: Security — Platform & Network Security; The system must adhere to platform security requirements. Cloud architecture should ensure the E2E enterprise system flows are secured from attack. Since the system handles business critical data, the measures taken to protect data are defined in the context of a customer project. Privileged access to system components is minimized and strictly controlled.
NFR006: High Availability; Digital Wallet and credentialing solution systems must be resilient to single points of failure or outages
NFR007: Maximum system response time; depends on customer project or ecosystem conformance criteria requirements and the chosen wallet technology platform.
NFR008: Disaster recovery; DR capabilities are added to our wallet for custom built solutions.
NFR009: Extensibility & Customizability; The solution must be able to support additional use cases for authorized trading partner verification, including the exchange of additional enterprise compliance credentials.
NFR010: Audit Requirements; Solution provides audit logs of interface access as well as of generation and verification of verifiable presentations. Solution can log corrUUID so that transactions are correlatable across systems and wallets of the trading partners.
NFR011: Archiving; The solution support audit trail archiving requirements. Data placement, data retention and preservation of evidence are implemented based on customer or ecosystem conformance criteria requirements.
NFR012: Crpyto-agility; feature required for compliance use cases and preservation of evidence requirements. The implementation options are an emerging discussion in the SSI ecosystem and is not yet supported by Spherity.
Use Case 1: Enterprise wallet and business system authentication using OAuth 2.0 token
A typical use case scenario is to connect SSI wallet solutions with enterprise systems (system users) in a secure way so that a legacy enterprise system can be retrofitted. This retrofitting approach leverages SSI wallet capabilities for acquisition and exchange of verifiable credentials between enterprise wallet implementations. Typical Spherity use case applications examples are:
- Authorized trading partner application enabling supply chain systems to securely authorize trading partners in accordance with official trading partner license status information
- Third Party Risk Management or Supplier On-boarding application using SSI wallets to acquire and exchange master data and supplier on-boarding credentials
- Product passport application for issuing and sharing product assertions from an enterprise ‘system of records’ in from of verifiable credentials with downstream trading partners and government entities
- Supply chain track & trace application sharing supply chain data in form of verifiable credentials
In a typical implementation pattern the wallet application and the legacy system are integrated in the following set-up either directly or via an API gateway (see figure 1 for details).
Interface Type: REST API
Authentication: API Gateway, JWT Bearer Token (OAuth 2.0)
Encryption: SSL TLS v1.2
Connection: REST on HTTPS
Use Case 2: SSO for organisational wallet of enterprise business users
Moving on from ‘system users’ to ‘human enterprise users’, the integration of a legacy Identity & Access Management (IAM), Customer IAM (CIAM) or SSO solution with SSI wallets enables enterprise users to sign on to a wallet business application via their SSO credentials.
At Spherity we worked on multiple use cases blending human authentication business logic for administration, custody wallet user management, dashboard analytics, audit trails, or industry domain data exchange protocols (e.g., GS1 lightweight messaging protocol for supply chain use cases) with SSI wallet agents.
The key objective is to provide authentication and authorization capabilities for enterprise users to access enterprise wallet business applications.
In principle there are two implementation options for enabling enterprise users to sign into an enterprise wallet business application:
- Edge wallet (smart phone) authentication and authorization credentials
- SSO credentials
The more simpler enterprise SSI wallet use cases in our portfolio do not require human user to rely on ‘human SSI wallets’. Therefore, we are providing solutions to integrate an enterprise IdP or SSO infrastructure with ‘enterprise SSI wallet’ for the use cases outlined above.
Such SSO capabilities are very handy for securely authenticating and authorizing enterprise wallet users or administrators. Our solutions typically provide logging functions for non-repudiation of user activities for audit and compliance purposes. A typical integration pattern is described below (see figure 1 for details as well):
Interface Type: Front-end application consuming cloud wallet REST APIs
Authentication: JWT Bearer Token (OAuth 2.0)
Encryption: SSL TLS v1.2
Connection: REST on HTTPS
Use Case 3: Multi-tenancy custody SSI business solutions
A further advancement of the IdP and wallet integration infrastructure is to provide multi-tenancy features for user authentication and authorization across multiple user accounts and technical tenants. It shall understood that there are multiple levels of tenancy depending on the categorization of a business application (e.g. GDPR, ERES, LOA) and the respective controls and compliance requirements.
- Isolated Tenancy: Basic level of tenancy: None of the layer is shared among the tenants. Each tenant has their own infrastructure, database, and application. The infrastructure is physically isolated.
- Infrastructure Tenancy: Underlying infrastructure for the application is shared across tenants. The database and application layers are separate for the tenants.
- Application Tenancy: It will have the application code and infrastructure shared by each tenant. The database is still separate for each tenant.
- Shared Tenancy: This model has infrastructure, database and application that are shared among all the tenants.
At Spherity we support all levels of tenancy. In this paragraph we focus on the ‘application tenancy’ and ‘shared tenancy’ case: Multiple enterprise customer and their users are sharing one cloud-based infrastructure.
Such a solution is beneficial for enterprise wallet solutions when production unit costs of must be very low and application or shared tenancy are supported from a compliance requirement perspective.
IdP implementations are using two types of tokens: JWT identity and JWT access token. As we are sharing infrastructure, we are leveraging the access tokens for the multi-tenancy implementation by adding a custom field with information such as the user tenant’s legal entity or its pricing plan.
By using the custom field, we can control access of customer users to their respective tenant accounts. Spherity’s IdP set-up can be configured to serve multiple tenant, user and role configurations (see figure 2).
Use Case 4: SSI-enabled IdP with cloud custody employee wallets
In some of customer implementation we are providing cloud custody SSI wallets for enterprise users.
This approach is in contrast with the use of edge wallets that are out of control of an enterprise infrastructure unless there are wallet attestation instruments to prove an validated edge wallet is used by the user. However, wallet attestation instruments are just about to emerge in the SSI ecosystem.
When there are no wallet attestation instruments an end-user smart phone wallet must be considered unknown and therefore neither an issuer nor a verify (or relying party) can validate if such a wallet was implemented in accordance with given conformance criteria. Such an unknown wallet cannot be trusted.
Therefore, in many enterprise user wallet use cases it is beneficial to provide an enterprise custody wallet solution for the enterprise business users in a controlled environment that is highly efficient in terms of maintainability and operability as well.
When the wallet IdP is integrated with enterprise SSO capabilities users can be easily on-boarded with the enterprise custody wallet cloud solution using their SSO credentials. Enterprise custody wallets can be provisioned in a very efficient way (see figure 3 for details).
In case of edge or smart phone wallets the SSO feature can be integrated as well in order to provide an instrument ensuring that only SSO-authenticated edge wallet users are interacting with corporate SSI infrastructure services.
Use Case 5: Acquiring credentials from issuers amd inheriting verifiable credentials from IdP assertions for SSI wallet users
In the scenario described above our SSI-enabled IdP interacts with an enterprise custody wallet infrastructure.
The enterprise custody wallets can be integrated with company internal services such as HR databases for employee training for issuing verifiable credentials or external services; e.g., Progeny KYC service (see figure 3 for details).
One of the use cases we did at Spherity was for a post-merger scenario of two US companies. By law some internal services shall be only made accessible for US citizens. By using enterprise wallets and an external KYC provider employees got citizenship credentials in a complex corporate infrastructure that were used for access control of internal services APIs.
Internal services that issue employee credentials are very useful in corporate environments. Employee role, authorization, qualification and training credentials are among the important credentials types. These credentials are use for use cases such as API endpoint authorization (e.g. for remote maintenance workforce access) or QA and trusted release processes. In all these processes authorization activities are preformed and companies are often obliged to create audits trail to prove that manufacturing processes were performed in accordance to SOPs and with qualified employees only.
Credentials can be issued be internal or external services to an employee wallet. As many employee assertions are stored in the IdP system an ‘SSI-enabled IdP’ can issue credentials about these exact assertions to the employee. In custom-built implementation we created automated processes to derive employee credentials from employee master data derived of the IdP user database (see figure 4). Such an approach requires a GDPR compliant set-up in an enterprise.
It shall be understood that such a set-up can be implemented for enterprise users and enterprise customers. In case a CIAM IdP has information about a customer’s driver license this information can be issued as verifiable credential and acquired by the (cloud or edge) wallet of a mobility customer. Again, this will only work for a GDPR compliant set-up and when an informed user consent is in place for such a scenario. We implemented such a scenario in a mobility as a service (MaaS) use case with our customers (doorman approach).
Use Case 6: Authentication of unknown SSI wallet users against an SSI-enabled IdP and creation of new IdP assertions
When an SSI-enabled IdP is in place the IdP can authenticate and authorize unknown users via their SSI credentials, register these users in the IdP database and create user IdP assertions that are derived from the verifiable credentials and updating the auth tables of the IdP (see figure 4).
Such a set-up can be technically implemented with our solution for a variety of use cases. We implemented such a solution for the above mentioned MaaS use case as well.
The challenge for such implementations is that secure processes for credential acquisition, wallet attestation and wallet operations must be deployed in in accordance with a trust framework and respective policies and conformance criteria.
This is especially the case for interactions with unknown users and their unknown wallets. Quality trust frameworks for regulated use cases are usually not in place and therefore security and compliance of the end-to-end solution cannot be ensured.
Use Case 7: ODIC for credential and presentation exchange
The OpenID Foundation recently released an approved “First Implementer’s Drafts of OpenID Connect SIOPV2 and OIDC4VP Specifications” (7.) focusing on two standardisation artifacts (specifications release on Feb 8, 2022, can be found here):
(a) Self-Issued OpenID Provider v2 (SIOP)
(b) OpenID Connect for Verifiable Presentations
OpenID Connect defines mechanisms by which an End-User can leverage an OpenID Provider (OP) to release identity information (such as authentication and claims) to a Relying Party (RP) which can act on that information.
The SIOP specification (a) extends OpenID Connect with the concept of a Self-Issued OpenID Provider (Self-Issued OP), an OP which is within the End-User’s local control. End-Users can leverage Self-Issued OPs to authenticate themselves and present claims directly to the RPs. This allows users to interact with RPs directly, without relying on third-party providers or requiring the End-User to operate their own hosted OP infrastructure.
The Verifiable Presentation specification (b) defines an extension of OpenID Connect to allow presentation of claims in the form of W3C Verifiable Credentials as part of the protocol flow in addition to claims provided in the id_token and/or via UserInfo responses. This specification extends OpenID Connect with support for presentation of claims via W3C Verifiable Credentials. This allows existing OpenID Connect RPs to extend their reach towards claims sources asserting claims in this format. It also allows new applications built using verifiable credentials to utilize OpenID Connect as integration and interoperability layer towards credential holders. This specification enables requesting and delivery of verifiable presentations in conjunction with Self-Issued OpenID Providers as well as traditional OpenID Providers.
The wallet-to-wallet communication approach using OIDC for credential and presentation exchange is also being investigated in the IDunion project.
Spherity plans to implement a first version of the protocols in the second half of 2022 into our cloud identity wallet solution.
Conclusion
The extension of IdP solutions with SSI capabilities provides a lot of value for current and future ecosystem product solutions with particular value of retrofitting existing federated identity infrastructures.
At Spherity we prefer to implement the SSI technology in more controlled business environments where trust frameworks have a high maturity which is typically not the case for human ID use cases with unknown users and wallet implementations in open ecosystems.
As there are no trust frameworks for open ecosystems for human identity, we consider technical implementations for this use cases domain as experimental (or closed).
Therefore, our current product focus addresses enterprise organisation and object identity compliance use cases by developing solutions for the first three IdP and SSI use cases:
1. Enterprise Wallet and Business System Authentication using OAuth 2.0 token
2. SSO for Organisational Wallet for enterprise business users
3. Multi-tenancy custody SSI business solutions
As a second priority we recommend focusing on controlled environments for enterprise systems and employee identity for use cases such as enterprise access control, audit trails, process approval events or trusted release. These use cases require the following capabilities:
4. SSI-enabled IdP with Cloud Custody Employee Wallets
5. Inheriting verifiable credentials form IdP assertions for SSI wallet users
When environments are not controlled and open there can be value in
6. Authentication of an unknown SSI wallet users against an SSI-enabled IdP
but we believe that trust frameworks are not mature enough to support the respective use cases.
As mentioned above we see a lot of value in
7. OIDC for credential and presentation exchange.
This OIDC capability can be of significant value to provide a secure and proven protocol for wallet-to-wallet communication. Simply put, these two new OIDC specs open the world for established implementations (mobile and web) to rapidly evolve into the new world of decentralized architectures where the ‘holder’ holds cryptographically-verifiable claims in their own device (instead of ‘phoning home’ each time).
For more detailed information about us, feel free to reach out to Spherity. You can also follow Spherity on Medium, Twitter, LinkedIn or sign up for our Newsletter.
