Decentralized identity: The Direct Presentation model
Published Feb 02 2022 10:00 AM 14K Views

Take a look in your physical wallet. Maybe you have some credit cards and probably identification of some kind. Do you have a roadside assistance card, perchance? The cards we carry and present every single day feel different than many common digital credentials (such as federated credentials) that identify us and communicate our attributes online, but that gap is narrowing. 


As the identity ecosystem looks at emerging paradigms for trust and individual agency in our online interactions, we see use cases where the federated identity model we know so well in the real world might work to provide more digital autonomy and control. We call this model the “presentation model” because an end user collects and controls the presentation of their credential when and where they choose. The presentation model does not replace online federated models, but instead, each model can be used where most valuable.


Part one of our series introduced our 5 guiding principles for decentralized identities. In this and subsequential blogs, we will continue to dive deeper into the technical basics of decentralized identity. Read on for part two of this five-part series on decentralized identity.


Part I:   The Five Guiding Principles

Part II:  The Direct Presentation model <-- You are here

Part III: The Basics of Decentralized Identity

Part IV: Deep Dive: Verifiable Credentials

Part V:  Deep Dive: Anchored Decentralized Identifiers


When we use identity-related credentials in the real world, they often have different properties than digital credentials. There are two separate ceremonies in most cases: issuance and presentation.  If you have spent any time at a department of motor vehicles or a passport office, you’ve seen what an issuance ceremony can be – it is usually an intensive process, but the tradeoff is that once you have a credential like a driver’s license or passport, you can use that credential for multiple purposes, at multiple places, over a long period of time. You, the “holder” of the credential, can choose to present your credential as a (mostly) voluntary exchange, in which the verifier of your credential can grant you access to some kind of resource - for example, they might allow you into a nightclub, or allow you to check out a library book.   


Let’s use a concrete real-world scenario: roadside assistance. Many of us are members of automotive clubs which advertise national and international coverage in the case of vehicle mishaps. After a sign-up song and dance and giving them my annual fee, they issue me a card I stuff into my wallet and forget about. Until one fateful night when my car breaks down in a location I am unfamiliar with. In this case, a miraculous thing happens – I can pull my auto club card from my wallet, and present that card to a garage that has never heard of me before, and a tow truck will arrive to help me. This issue-then-present credentialling model that has long powered the physical world is ready for adoption in the digital world too.





The technical name for the model at work here is called the Direct Presentation model. A credential is issued, and then held for a long period of time with intermittent voluntary presentations to many different verifiers. To put that back into our example, my auto club issues me a card, which I hold in my wallet for years (maybe decades!), and I might choose to show that card to a garage when I need a tow, or possibly to a store to get a discount.


Now let’s switch gears (see what I did there?) to look at the digital world as you use it today. Rather than giving me a card I can store in my wallet, websites (and other services) create a user account. My resource access is tied to this account, and I must prove I own the account by authenticating to the website. After I have authenticated, there is a limited amount of time where the website “knows” who I am and can vouch on my behalf to applications and to other domains, introducing me to resources while sharing data about me. 


This process of an authoritative Identity Provider who redirects me to resources and introduces me as a valid account within their domain with certain attributes and entitlements is called the Federated Presentation model. Going back to my night on the highway, instead of presenting my road service card to the garage, I’d have to borrow their point of sale (POS) terminal to authenticate to the auto club website, then be redirected to the garage website - with my card information included in the redirect.





Both of these models got me my tow truck. They both have important qualities, and there are a number of use cases where either could do the job. But each has a few use cases where they can really shine. In the case of federated presentation, enterprise scenarios such as single sign-on (SSO) provide a compelling combination of convenience and security. Likewise, the digital version of the direct presentation model has great applications - where users benefit from increased agency in their dealings with businesses, governments, and even each other. We’ll cover the key qualities of the direct presentation model in the rest of this blog, and then in our next blog, we can talk through what high level architectural requirements we foresee. Remember, my car has broken down, I’m in a remote and unfamiliar place, and I need to leverage the roadside assistance that I have purchased in advance to get service from a garage that I have never previously done business with. 


Common qualities of the Direct Presentation model (Real-world and digital)

My choice of when and what gets presented

As I sit in my broken-down car, I have options. I might have roadside assistance coverage from multiple providers. I might even have a coupon for a free tow I picked up from the roadside diner or prefer to use a credit card. If I do, I can debate which offers the best deal, and present what works for me. This sounds like a simple thing, but it is tougher to do in the federated model because I can’t look through my wallet to remember which clubs I’m a member of or what coupons I’ve squirreled away. Instead, the garage would have to try to help me remember which auto clubs I might be affiliated with by showing me logos until I see one I recognize.


