The Business Case for Dynamic Authorization

Phil Windley // Tue Feb 25 11:03:00 2025 // authz authorization identity

Access management is seen by many business leaders as primarily a means of protecting and securing computer systems. Important, but of secondary importance to the business. But as computer systems come to intermediate almost every interaction the business has with employees, contractors, partners, and customers, dynamic authorization should be seen as a strategic business enabler. Investing in a robust, flexible, and pervasive authorization infrastructure can drive revenue growth, operational efficiency, regulatory compliance, and competitive differentiation.

Reducing Operational Costs

Manually managing access using rigid, static authorization models like ACLs and groups is labor-intensive and prone to errors. Organizations that rely on static methods often have employees who are dedicated to managing permissions for employees and others. These employees also perform manual audits, track down problems, and manage groups. As the organization grows, these processes become more complex scaling superlinearly due to interactions in the system.

Dynamic authorization automates many of these access control decisions, reducing the need for manual intervention. This has several benefits:

• Lower administrative overhead eliminating the need for manually managing permissions and groups reduces administrative costs.
• Reduced risk of over-permissioning accounts with permissions they no longer need are the source of many costly security breaches.
• Reduced security insurance premiums many organizations buy costly insurance for security breaches and ransomware. Better authorization practices and systems can reduce premiums.
• Fewer support tickets for access problems tickets that require IT to drop what they’re doing to sort out a permissioning problem take these critical employees away from work that advances the organization’s products and services.
• Improved onboarding and offboarding efficiency dynamic authorization can ensure new employees or contractors have all the access they need on day one and lose it as soon as they leave.

Improved operational efficiency gives the organization the freedom to explore and grow instead of constantly battling access management problems.

Enabling Business Agility and Innovation

As more and more business is conducted online, organizations are finding that it’s vital to quickly react to changing business needs. Whether an organization is launching a new product, expanding into new markets, reacting to new regulatory requirements, or enabling new partnerships, being able to flexibly adapt to emerging requirements and support innovation is table stakes for successful organizations.

As we’ve discussed, static authorization methods require manual changes to lists and groups to increase or decrease access to systems. For example, a financial services firm that is employing external auditors for compliance reviews must grant access for the duration of the engagement. A dynamic authorization system makes this as easy as a policy change. Even that might not be required if authorization policies have been written so as to anticipate this kind of need.

New products often require custom code to support authorization requirements for customers and administrators. A workforce management service provider launching a new employee onboarding product must ensure that customers can properly authorize varying access levels for their employees to administer and manage the service securely. A dynamic authorization system can be integrated with the new product, allowing developers to build in the right authorization controls without writing custom authorization code.

Improving Customer Experience

The compelling features of modern SaaS applications, marketplaces, and collaborative services depend on carefully controlling access. In these platforms, dynamic authorization isn’t just for security; it also enhances the user experience and provides enhanced revenue opportunities.

For example, platforms like Google Docs, Dropbox, and SmugMug all allow their customers to share content with specific people or groups. Dynamic authorization makes this functionality possible.

Or consider multi-tenant SaaS companies like Workday or Salesforce. Fine-grained authorization allows these companies to isolate customer data while simultaneously allowing granular access within each tenant that follows complex rules. These companies can’t build a single access management system because each tenant requires different access controls depending on their organization, regulatory environment, and internal access policies. Dynamic authorization lets them more easily meet customer needs.

Finally, many online businesses offer different features to different users depending on subscription levels. Dynamic authorization policies allow this to be done without custom code and give the business flexibility to add or modify subscription levels and features without changing the underlying code.

Strengthening Security and Compliance

Using dynamic authorization for improved security and regulatory compliance provides several business advantages. Industries like finance, healthcare, and government are heavily regulated. The regulations require organizations to enforce least privilege access, ensure auditability, and dynamically adjust access based on employee roles and changing risk conditions. Organizational benefits from using dynamic authorization include decreased compliance risk, better employee experience, fewer workarounds that introduce security problems, and reduced overall cost.

Competitive Differentiation

Using dynamic authorization inside products gives organizations a competitive edge by offering a more secure, flexible, and user-friendly product.

For example, a B2B SaaS company with a product built with fine-grained access control can better attract large enterprise customers who demand flexible, yet secure features. A financial services company that lets customers dynamically set transaction limits based on varying risk signals allows them to reduce fraud while maintaining a rich user experience. A collaboration tool that offers flexible, secure content sharing beats out competitors who use more rigid, static sharing models.

Organizations can more easily respond to competitor product changes when access management is as simple as a policy change. And dynamic authorization provides these benefits without developers having to write custom code.

A Business Necessity

The preceding sections offer multiple examples of how dynamic authorization goes well beyond enhanced IT security. Organizations that embrace dynamic authorization gain enhanced operational efficiency through automation, increased business agility to more easily pursue new opportunities, stronger security and compliance with less overhead, and better customer experiences that drive customer engagement and revenue.

In the era of multi-tenant, AI-enhanced, SaaS applications, dynamic authorization is essential for organizations to securely scale and effectively compete. Failing to adopt better access management technologies and mechanisms puts organizations at risk of losing their competitive advantage.

