Contents hide
What’s the fuzz about decentralized identity?
Authorities, certificates, and watchful eyes
Interlude: TLS certificates and the realm of universal standards
The joy of online accounts
Managing Decentralized Identities using filancore’s stack

Alice and Bob had a nice day, no user complaints today, and no new requirements to implement. So they used the opportunity to prepare for some knowledge transfer in the office. After her last research into decentralized identities, Alice was very motivated to focus this session on decentralized identities.

Bob agreed that it would be a nice topic. After all, apart from their use of decentralized identities for the over-the-air update project, the team used a plethora of other identity management solutions: Active Directory for the work accounts, GPG keys to verify their commits, SSH keys to identify against servers, and PKI infrastructure with certificates for encryption needs. What a complex way to say “I’m myself”.

illustration of the digital “identity” of one human being
Digital identities for a single human being

Now, they were sure, this hideous illustration of the digital “identity” of one human being was a great way to start a discussion on decentralized identities.

What’s the fuzz about decentralized identity?

Alice now wondered what would be a natural introduction to the topic. The obvious real-world example would be your state/employee/student/… ID card. You have your identity, you can present it to others, and they don’t need to call someone else to believe you who you are. One ID to rule them all. Theoretically, the same is true for basically all of the aforementioned keys and accounts, for sure. So what’s so special about a decentralized identity?

With her knowledge about different DID methods, Alice asked for Bob’s opinion on the following:

A decentralized identity is like a password manager for digital identities: you own a master key to your “vault” and its content provides you with means to prove your identity to the world around you.

“Sounds handy, doesn’t it?” “Definitely quite an attractive vision. Now we just need some slides with an explanation why it’s maybe not the whole truth.”

Said and done, the low-hanging fruits here definitely are the keys in various formats. So Alice decided to pick up her personal did:web as an example

Contents of did:web:example.com:alice
{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/v2",
    "https://w3id.org/security/suites/secp256k1recovery-2020/v2",
    "https://w3id.org/security/suites/ed25519-2018/v1"
  ],
  "id": "did:web:example.com:alice",
  "verificationMethod": [
    {
      "id": "did:web:example.com:alice#p-256",
      "type": "EcdsaSecp256k1VerificationKey2019",
      "controller": "did:web:example.com:alice",
      "publicKeyJwk": {"alg":"ES256","crv":"P-256","kty":"EC","x":"qDurXD6jd-AV6kBTSAoh-_S7Db-b1crGZnGyV7oPwZg","y":"fVO10kQe5FaZ-wIvOdZg14Gk6YRYGhmZN9D5hiGF9vA"}
    },
    {
      "id": "did:web:example.com:alice#ed25519",
      "type": "Ed25519VerificationKey2018",
      "controller": "did:web:example.com:alice",
      "publicKeyJwk": {"alg":"EdDSA","crv":"Ed25519","kty":"OKP","x":"N0mLlohrssice3LABO1n4GfFdtq_8AYAms6JhoZ4P8I"}
    }
  ],
  "authentication": [
    "did:web:example.com:alice#p-256",
    "did:web:example.com:alice#ed25519"
  ],
  "assertionMethod": [
    "did:web:example.com:alice#p-256",
    "did:web:example.com:alice#ed25519"
  ],
  "keyAgreement": ["did:web:example.com:alice#ed25519"],
}

Relying on the trust in the WWW’s TLS certificate chain, this did:web publicly assigns two keys to belong to Alice who is the only one able to complete any challenge requiring the private keys belonging to the public parts of did:web:example.com:alice.

The private keys itself can even come from different sources. For instance, Alice’s private P-256 key is safely stored in her laptop’s trusted platform module (TPM) whereas her private Ed25519 key is stored in SSH’s textual representation on her file system. Still, she has access to both, so she could complete cryptographic challenges with them.

Now, there’s one missing link here: a third party may still need a different representation of these keys. Fortunately, it’s relatively straight-forward to write adapters for these things, e.g., a custom SSH agent that can translate the keys and signing requests as needed. Bob was intrigued, he was definitely trying to write such a thing when he got some spare time for tinkering again.

