For the past several years, there’s been a spike in interest in federating digital user identity, largely due to demands brought on by the pandemic. Federation is a popular architecture for connecting users with many different software systems. Yet, federation is not perfect. It’s got numerous shortcomings, mainly from a performance angle.

A new trend has been becoming increasingly prominent among developers. Decentralized identity promises to eliminate many of federated identity’s shortcomings, ensuring greater data privacy while improving performance at the same time.

Curity’s Jacob Ideskog delivered a talk at the 2023 Platform Summit titled “Decentralized Identities Changes Everything, Even Your APIs,” where he explained decentralized identity in greater detail before delving into some ways it’s going to impact the way we currently approach identity, cybersecurity, and authentication.

What Is An Identity System?

Although we highly recommend watching Ideskog’s talk, where he addresses each of these points more thoroughly, it’s worth recapping some of his main points, as they will play an essential part in some of the issues pertaining to decentralized identity we will discuss.

Ideskog begins by briefly defining identity systems, in general, which are systems where one system wants to access another. In daily practice, this is usually a user wanting to access a network. In identity systems, the user is known as the subject, and the system they’re trying to access is called the relying party.

What Is Federation?

Federation acts as a mediator between two systems, primarily to prevent the user from having to input their password repetitively. Under federated identity, authentication is usually handled by an identity provider (IdP). However, this solution has some inherent issues, namely performance and oversharing.

Ideskog calls these issues The Digital Identity Dilemma.

The Digital Identity Dilemma

• You don’t know or control what data is shared
• The issuer knows when and where it was shared
• You need to overshare to prove it

While explaining federation, Ideskog repeatedly returns to the analogy of a passport to illustrate how authentication is handled. When discussing authentication under federated identity, he compares it to each agent having to manually verify the passport’s validity. Decentralized identity means the passport would only need to be verified once, on the other hand.

Federated Identity vs. Decentralized Identity

A side-by-side comparison makes understanding decentralized identity easier. Here are its its advantages in numerous authentication scenarios compared with federated identity.

Federated Identity

• The credential is issued in every login.
• The relying party must call the issuer every time.
• The issuer owns the credential.
• The user doesn’t know what data is being shared with the relying party.

Decentralized Identity

• The credential is issued once.
• The relying party trusts the issuer but can verify on its own.
• The user owns the credential.
• The user (can) know what’s being shared with the relying party.

What Is Decentralized Identity?

Decentralized identity isn’t that dissimilar to federated identity. It uses slightly different terminology, but it’s primarily concerned with the same issues. In decentralized identity, the subject is called the holder. The issuing party is known as the issuer. The relying party is called the verifier.

According to Ideskog, decentralized identity is going to rely heavily upon private keys, which will serve as the digital equivalent of the photo on a passport.

How Decentralized Identity Will Affect APIs

Token-Based Architecture

As we have seen from some of our previous examples, decentralized identity heavily relies upon tokens. To return to the passport metaphor, once a system verifies the passport’s authenticity, subsequent interactions could all be handled with tokens.

As Ideskog succinctly puts it, “If you’re not currently using a token-based architecture, you need to be planning for it.”

Familiarity With OAuth Required

According to Ideskog, OAuth is the only real token-based solution. If you’re not yet proficient in using OAuth for identity management, you need to be.

Perform API Sanity Checks

When you’re using decentralized identity management, you’re going to get a lot more anonymous traffic due to users not logging in. Anonymous users might find themselves without the access they’re used to. Ideskog recommends putting an “API Sanity Check” in place to keep meltdowns to a minimum.

API Sanity Check

• Always use a unique identifier as a subject
  • Independent of the login mechanism
  • Independent of sub-division
  • Independent of the system being accessed
  • Independent of whether the account exists or not
• Always normalize claims

He also recommends a “Token Sanity Check” to ensure consistency across the network. For example, this might entail checking that a field called email is always called email. The Token Sanity Check will also help prevent oversharing, as it will help you think about what data needs to be consumed.

Get To Know Wallets

Wallets are the new identity store, according to Ideskog. While the OpenID for Verifiable Identities standard is still being developed by the OpenID Foundation, you’ll want to make sure you’re comfortable with the most popular wallet formats like Google Wallet or Apple Wallet.

Know Who To Trust

Ideskog recommends breaking down APIs into internal APIs and external APIs. This way, you can know how to extend trust to your internal APIs. For external APIs, he recommends using a single point of trust. How you deal with internal APIs in light of philosophies like zero-trust architecture will differ from case to case.

Final Thoughts on Decentralized Identity

As it stands, identity management is currently facing some difficulties. It’s too tightly coupled, for one thing. And relying on third-party solutions like IDPs emphasizes problems around data transparency and privacy issues. Decentralized identity returns control to the user while improving performance by keeping API calls to a minimum.