The Best Enterprise Self-Sovereign Identity Platform
Enabling Trusted Digital Interactions
The Right Mix of Standards and Open Source Protocols
NB Orbit Enterprise is a no-code self-sovereign identity platform that facilitates the storage, issuance and verification of verifiable credentials that are held and owned by end users in digital wallets.
The platform contains a collection of technologies and concepts in identity management, distributed and edge computing, distributed ledger technologies and cryptography.
Built for Scale and Flexibility
Easily scale the platform as your usage increases; and embed credential exchanges workflows within your systems.
Built on open standards and technologies such as DIDs, VCs, Aries, AnonCreds and more. Ensures that you won’t face vendor lock-in and will interoperate with global players.
The holders consent to what information they share with the verifying parties. Leverage compounding, predicates, selective disclosure, restrictions, connectionless and more.
Credential Management and Issuance Workflows
Create new, and manage existing Verifiable Credentials that your organization can issue. Govern which employees of your organization can issue what type of credential. Use the Issuance Services to begin issuing credentials to your customers, employees and partners.
Organizational Cloud Wallet and P2P Connections
Store your organization’s credentials within a web-based wallet. Use these credentials to enter into B2B credential exchanges with other cloud wallets. Offer outbound connection invitations to any organization or person. Accept inbound connection requests.
Flexible Credential Verifications
Create any type of proof request that you wish. From a simple instant proof, to a re-usable privacy-preserving proof based on workflows, we got you covered. If you wish to initiate a proof proposal as a holder, it’s easy to do as well.
Frequently Asked Questions
What do you mean by interoperability?
– To avoid vendor lock-in situations, we ensure that the NB Orbit products all use open source standards technologies
– Yes, on the cloud side of things, we have the latest version of ACA-Py deployed, which provides support for AIP 2.0.
– On the mobile agent side, we’re working on enhancing specific RFCs in the AFJ implementation to reach the same.
What identity proofing solutions are included in NB Orbit Enterprise?
Many use cases require a person’s government issued ID to be bound to their mobile wallet. We provide you with best-in-class options for this.
Our identity proofing solutions include,
- Document Authentication – tells you if the identity document has been issued by a governing authority by comparing it to official documents in a document library and through a set of security tests.
- Liveness Testing – One-to-One biometric facial matching with a liveness test determines the genuine presence of a live person by matching the image extracted from an ID to a selfie.
Do you support zero knowledge proofs?
In NB Orbit solutions, the holders have the choice of what information they share with the verifying parties. And not only what information they share, but how they share that information.
We support privacy-preserving proof requests that can use compounds, predicates, data minimization, restrictions, selective disclosure, connectionless and more.
What types of verifiable credential implementations does NB Orbit Enterprise support?
Right now Northern Block is focused on building use cases which are privacy-preserving, thus best suited for AnonCreds (JSON-LD).
Convergence seems to be happening across various elements of the ecosystem. Standards such as OIDC and mDL are all now in dialogue with W3C, AnonCreds, Aries, etc. We will continue adding support for further technologies and protocols as needed.
What signature types do you support?
We support CL signatures. When AFJ upgrades (work which we are contributing towards), we will also support BBS+ signatures.
What are holder-driven workflows?
We believe that holder-driven workflows are going to lower friction in ensuring credential exchanges within the trust triangle.
We’ve written a blog post about why credential issuance should be holder-driven (here). The same is true for verifications.
We are building more and more features that support holder-driven actions.