Illustration of decentralized identity: Alice using a digital vault to manage multiple cryptographic keys (e.g., did:web) stored in trusted hardware and files, enabling her to prove her identity without centralized verification.
Communicating keys to the world

After drawing up a sketch, Bob had to confess, “somehow, this setup looks more complex than before”. “Indeed. There is the adapter layer of the custom SSH agent. Maybe we should summarize the benefits then”:

  • One place to claim identity: the DID is where Alice publishes her keys. Not one publication per key type, one place for all the keys.
  • A clear route for others: Alice can present her DID and a friend of her can grant her access to his servers/resources/… by granting access to one of her public keys. The same is true for her IT department that does not need her to send over the public SSH keys per device anymore when they know where to look.
  • Independence of storage: A DID communicates keys and their functions (verification method, authentication, …). It does not say where the key is stored and in which format. An SSH key file will look the same as a TPM-generated key as one obtained from a hardware security module.

“Okay, so we’ve got the low-hanging fruits covered. What’s next?” “Let’s look at the elephant in the room, PKI-based certificates.”

Authorities, certificates, and watchful eyes

Alice began to describe the issue, “in public key infrastructure like for the S/MIME example, you have a certificate authority that issues the certificate. Because that authority is a root in the web of trust of your local certificate store, it is accepted. Thus, those trusted certificate authorities are the backbone of certificate issuance, preventing decentralized identities to work here because they would fall out of the chain of trust.”

Bob wondered, “if it is that far from decentralization, why are we even considering this use case?” “Well, it’s because we have a solution for this. It may not be as standardized as e-mail encryption using S/MIME but e-mails are text messages after all, so we will be fine, just stay with me for the ride.”

Then, Alice started to outline how the certificate chain is completely irrelevant when two people with DIDs communicate with each other, in this example, Bob wants to send Alice a message:

  • Bob looks up Alice’s DID and finds a public key of hers. (If he does not have her e-mail address, he may even get that from the DID if Alice added it to the services section.)

This is actual the crucial step in replacing PKI. The DID method and its guarantees are now what defines the trust model. Instead of trusting a certificate authority, Bob decides whether to trust Alice’s DID.

  • He then writes his e-mail and encloses it into a verifiable credential. The issuer being his and the subject being Alice’s DID.
  • Using common JOSE tooling, he encrypts the content and encloses it in a JWT. The JWT payload will contain his DID in unencrypted form next to the claims and therefore expose a reference to his DID so that Alice knows which public key of his to use.
  • He then sends the JWT to Alice’s e-mail address.
  • Alice then decrypts the e-mail by checking the JWT signature for the credential. The credential’s issuer identity (DID) she just used to verify the signature is also what she uses to look up Bob’s public key. She then uses her private key for the public key of hers referenced in the credential’s subject to decrypt the actual content.

Bob acknowledged, “well, this is actually not that much more complex than other e-mail encryption schemes, so for this use-case it seems like a perfectly suited replacement of PKI certificates”.

Visual explanation of decentralized identity replacing traditional certificate authorities: Bob sends Alice an encrypted message using DIDs and verifiable credentials, bypassing the need for centralized trust roots in public key infrastructure.
Replacing S/MIME with VCs in Alice’s key landscape

“Great, so we’ve got keys covered and PKI certificates. That only leaves the online accounts, right?” “Basically, yes, but let’s jot down some bullet points for the slides first.”

  • Cost efficiency: You don’t need a CA for the certificate, all you pay are the storage costs of your DID which may be free hosting for some methods, your existing web hosting for did:web, or ledger transaction and storage fees for methods like did:iota.
  • Cut off bureaucracy: No need for lengthy processes to get a certificate. Issue as many identities as you wish, go through lengthy processes only if you want recognition in some highly official did:web or similar.
  • Meet signature and encryption needs with a flexible set of options, don’t be limited by what a CA offers you, add whatever key material your sources (TPM, HSM, …) throw to your feet (see also the last section).
  • Never circumvent your trust sources: You will never again need to install custom root CAs on devices, you scale your trust model yourself, from identities to organizations to the scope of whole did methods.

Interlude: TLS certificates and the realm of universal standards

