The SSO Practitioner’s Introduction to Decentralized Identity

Decentralized identity—also known as self-sovereign identity—is earning a reputation as a silver bullet that can solve all of today’s identity problems. It promises to ensure perfect privacy, informed consent, user independence and control, and the ability to leverage the latest technology and cryptography.

But for those of us who’ve been in the identity industry for some time, these promises might seem far-fetched. We’ve seen too many other purported magical solutions rise and fall over our careers, and evaluating decentralized identity’s true potential is no easy task. Complicating matters is the fact that if you’re coming from a single sign-on (SSO) background of SAML, OAuth or OpenID Connect, you have likely encountered an entirely new glossary of unfamiliar terminology, often conflicting technical descriptions and a distinct lack of actionable standards.

That’s not really too surprising for new technology efforts, though it does make it more challenging to follow. So we thought we’d offer a friendly introduction—mapping concepts you’re already familiar with to the new ones, explaining where there’s a lot of overlap, highlighting some of the differences and demonstrating where decentralized identity is likely to go—without any hype.

One of the first things you encounter when reading about decentralized identity is a daunting array of unfamiliar terminology. While important distinctions exist, there is a significant amount of high-level overlap with the roles and interactions you’re already familiar with.

Let’s start with the decentralized identity role of the issuer. It’s pretty easy to follow that an issuer issues things, and in large part you can immediately connect it to the role of an identity provider (IdP) or OpenID provider (OP) in that one of their primary functions is also issuing things: tokens.

What is an issuer issuing if not tokens? That would be credentials. While a traditional opaque access_token isn’t a good analogy to a credential, an id_token is a better comparison since it is a statement by the ID provider (issuer) about some attributes of the user.

The other easy association is that of the relying party (RP) or service provider (SP) to the new term verifier. A verifier is simply the party or service that verifies and acts on the validity of a credential. While the issuer/verifier terms generally map well to existing concepts, it’s important to note that with decentralized identity, both the issuer and verifier may also be a single individual and not always be a service.

The terminology diverges further when considering the relationship between the above two generalized roles. With SSO and federation there’s a variety of flows with different capabilities, but few of them provide for a distinct or stand-alone third role that sits in between those entities.  In decentralized identity, that middle role is a cornerstone of the architecture and is more formally known as the holder (though typically just called the wallet). Its role is to securely retain digital credentials on behalf of the user (also known as the subject) and protect their privacy.

While it follows that credentials are issued to a holder about a subject, we should highlight the verifier side of a credential flow. It begins when a verifier generates a presentation request to the holder, which, after gathering any user consent, then presents the credential to the verifier.

In summary, decentralized identity follows some very familiar roles and relationships to existing identity management protocols but uses a more action-oriented terminology instead:

• Issuer → identity provider or OpenID provider, issues credentials
• Verifier → relying party or service provider, is presented credentials
• Subject → typically a user or individual, could also be other types of entities
• Credential → crypto envelope of information about a subject, such as an id_token
• Holder → wallet software to manage credentials on behalf of a subject

Possibly the most fundamental difference between decentralized identity and existing identity management is that of trust relationships. What is widely deployed today with SAML and OAuth is bi-directional trust, where two parties that are known to each other have formed some agreement to establish a connection. That connection is then used to share information about the user such as authentication, identity attributes and authorization.

In most self-sovereign and decentralized identity systems the trust model is fundamentally unidirectional, where a verifier will trust the issuer, but the issuer may have no knowledge of the verifier. Importantly, to accomplish this securely and ensure fundamental one-way privacy, the role of the wallet is a critical component. It is a distinct party with its own independent relationship to both the issuer and verifier, and it must provide strong cryptographic capabilities to perform that role.

You might be thinking that such unidirectional trust relationships can be supported with existing solutions and that is quite correct. There are numerous supported mechanisms to approximate those types of relationships with today’s platforms. Where the divergence deepens is in the adoption of more advanced cryptography within decentralized identity, such that the crypto itself guarantees the trust boundaries through the use of zero knowledge proofs and anonymous signature techniques. Newer requirements of those still-evolving security technologies have subtle but important implications that have been easier to accommodate from a clean slate as they grow.

The new first-class role of the wallet is where the promise of privacy and control are enforced in decentralized identity. It is the responsibility of the wallet to act with the trust of the user on their behalf, securing credentials to their personal devices by protecting access using enclaves and strong biometrics, and not revealing any metadata when credentials are used that could lead to tracking of their usage.

The wallet must request informed consent from the user when handling any presentation request to ensure that the user understands what is being shared and with whom, and to minimize what is shared. It must also manage the relationship with one or more issuers of credentials, authenticating itself and negotiating for credentials using the strongest available cryptographic techniques.

If any single distinction is to be made between SSO and decentralized identity, it is that the user trusts the wallet to protect their privacy.

We at Ping Identity are committed to doing the hard work of seamlessly and securely bringing distributed identity capabilities into existing platforms. Along with investing in long-term open standards development to start bridging the gaps, we are also constantly adding new capabilities across all of our products to support the challenges our customers face every day, whether they are distributed or centralized.

The ability to continue increasing everyone’s personal identity privacy and control deeply excites us. You can expect every product and service we offer to advance the state of the art as we help pioneer this future of identity. Learn more about how we’re furthering personal identity with a digital identity wallet.