Photo Credit: Octopus busy approving things from DALL-E (public domain) Prompt: Draw a picture of an octopus wearing an officials hat with each arm holding stamps that say either "allow" or "deny". The octopus is stamping multiple sheets of paper on a desk.

Authorization Matters

Phil Windley // Thu Jan 16 08:53:00 2025 // authz authorization identity

In 2013, poor authorization practices led to one of the largest data breaches in history. Over a three-week period, hackers stole 40 million credit and debit card accounts from retail giant Target by exploiting the account of an HVAC contractor. The attack began with an email-based phishing scam that tricked an employee at the HVAC company into revealing their credentials. As a vendor to Target, the HVAC company had legitimate access to Target’s systems. Using the stolen credentials, the hackers infiltrated Target’s network and installed malware on the retailer’s point-of-sale systems, enabling them to collect customer data. The breach resulted in direct costs to Target of nearly $300 million, along with reputational damage that is difficult to quantify.¹

The Target breach underscores the critical importance of not only knowing who is accessing your systems (authentication) but also controlling what they can access (authorization). The HVAC vendor had access to Target’s systems for electronic billing, contract submission, and project management. However, the hackers were able to extend this access beyond those legitimate uses to reach systems used to update point-of-sale devices. Target’s failure to properly restrict access to critical systems created a significant vulnerability that the hackers exploited.

But I don’t want you to get the idea that authorization is just about securing IT systemsâ€"it’s also fundamental to how modern cloud applications function, enabling features that wouldn’t be possible otherwise. For example, services like Google Docs and Dropbox rely on authorization to allow users to share documents with specific people while restricting access to others. Without this capability, these applications would not be possible.

Another example is Amazon Web Services (AWS), where authorization enables Amazon to securely provide hundreds of cloud services to millions of customers at scale in a cost-effective manner. As a global distributed system taking advantage of multi tenancy to service millions of customers, AWS uses a sophisticated policy-based authorization system to help customers control access to the services running inside their accounts.

Several trends make authorization a more important topic that it has been:

• More and more software is being delivered as a service (so called Software as a Service, or SaaS). As we’ve discussed cloud-based services can’t provide the needed levels of functionality and security without strong authorization systems.
• Perimeter-based security architectures like firewalls are giving way to zero-trust architectures. Rather than assuming everyone inside the perimeter is trusted, zero-trust systems assume breach and authorize every access. This isn’t possible without flexible authorization systems that can determine whether to grant access based on the context of the request.
• Internet of Things (IoT) and interconnected devices mean that more and more computer systems are talking to each other on their owner’s behalf. Restricting their access to the role they play protects them and prevents them from becoming a vector that hackers can exploit to break into other sensitive systems.
• Regulatory compliance is yet another reason why authorization is increasingly important. Laws like the Health Insurance Portability and Accountability Act (HIPAA) and General Data Protection Regulation (GDPR) require that access to personal information be carefully controlled so that only the right people and systems can use it. Beyond controlling access, these laws also require that you be able to audit access to show compliance.

In addition to these, the rise of GenAI and particularly AI agents that can act on your behalf pour gasoline on the smoldering identity industry interest in authorization. Am I talking to a human? Does this agent have authority to make a doctor's appointment on the patient's behalf? These and other questions mean that making good authorization decisions, knowing what decisions were made, and easily incorporating authorization infrastructure into your apps and infrastructure is vital.

Notes

1. The story is interesting beyond the fact that it highlights the need to properly manage access. Target’s response, or rather lack of one, provides several important security lessons. Cyber Case Study: Target Data Breach provides more details.

Photo Credit: Hacker Stealing Credit Cards from DALL-E (public domain). Prompt: Draw a wide picture of a hacker stealing credit cards from an online store.

Internet Identity Workshop XXXIX Report

Phil Windley // Fri Nov 8 09:23:00 2024 // iiw identity

The 39th edition of the Internet Identity Workshop wrapped up last week. We have 364 attendees from around the world who called 178 sessions. I can't begin to describe the energy of the identity community when they all get together to discuss their favorite topics. If you like identity, or simply want to be part of an enthusiastic technical community, you should come to IIW.

As you can see by the pins in the map at the top of this post, there were attendees from all over the world. Not surprisingly, most of the attendees were from the US (251), followed by Canada (18) and France (14). Germany, Japan, and Australia rounded out the top six with 12, 9, and 7 attendees respectively. Attendees from India (5), Columbia (3), and Chile (2) show IIW's geographic diversity. Sadly, there were no attendees from Africa again. Please remember we offer scholarships for people from underrepresented areas, so if you'd like to come to IIW40, please let us know. If you're working on identity, we want you there.

For states and provinces, California was first with 131 attendees. Washington (19), Utah (14), New York (9), and Massachusetts (9) made up the rest of the top 5. San Jose (20), San Francisco (16), Paris (12), Oakland (11), and Seattle (9) were the top five cities.

We'll have the book of proceedings out in a month or so with notes from the different sessions and descriptions of the 20 demos given during demo hour. Past proceedings are available here.

The next IIW takes place April 8-10, 2025 at the Computer History Museum. This will be IIW XL, number 40! We'll have registration open the first part of December. If you're interested in sponsoring, send me a note.

Resources

• Book of Proceedings (PDF)
• Doc Searls's picture album from IIW 39

Is Voting Secure?

Phil Windley // Mon Oct 28 09:42:00 2024 // voting identity security government

There's a lot of fear mongering about the security of elections. I've wanted to discuss this for a while. I have several things in my background that have given me insight into how elections work. I was the CIO for the State of Utah. I was a member of the Lt Governor of Utah's voting equipment selection committee. And I've been involved in identity and security for several decades.

Let me give you the headline up front: committing election fraud in a way that changes the result is difficult, nearly impossible. Let's examine how elections are run and how fraud could happen to see why.

First a caveat: there is no single way that US elections are run. Elections in the US are quite decentralized. Each state has different election laws and in most cases the mechanics of running an election are given over to county clerks who must follow state law, but also have freedom to create their own workflows and processes within that law. There are 3244 counties in the US. The analysis that follows is generalized and likely more true of Utah, which I'm very familiar with, than other places. Still, I think the big ideas are largely the same everywhere.

The process of voting is divided into two parts: (1) voter registration and (2) voting. This is important because most people who make up scenarios to convince you that voting is insecure usually ignore voter registration. Registration requires that you provide an address. This is an important piece of information because if you're voting by mail, it's where the ballot will be mailed. If you're voting in person, you need to vote at a specific polling place depending on your address.

When you vote, you either mail back the ballot that was mailed to you at the address you provided or you go to your assigned polling place and fill out a ballot (usually via a voting machine). In either case, the ballot presented to you depends on your address since the candidates listed on your ballot depend on your voting precinct. Also, as of 2024, 35 states require voters to present identification at the polling place in order to vote. Of those that don't, many require it for voters who are voting for the first time after their registration.

Now, let's examine voting fraud and how it might work. One important factor is scale. You need to commit fraud at a scale necessary to impact the outcome. For small elections (say a single state legislative race or a small school board election) you don't need to change a lot of votes to change the outcome in a tight race—hundreds of votes might do it. For larger elections, like the presidential election, scale is a significant issue. I'm going to focus on presidential elections since they are the most consequential. Less consequential elections are not likely to attract the kind of money and talent necessary to commit election fraud.

A second factor is stealth. You have to keep the fraud from being discovered so that it's not reversed. Proving consequential fraud would likely result in the election being challenged and rerun. You don't have to identify who did it, just prove that it was done. So election fraud is much more dependent on not being discovered than commercial transaction fraud where the loss is likely to only be recoverable if the identity of the perpetrator is known.

The nature of presidential elections is greatly influenced by the electoral college system. You need to influence the votes in enough states to swing that state's electoral votes to the candidate you favor. You don't want to commit fraud where it's not needed because you'll waste money while increasing your chances of discovery. So, selecting the states where you want to commit fraud is critical. Each of those states will have different requirements, so you'll have to tailor your attack to each of them. Furthermore, you'll have to tailor your attack to each voting precinct within the counties you determine are the most likely to impact the election.

There are a few ways to attack an election:

• Sending your people to vote—for this to work, your fake voters have to have been registered and, in most cases, provide some form of ID. To register, they need a plausible address. The election office might not notice if one or two extra people with different last names are registered at a specific address, but they might if this is systematic or if an unreasonable number of people register at the same address. Remember that elections are run at the county level, so you have to assume that the election workers have a good understanding of the local environment. These fake voters now have to go to many different polling locations and cast a vote. They can't easily cast multiple ballots at the same polling location since the poll workers might remember them. So, you need lots of people going to lots of different polling locations.
• Intercepting mail-in ballots—for this to work, you have to register at someone else's home address and then get to the mail before they do or steal their ballots after they've filled them in and change the vote. This requires lots of people. You can't do this remotely. It requires "boots on the ground" as the saying goes. Furthermore, those people are exposed since they're looking in mailboxes in neighborhoods where they don't live. Doable, but not very stealthy.
• Paying people to vote—for this to work, you have to contact a lot of people, convince them to commit fraud, and then be satisfied with the fact that you'll never know if they voted for your candidate or not because ballots are secret. They could take your money and vote for whoever they want. Or just not vote at all unless you're supervising them, an activity that will call attention to you and your agents.
• Replacing real ballots with fake ones—for this to work, you have to create realistic facimiles of real ballots for many different polling places (remember they're different because of overlapping jurisdictions), intercept the ballots somewhere in transit or on delivery, and replace the real ballots with ones that you've filled out for your candidate. This likely involves subverting county election workers. Not just one, but many. Again, the risk of discovery goes up with each contact.
• Destroying ballots—for this to work, you need to destroy ballots that are for the candidate you don't want to win. You could simple destroy ballots without regard to how they're filled, but this won't assure you'll meet your goal. To be effective, you have to just destroy the ones for the other candidate and leave the ones for your candidate. Again, you will have to subvert election workers to get your hands on the ballots and determine who the ballot is for.
• Changing the results after the ballots are counted—for this to work, you have to either hack the machines that record the vote or hack the machines that are tabulating the vote. Hacking the machines won't work if the machines keep a paper audit trail and it's used to audit results. Hacking the tabulators means getting access to those machines. Recall those are kept at the county level, so you have to hack many in different locations unless a single county can swing the election your way.

I hope all of this has at least given you a feel for the scale and scope of the problem. Pulling it off successfully without anyone knowing it happened is a difficult problem. Each method involves many people being let in on the secret—in some cases a lot of people. This isn't an operation that a small group of hackers can reliably pull off. Having lots of people involved increases the chances that you'll be discovered. The decentralized and distributed nature of how elections are run is a feature and makes elections more secure and trustworthy.

On top of all this, election officials aren't stupid, lazy, or inept. Sure, you're going to find a few who are. But as a rule the elections officials I've interacted with at the state and county level are professionals who are attuned to these dangers and take active steps to protect against them. They are usually happy to talk about how they operate and will respond to polite requests for information about how they audit systems and the processes they have in place to protect the vote.

As an aside, do you know what's easier than committing election fraud? Using social media to convince people that election fraud is happening to reduce confidence in the election and sow discontent. Then you can use that discontent to challenge a legitimate election and maybe change the outcome. Ask yourself which is more likely.

Successfully changing the results of a presidential election isn't impossible. But the odds of doing so and not leaving any evidence—the perfect crime—are vanishingly small. I have confidence in the security of the US election system.

Photo Credit: Voting from DALL-E (public domain) Prompt: Draw a horizontal picture of a woman casting a ballot with a ballot box

Digital Identity and Access Control

Phil Windley // Tue Sep 10 07:29:00 2024 // identity access+control ssi

In response to a post on X about China's social credit system, Paul Conlon said:

Digital ID is ultimately about access control where those who impose the system are the ones determining what you are required to be and do.

Provision of resources and liberties become conditional upon the whims of the affluent. Doesn't sound safe or convenient to me.

From X
Referenced 2024-08-28T08:10:31-0400

How Paul said this struck me because I've been thinking a lot about access control lately. I believe that we build identity systems to manage relationships, but, as Paul points out, in many cases the ultimately utility of identity systems is access control.

This isn't, by itself, a bad thing. I'm glad that Google controls access to my GMail account so that only I can use it. But it doesn't stop there. If I use my Google account to log into other things, then Google ultimately controls my access to everything I've used it for. This is federation's original sin¹.

Paul's comment points out the primary problem with how we build identity systems today: when access control is centralized, it inherently shifts power towards those who manage the system. This dynamic can lead to a situation where individuals must conform to the expectations or demands of those in control, just to maintain their access to essential services or resources. While we often accept this trade-off for convenience—like using Google to manage multiple logins—the broader implications are troubling.

The more we rely on federated identity systems, with their tendency to centralization, the more we risk ceding control over our digital lives, reducing our autonomy, and increasing our dependence on entities whose goals may not align with our own. This is why the principles of self-sovereign identity (SSI) are so compelling. SSI proposes a model where individuals maintain control over their own identity, reducing the risks associated with centralized access control and enhancing personal freedom in the digital realm.

Critics of SSI will claim that giving people control over their identity means we have to accept their self assertions. Nothing could be further from the truth. When someone wants me to prove I'm over 18, I use a driver's license. The state is asserting my age, not me. But I'm in control of who I show that to and where. Sovereignty is about borders and imposes a system of relationships.

Now, China could use decentralized identity technology to build their social credit system. One credential, controlled by the state, that is used to access everything. Technology alone can't solve this problem. As a society, we have to want a digital world, modeled on the physical one, where individuals are the locus of control and use information and assertions from a variety of credentials to build and interact in authentic peer-to-peer relationships. Until we value freedom and independence in the digital world, we will yield up control of our digital lives to others who will act in their own interests, not ours.

Notes

1. For similar reasons, I think federated social media systems are a bad idea too, but that's another blog post.

Photo Credit: Papers Please from DALL-E (public domain). Prompt: Draw a rectangular picture of police checking identity papers of people on the street

What Is Decentralized Identity?

Phil Windley // Mon Jun 17 07:42:00 2024 // identity ssi decentralized+identity verifiable+credentials

In Yeah, yeah, yeah, yeah, yeah, nah, Alan Mayo references my recent blog post, Decentralized Identity Comes of Age, and says:

My challenge to the decentralization community is for them (someone) to explain how it works in relatively simple and reasonable terms. I say relative because identity is not simple, so we should not expect simple solutions.

This post is my attempt to do that for Alan and others.

Identity is how we recognize, remember, react to, and interact with other people, organizations, and services. Put another way, identity is about relationships. Online we suffer from a proximity problem. Since we're not near the parties we want to have relationships with, our natural means of recognizing, remembering, and interacting with others can't be used. Digital identity systems are meant to provide us with the means of creating online relationships.

Traditional identity systems have not served us well because they are owned and controlled by companies who build them for their own purposes. The relationships they support are anemic and transactional. We can't use them for any purpose except what their owner's allow.

Decentralized identity systems¹ on the other hand allow you to create online relationships with any person, organization, or service you choose and give you the tools to manage and use those relationships. They help you recognize, remember, react to, and interact with them. The most important tool is a decentralized identity wallet. The world of decentralized identity wallets is still young, but organizations like the Linux Foundation's Open Wallet Foundation give me hope that useful, interoperable wallets are a tool we'll all be able to use soon. They are as foundational to decentralized identity as a browser is to the web.

Besides helping you manage peer-to-peer relationships with others online, wallets hold verifiable credentials, the digital analog to the credentials and cards you carry in a physical wallet. One of the most important aspects of digital relationships is providing information about yourself to those you interact with. Sometimes that information can come from you—it's self-asserted—but many times the other party wants to reliably know what others say about you. For example, if you establish a banking relationship, the bank is legally obligated to verify things like your name and address independent of what you say. Decentralized identity wallets allow you to prove things about yourself using credentials others provide to you. At the same time, they protect your privacy by limiting the information disclosed and forgoing the need for the party you're interacting with to directly contact others to verify the information you provide.

In summary, decentralized identity systems allow you to create digital relationships with other parties independently, without relying on any other organization or service. These relationships are direct, private, and secure. They also provide the means for you to prove things about yourself inside these relationships so that even though you're operating at a distance, you and the other party can have confidence in the relationship's authenticity.

How Does It Work

The preceding paragraphs say what decentralized identity is, and provide its benefits, but don't say how it works. Alan and others will likely want a few more details. Everything I describe below is handled by the wallet. The person using the wallet doesn't need to have any more knowledge of how they work than the operator of a browser needs to understand HTTP and HTML.

The foundation of a peer-to-peer, decentralized online relationship is an autonomic identifier like a peer DID. Identifiers are handles that someone else can use to identify someone or something else online. Peer DIDs can be created by a wallet at will, they're free, and they're self-certifying (i.e., there's no need for a third party). A relationship is created when two identity wallets create and exchange peer DIDs with each other on behalf of their owners. Peer DIDs allow the parties to the relationship to exchange private, secure messages.

There are four primary interaction patterns that wallets undertake when exchanging messages:

1. DID Authentication which uses the DIDs to allow each party to authenticate the other
2. Single-Party Credential Authorization where the same party issues and verifies the credential.
3. Multi-Party Authorization where the credential issuer and verifier are different parties.
4. Generalized Trustworthy Data Transfer which uses a collection of credentials to aid the wallet owner in completing online workflows.

Verifiable credentials make heavy use of cryptography to provide not only security and privacy, but also confidence that the credential data is authentic. This confidence is based on four properties a properly designed credential presentation protocol provides:

1. The identifier of the credential issuer
2. Proof that the credential is being presented by the party is was issued to
3. Proof that the credential has not been tampered with
4. The revocation status of the credential

The credential presentation can do all this while only disclosing the information needed for the interaction and without the verifier having to contact the credential issuer. Not having to contact the issuer ensures the credential can be used in situations with poor connectivity, that the issuer needn't be online, and preserves the credential subject's privacy about where the credential is being used.

A properly designed credential exchange protocol has four important properties:

1. The system is decentralized and contextual. There is no central authority for all credentials. Every party can be an issuer, an owner, and a verifier. The system can be adapted to any country, any industry, any community, any set of credentials, any set of trust relationships.
2. Issuers are free to determine what credentials to issue and whether or not to revoke them.
3. Wallet owners are free to choose which credentials to carry and where and when they get shared. While some verifiers require a specific credential—such as a customs agent requiring a passport—others will accept a range of credentials. Therefore owners can decide which credentials to carry in their wallet based on the verifiers with whom they interact.
4. Verifiers make their own decisions about which credentials to accept. For example, a bar you are trying to enter may accept any credential you have about your date of birth. This means some credentials (e.g., passports, driving licenses, birth certificates) may be much more useful than just for the original purpose for which they were issued.

These properties make a decentralized identity system self sovereign.

Why is Decentralized Identity Important?

Decentralized identity systems are designed to provide people with control, security, and privacy while enhancing the confidence we have in our online relationships. Some time ago, I wrote the following. I think it's an apt way to close any discussion of decentralized identity because unless we keep our eyes on the goal, we'll likely take shortcuts in implementation that fail to live up to their promise.

Presently, people don't have operational relationships anywhere online.² We have plenty of online relationships, but they are not operational because we are prevented from acting by their anemic natures. Our helplessness is the result of the power imbalance that is inherent in bureaucratic relationships. The solution to the anemic relationships created by administrative identity systems is to provide people with the tools they need to operationalize their self-sovereign authority and act as peers with others online. Peer-to-peer relationships are the norm in the physical world. When we dine at a restaurant or shop at a store in the physical world, we do not do so under the control of some administrative system. Rather, we act as embodied agents and operationalize our relationships, whether they be long-lived or nascent, by acting for ourselves. Any properly designed decentralized identity system must provide people with the tools they need to be "embodied" in the digital world and act autonomously.

Time and again, various people have tried to create decentralized marketplaces or social networks only to fail to gain traction. These systems fail because they are not based on a firm foundation that allows people to act in relationships with sovereign authority in systems mediated through protocol rather than by the whims of companies. We have a fine example of a protocol mediated system in the internet, but we've failed to take up the daunting task of building the same kind of system for identity. Consequently, when we act, we do so without firm footing or sufficient leverage.

Ironically, the internet broke down the walled gardens of CompuServe and Prodigy with a protocol-mediated metasystem, but surveillance capitalism has rebuilt them on the web. No one could live an effective life in an amusement park. Similarly, we cannot function as fully embodied agents in the digital sphere within the administrative systems of surveillance capitalists, despite their attractions. The emergence of self-sovereign identity, agreements on protocols, and the creation of metasystems to operationalize them promises a digital world where decentralized interactions create life-like online experiences. The richer relationships that result from properly designed decentralized identity systems promise an online future that gives people the opportunity to act for themselves as autonomous human beings and supports their dignity so that they can live an effective online life.

Notes

1. I prefer the term self-sovereign to decentralized because it describes the goal rather than the implementation, but I'll stick with decentralized here. All self-sovereign identity systems are decentralized. Not all decentralized identity systems are self-sovereign.
2. The one exception I can think of to this is email. People act through email all the time in ways that aren't intermediated by their email provider. Again, it's a result of the architecture of email, set up over four decades ago and the culture that architecture supports.

Photo Credit: Young Woman Using a Wallet from DALL-E (public domain) Prompt: draw a rectangular picture of a young woman using a wallet.

Decentralized Identity Comes of Age

Phil Windley // Wed Jun 5 09:25:00 2024 // identity ssi decentralized+identity verifiable+credentials

I'm at European Identity Conference (EIC) this week. I haven't been for several years. One thing that has struck me is how much of the conversation is about decentralized identity and verifiable credentials. I can remember when the whole idea of decentralized identity was anathema here. The opening keynote, by Martin Kuppinger is Vision 2030: Rethinking Digital Identity in the Era of AI and Decentralization. And all he's talking about is decentralized identity and how it's at the core of solving long standing identity problems. Another data point: Steve McCown and Kim Hamilton-Duffy ran a session this morning called Decentralized Identity Technical Mastery which was a hands-on workshop. The rather large room was packed—standing room only.

I attended a couple of sessions on decentralized identity where I didn't know the companies, the speakers, or the specific platforms they were using. The space is too big to keep track of anymore. Identity professionals who were ignoring, or talking down, decentralized identity a few years ago are now promoting it.

This truly feels like a tipping point to me. At IIW, it's identity geeks talking with other identity geeks, so it's no surprise to see lots of discussion about new things. EIC is a different kind of conference. There are about 1000 people here I'd guess. Most of them aren't working on new standards or open source projects. Instead they're the folks from companies who come to conferences like EIC to learn how to solve the problems their organization is facing.

In the keynotes and in numerous sessions, the message that they're hearing is "decentralized identity will solve your problems." Martin closed his talk with the proclamation that "decentralized identity is the new paradigm for identity."

Photo Credit: Credential Tipping Point by DALL-E (public domain) Prompt: Draw a rectangular picture that shows a credential at a tipping point. Make the credential look like a lifelike credential, include cartoon picture, and some writing. Use bright friendly colors.

Can LLMs Provide References for Their Work? An Experiment

Phil Windley // Thu May 30 08:52:00 2024 // genai llm chatgpt prompt+engineering

Recently my friend Scott Mace asked this on X in response to a post about the evolution of software and how LLMs will likely follow that same trajectory:

Yes, but how trustworthy will it be? Can I at least see the links it used to create its response?

From X
Referenced 2024-05-21T18:09:06-0400

The short answer is "no", but the real answer is a bit more nuanced because of how LLMs like ChatGPT work. First the short answer: LLMs don't understand what they're saying so they can't reference the material that it used to create a response. They don't work like that. They don't go out, do a bunch of research and then create a response. Instead lots (and I mean LOTS) of material is fed into the program that creates the model, a multi-dimensional matrix of word orders. Then when you ask a question ("give it prompt" in LLM-speak), it processes the question and generates text based on the probabilities of words in its model¹. There's no way it can satisfy Scott directly because the model doesn't—can't, as far as I know—include the references that it used to create the text because it's generating it on the fly from material that has been thoroughly blended together.

But, in fairness, that's not what people do most of the time either. If you asked me over lunch or at the end of a tech presentation to describe zero trust and its pros and cons, I'd start talking. I wouldn't start looking up things on the web and somehow weave them into text complete with references. I'd go look for references if you asked me to back up something I said. So, let's try that with ChatGPT 4o. I gave it the following prompt:

You are a writer for a website focusing on technology. Your specialty is security. Write a 150 word explanation of zero trust with three pros and three cons.

ChaptGPT answered with this text:

Zero Trust is a security model based on the principle of "never trust, always verify." Unlike traditional security models that assume everything inside the network is safe, Zero Trust assumes that threats can exist both inside and outside the network. It requires strict identity verification for every user and device attempting to access resources, regardless of their location.

Pros:

1. Enhanced Security: By continuously verifying users and devices, Zero Trust reduces the risk of breaches and unauthorized access.
2. Minimized Attack Surface: It limits access to only what is necessary, reducing potential entry points for attackers.
3. Improved Compliance: Helps meet regulatory requirements by ensuring strict access controls and logging all access attempts.

Cons:

1. Complex Implementation: Deploying Zero Trust can be complex and time-consuming, requiring a significant overhaul of existing systems and processes.
2. Increased Costs: The initial investment in technology and training can be high.
3. User Experience Impact: Continuous verification can lead to friction and inconvenience for users if not implemented smoothly.

Zero Trust is essential for modern cybersecurity, but it requires careful planning and resources to implement effectively.

That's pretty good. But what if we need some references to other material to back up the pros and cons? I asked ChatGPT to supply them:

Now repeat that task, but this time include references as hyperlinks to back up each pro and con.

ChaptGPT answered with this text:

Zero Trust is a security model based on the principle of "never trust, always verify." Unlike traditional security models that assume everything inside the network is safe, Zero Trust assumes that threats can exist both inside and outside the network. It requires strict identity verification for every user and device attempting to access resources, regardless of their location.

Pros:

1. Enhanced Security: By continuously verifying users and devices, Zero Trust reduces the risk of breaches and unauthorized access (CSO Online).
2. Minimized Attack Surface: It limits access to only what is necessary, reducing potential entry points for attackers (NIST).
3. Improved Compliance: Helps meet regulatory requirements by ensuring strict access controls and logging all access attempts (Gartner).

Cons:

1. Complex Implementation: Deploying Zero Trust can be complex and time-consuming, requiring a significant overhaul of existing systems and processes (Forrester).
2. Increased Costs: The initial investment in technology and training can be high (ZDNet).
3. User Experience Impact: Continuous verification can lead to friction and inconvenience for users if not implemented smoothly (TechRepublic).

Zero Trust is essential for modern cybersecurity, but it requires careful planning and resources to implement effectively.

That looks great! Nice references for each bullet. There's just one problem. All the links, except the NIST reference, are dead. I don't know if they're wrong, made up, or stale. I tried finding content on a few of the sites by searching and came up dry. As I heard Johannes Ernst say once, ChatGPT is a "large language model" not a "large fact model" and this bears that out.

Still, asking for references or evidence for statements is something people are going to want. So, I tried a different tack. This time I asked this:

Why do you say complex implementation is a problem for zero trust? Can you give me a few references on that I can read myself?

ChatGPT responded with this:

Implementing a Zero Trust security model can be challenging for several reasons:

1. Overall Complexity: Zero Trust requires a comprehensive understanding of your network's intricacies, including users, devices, applications, and data. This can involve significant changes to existing infrastructure, which can be disruptive and costly. Organizations need to be prepared for the extensive planning and resources required for successful implementation​ (Help Net Security)​​ (Enterprise Networking Planet​).
2. Legacy Systems: Many organizations have legacy systems that are not designed to operate within a Zero Trust framework. These systems might require different security measures or even complete replacement, adding to the complexity and cost (Help Net Security)​​ (Enterprise Networking Planet​)
3. Cultural Shift: Zero Trust is not just a technological shift but also a cultural one. It requires continuous verification and strict access controls, which can lead to user frustration and resistance if not managed properly. Ensuring user buy-in and minimizing disruption to workflows through training and communication is essential (Deloitte United States)​​ (Guidehouse).
4. Resource Intensive: Implementing and maintaining Zero Trust can put a strain on IT resources due to the need for continuous monitoring and management. The need for advanced security tools and ongoing updates further adds to the resource demands (Help Net Security)​​ (Enterprise Networking Planet​).
5. Stakeholder Alignment: Achieving buy-in from all stakeholders and aligning them with the Zero Trust principles is critical. This requires a coordinated effort to educate stakeholders, prioritize gaps, and ensure consistent understanding and application of Zero Trust principles across the organization (Deloitte United States)​​ (Guidehouse).

These challenges highlight the importance of a phased and well-planned approach to Zero Trust implementation, considering both technological and human factors. For more detailed insights, you can refer to articles from Help Net Security and Guidehouse.

Much better. The links in the bullets all work, but the ones at the end don't. The articles it references aren’t very detailed, so I wouldn’t say they’re stellar references, but at least there’s a pointer to outside material that discusses similar challenges. So, partial success.

I've found that when you're using ChatGPT to do research, treating it like a librarian and asking questions that follow up are the best way to gain confidence that the material is correct and find the supporting material, just as I did above. I'm sure you could wrap additional helper functions around an LLM to make getting references easier. But for now interrogation through chat is the best way to get comfortable with the results.

Notes

1. Yeah, this is really simplified and thus wrong, but it's directionally correct. For a better explanation, see What Is ChatGPT Doing … and Why Does It Work?.

Photo Credit: Older Man Talking to Robot Librarian from DALL-E (public domain) Prompt: draw me a rectangular picture of an older man talking with a robot librarian. Use earth tones.

Internet Identity Workshop XXXVIII Report

Phil Windley // Mon Apr 29 07:47:00 2024 // identity iiw

We recently completed the 38th edition of the Internet Identity Workshop. We had 330 people from around the world who called 169 sessions. As usual there was lots of energy and thousands of side conversations. IIW is a place to get things done and it showed in the energy and the comments people made to me about how much they enjoyed it.

As you can see by the pins in the map at the top of this post, there were attendees from all over the world. Not surprisingly, most of the attendees were from the US (241), followed by Canada (11). Germany, India, and Switzerland rounded out the top five with 9, 8, and 7 attendees respectively. Attendees from India (5), Thailand (3), and Korea (3) showed IIW's diversity with attendees from APAC. And there were 4 attendees from South America this time. Sadly, there were no attendees from Africa again. Please remember we offer scholarships for people from underrepresented areas, so if you'd like to come to IIW39, please let us know. If you're working on identity, we want you there.

For states and provinces, California was first with 122. Washington (16), Utah (10), Texas (10) and New York (10) rounded out the top five. San Francisco (14) Oakland (13), San Jose (12), Seattle (11), and New York (9) were the top cities.

In addition to sessions, we have a demo hour on Wednesday that is a little like speed dating. There were 20 different projects highlighted. There's always more than one session that I want to attend in any given time slot and choosing is hard. That's a common refrain. Luckily we have sessions notes that we publish in a Book of Proceedings.

Here's pictures from all three days courtesy of Doc Searls

You belong at IIW! IIW is where you will meet people to help you solve problems and move your ideas forward. Please come! IIW 39 will be held October 29-31, 2024 at the Computer History Museum. We'll have tickets available soon.

Using X.509 Certs for DID Provenance

Phil Windley // Thu Apr 25 08:31:00 2024 // identity ssi decentralized+identifiers verifiable+credentials x.509

When you used a verifiable credential to prove something about yourself, the verifier can know cryptographically: (1) the identifiers for the issuer, (2) the credential hasn't been tampered with, (3) the credential was issued to you, and (4) the credential hasn't been revoked. These four checks are important because their establish the fidelity of the data being transferred. They don't, however, tell them whether they can trust the issuer. For that, they need to take the issuer's decentralized identifier (DID) that they got from credential presentation and determine who it belongs to.

At the most recent Internet Identity Workshop, Drummond Reed gave a session on how X.509 certificates could help with this. The first step, like always, is to resolve the DID and retrieve the DIDDoc that associates keys and endpoints with the DID. The endpoint can be an HTTP server and, of course, should have an X.509 certificate providing TLS security. That certificate, at the very least, has a a domain name to bind that to the certificate's public key. It can, if you pay for the feature, also include information about the entity that applied for the certificate. The certificate authority proofs that information and is vouching for it when they sign the certificate.

The key to making the X.509 certificate useful for checking the provenance of a DID lies in one key change. X.509 certificates can contain and extended field called a Subject Alternative Name. This following figure shows how it can help.

In this figure:

1. The issuer (Attestor) creates the DID they will use to issue the certificate along with its associated DIDDoc, including an HTTP endpoint for DID verification.
2. Attestor applies for a X.509 certificate for that endpoint, including in the application the DID they created in (1).
3. The certificate authority does it's usual proofing of the application and issues a certificate that includes the DID in the Subject Alternative Name field.
4. The issuer creates a credential definition in the usual way that includes their DID and writes it to whatever Verifiable Data Registry their DID method dictates.
5. Attestor issues a credential to a holder (Alice) using that credential definition.
6. At some later time, Alice presents the credential to the verifier (Certiphi).
7. Certiphi resolves the DID to get the DIDDoc and retrieves the verfication endpoint from the DIDDoc
8. Certiphi retrieves the certificate for that endpoint¹.
9. Certiphi verifies the certificate by checking it's signature and ensures that the DID in the DIDDoc for the credential matches the one in certificate.²

The issuer's DID has now been tied in a verifiable way to whatever information is in the certificate. Provided the certificate includes information about the entity beyond the domain name, the verifier can use that information to determine whether or not the credential is authentic (i.e., issued by who the credential definition purports issued it). That might be all the evidence they need to determine whether to trust the entity. Certificate authorities could also issue verifiable credentials to the customer attesting the same verified claims—after all, it's one more product they can offer.

The benefit of doing issuer validation using X.509 certificates is that there are already many trusted X.509 certificate authorities in business who already do proofing of attributes about businesses. That's a huge chunk of the verifiable data ecosystem that doesn't need to be built because it can be leveraged. To make this work, digital certificate authorities would need to start offering to validate DIDs and include them in a certificate as a Subject Alternative Name. I don't discount that this will take some bureaucratic maneuvering. Certificate authorities will need to see a business opportunity. I'd love to see Digitcert or someone do a pilot on this.

Notes

1. Note that this step might be combined with the previous step if the Verifiable Data Registry is the same server as the endpoint, but that's not necessarily going to be the case for a number of reasons.
2. Note that this does not create a call back wherein Attestor can determine which credential was used, preserving the privacy of the presentation. Attestor does know one of its credentials has been presented to Certiphi. If this information leakage bothers you, then any web-based DID method is potentially a problem.