Everything goes through me

When I interact with the garage, I’m the person presenting my credential and I’m the person getting a receipt back. No real-time interaction is needed with the auto club, which is lucky because it’s the middle of the night. But I am aware of the interactions in real time, and if I want to, I can compare my receipts from all the breakdowns my car has had, see trends in what kinds of transactions I’ve been a part of, and even find places where I’ve been overcharged or where the promises of the transaction haven’t materialized. This is because I was an agent in the direct presentation. In a federated model, the logs of what data was passed about me are likely available but I would have to collect those logs from many different places – if they’re made available to me - to see the full picture.


Present it anywhere

Imagine the case where every garage had to have a separate contract with every regional auto club whose members might want to use their services. The overhead of such a system would be high. Instead, the garages and regional clubs all agree to abide by a common association’s trust framework that establishes the rules and practices that everyone must follow. In the direct presentation model, standards help establish the rules which allow easy establishment of associations, and there’s a potential for direct presentation to make it easier to set up common trust frameworks. This is what allows me to present my membership card from Alberta on a dark highway in North Dakota – where both I and the driver can be confident in the transaction. If everyone uses a common presentation model, it opens the doors to make it easier for trust frameworks to be formed and governed.


Unique properties of the Digital Direct Presentation model

There are few things that couldn’t work for me as I sit in my broken-down car with a physical auto club card, but that could work if I were using a digital credential.


Selective disclosure

When I hand my auto club card to the tow truck operator on the dark highway, I cannot prevent that person from reading everything printed on that card. If the card were to show my home address, the truck driver would know where I lived. But with a digital credential, I can choose what to release (and what not to) during presentation – in this example, I can simply release the fact that I qualify for a tow, and nothing else.  


My wallet has a brain

Another unique quality of a digital direct presentation is that because software can help, my wallet has a brain and can be a trusted advisor. As I sit in my car, shivering, I might make a bad choice about which garage to call. A digital wallet might cross-reference my choice in garages with the Better Business Bureau and suggest I choose a business with a rating higher than one star, saving me from a bad experience.


But what IS the digital version of Direct Presentation?

There are several important initiatives already underway that qualify as direct presentation – including mobile Driver’s License projects based on the ISO 18013 specification, as well as various ePassport initiatives. Vaccine passports are another case where the direct presentation model is emerging, with initiatives such as VCI and Good Health Pass (GHP) gaining traction.  In the identity world, we at Microsoft see the W3C Verifiable Credentials specification as a Data format with long-term potential to let the industry move towards multi-purpose direct presentation. We hope to see some of the models converge over time as they mature, and we’ll deep dive on each of these options over time.


Federated Presentation and Direct Presentation are complimentary

You might be wondering: do we see the direct presentation model replacing federated models? No. We believe that federated and direct presentation models will co-exist, and that each model lends itself to solving different problems. Federated presentation is a modern workhorse when it comes to use cases like enterprise single sign-on, and there will continue to be many places where involving the user in a presentation ceremony will never make sense. The good news is that we have specifications that can help federated and direct models to co-exist, and we are working in the OpenID Foundation, the Decentralized Identity Foundation, and other standards bodies to find an interoperable balance.


If you want a sneak peek, check out Kristina Yasuda and Torsten Lodderstedt at the recent OAuth Security Workshop, talking about some of their work that leverages the Self-Issued Identity Provider section of the OpenID Connect specification. This work truly bridges the worlds of Direct and Federated Presentation models. 


But wait, what does this have to do with Decentralization?

If you’ve noticed that we’re not talking a lot about decentralized tech here, don’t be shocked. Microsoft sees unique and differentiated value in how decentralized technology can fulfill many of the criteria listed above, and we’re excited to dig deeper into what decentralized technology can deliver in later posts! But our goals center on both human and business outcomes. As such, we can and will use decentralized technology where it’s needed and useful, and we’ll do our best to discuss with the community the trade-offs and advantages in the process. 


What’s next?

Now that we have a foundational understanding of the Direct Presentation model and its place in the digital world, our next installment will discuss how we build a reference architecture that could deliver on our principles using the Direct Presentation model. We’ll start with a high-level architecture and slowly drill into the various parts of that architecture, describing the standards at play and how we can see those standards pushing us closer to the 5 guiding principles. There are quite a lot of standards – we’ve constructed a handy linktree to let you easily index into the various specifications we are participating in and/or implementing.


This is going to be fun!

Version history
Last update:
‎Mar 24 2022 02:22 PM
Updated by: