Brian Mullins

Inside Project Sif

Blog Post created by Brian Mullins Employee on Dec 3, 2018

My previous blog post described how combining the concepts of decentralized identity with verifiable claims creates a powerful new model that allows any person, organization, or thing to interact with any other entity with trust and privacy. This post will delve deeper into the inner workings of Project Sif.


Decentralized IDs (DIDs)

A decentralized identity is a digital identity an individual creates, owns, and controls without requiring the involvement of any centralized 3rd party. Decentralized identities are accessible to everyone and designed with privacy in mind. There are no passwords and no centralized repositories of identity data. The idea is that instead of creating a new digital identity for every digital service you want to consume, you can bring your existing IDs with you, similar to how things work in the physical world.


The RSA Labs Identity Wallet mobile app allows you to manage your decentralized identities.  This includes creating a decentralized identity (equivalent to a pseudonym or persona) which is backed by a public/private keypair. The public key is stored in a publicly accessible location, in this case a blockchain, where it can be accessed by anyone; the private key is stored encrypted on your mobile device.


Verifiable Claims

Verifiable claims are cryptographically signed attestations which can be instantly verified by anyone. They can be issued by governments, banks, or even a friend or family member. Upon reading more about verifiable claims, you’ll undoubtedly stumble across this diagram from W3C:

W3C Verifiable Claims Components


Let’s briefly go through each component to better understand how the model works:

  • Holder – Entity storing and controlling verifiable claims
  • Issuer – Generates claims and sends to Holder
  • Inspector-Verifier – Requests claims from Holder to verify
  • Identifier Registry – Stores a mapping of DIDs with their public attributes (e.g. public keys)


In this model, these components can be provided by disparate vendors. The only trust relationship that exists is between the inspector-verifier and the issuer. This is analogous to how trust works with physical credentials in the real-world. A driver’s license, for example, is issued by a DMV (the issuer) and presented, by the holder, to a liquor store (the inspector-verifier) to prove age.  The liquor store must trust the DMV to only issue valid licenses, which in turn allows it to trust the age claim of the holder of the license.


The RSA Labs Identity Wallet mobile app allows you to store and manage your verifiable claims given to you by issuers. Claims can be imported onto your mobile device and later presented to any inspector-verifier that requests them. Here, the mobile app is fulfilling the role of the holder.


Project Sif Architecture

Putting these pieces together, the Project Sif architecture takes shape:


 Project Sif Architecture Diagram



  • The Android Identity Wallet app is the Holder
  • A Demo Issuer and Inspector-Verifier were introduced for testing
  • The Blockchain is the Identifier Registry and maps DIDs to their public attributes, in this case the DID public keys


Note that in this solution the DID is not the public key. This was done to be able to support the use case of a user revoking a public key and associating a new one with an existing DID.


Data Flow

It’s always helpful to understand a system by seeing how data flows through it. Here’s a sample sequence diagram of a user registering for a new website that requires a verified age claim:


Project Sif: Website registration data flow


Why Blockchain?

It’s important to note that the Identifier Registry as defined by W3C makes no mention of blockchain or any other underlying data storage technology. When considering the combination of decentralized identity with verifiable claims, the Identifier Registry should ideally have the following attributes:


  • Public – To adhere to the philosophy of decentralized identity being available to anyone
  • Decentralized – To prevent a single point of failure/attack
  • Immutable – To provide strong assurances about data integrity
  • Auditable


RSA or any other organization could stand up its own Identifier Registry server, but it would represent a centralized component in a decentralized solution. The solution is more resilient when every component is decentralized. When considering these ideal attributes, a public blockchain checks most of the boxes. The biggest limitation imposed by a blockchain is the throughput, an area of active research by many groups. Other distributed ledger solutions could also fill the role of the Identifier Registry if properly configured – a blockchain is not the only solution.



Project Sif demonstrates how the concepts of decentralized identity and verifiable claims can be combined to create a new model for identity management; a model that brings advantages regarding both security and usability. As digital services move to a decentralized model, decentralized identity solutions will be required. If you have a use case where decentralized identity and verifiable claims could be helpful or want to learn more about Project Sif please reach out to We’d love to hear from you!