Bob admired Alice’s enthusiasm for the topic. But he was getting tired of knocking over all the established security models and thinking through new ones. So he leaned back and challenged Alice, “That was a tough ride. So after we ‘eliminated’ the need for PKI, why don’t you solve the other basic security challenges of the internet with credentials. How about replacing TLS certificates?”

“Well”, Alice admitted, “this is kind of awkward because there is a huge momentum of the web ecosystem towards some blessed implementations of TLS. It’s rarely plug and play so we can’t really establish TLS with verifiable credentials if we don’t control server and client. But if we do, there are ways.”

That piqued Bob’s interest. After some elaboration on Alice’s part she referred bob to an interesting IETF draft that outlines the use of verifiable credentials as alternative to certificates in TLS. The cybersecurity research group of the LINKS foundation even has implemented and open-sourced some prototype integrations into OpenSSL.

“Interesting question, Bob, but let’s keep this out of the workshop, it’s a bit too experimental and less practical.”

The joy of online accounts

“Fine by me, Alice, but you still have nearly exceeded my attention span. I hope your solution to the remaining centralized authentication/authorization parts is simple.” “It most definitely is. We already discussed it a few weeks ago, remember?”

Alice rummaged around for their sketches of the over-the-air update process they designed in collaboration with Fred. “Oh well, yes, we have credentials and we already used them with SIOPv2 and OID4VP, basically authenticating by proving ownership of a credential using a verifiable presentation. Is it really that easy?”

Unfortunately, Alice had to concede that there was a catch: this replacement only works if you can be your own identity provider. So you cannot simply authenticate against a Microsoft Active Directory and claim to be someone without the credentials that service knows. So you need to influence the identity provider …

… or add a bridging service that translates your SIOPv2+OID4VP requests in a yes/no response for authentication or authorization which you can add as separate means for authentication in many identity providers (Ory Kratos, Keycloak, …). So for her personal Matrix account on her self-hosted Matrix server Alice is fine. But her work account for the office suite using an Active Directory is intractable, for now.

“So, just to make sure I understand this: we basically do the same thing as we did with the custom SSH agent here? We add a simple proxy service that translates claims and are able to use decentralized identities instead of centralized ones?” “Yes, exactly. You can look at it as the AuthFediverse: authenticate using decentralized means but access resources on a central service as you are used to.” “You got me there, let me try to write the summary this time.”

  • Accessing central resources using decentralized identities: your identity provider does not need to know about all identities, it just needs to know how to determine which ones to accept. You want to allow all Bluesky users to comment in a Matrix room? Allow appropriately did:plc-signed presentations on your homeserver and each of those users has access without you having a comprehensive list of them.
  • Change your password without ever changing a password: you don’t need to know a password for your account anymore, you (or your TPM, HSM, …) only need the private key to your identity to sign verifiable presentations. Don’t have that key anymore? Revoke it through your identity.
  • Tell others what they need to authenticate or authorize you: what we discussed with SSH in the beginning, the DID tells others how they can let you in without them creating an account for you.
Diagram showing decentralized authentication using verifiable credentials and identity proxies to access centralized services, enabling login without passwords or traditional identity providers by proving key ownership via protocols like SIOPv2 and OID4VP.
Using OIDC to avoid username_password login

Alice smiled. With this last point, things have come full circle for the workshop. And everything but the Active Directory has been successfully decentralized. Maybe the world is not yet ready for full decentralization. On the other hand, this is going to be a very promising picture to paint for the team.

Managing Decentralized Identities using filancore’s stack

If we had to give a similar workshop to the one Alice held at the office, filancore would have shown you the following:

  • Full decentralized identity management for various DID methods and key formats.
  • Management of verifiable credentials from issuance to revocation.
  • SSI-based login using the open standards SIOPv2 and OID4VP via OIDC.
  • An SSI-aware SSH agent that retrieves key material directly from your machine’s TPM.
  • SSI-based solutions for over-the-air updates, data integrity, and many more.
filancore products & services

If you are interested in SSI or have a use case involving decentralized identity management, authentication, or authorization, we would be happy hearing from you. Just use the contact form below: