This past week, we held the 40th Internet Identity Workshop—a milestone event that brought together a global community of builders, dreamers, and implementers focused on the future of digital identity. And what a gathering it was.
If there's any lingering doubt about IIW's reach or relevance, just take a look at the map of attendees. People came from all over the world to shape the conversation on the importance of digital identity in the modern age.
As expected, the United States made up the bulk of attendees, with 223 participants from across 20+ states, but what stood out this time was the breadth of international participation:
🇺🇦 Ukraine, 🇹🇠Thailand, 🇹🇼 Taiwan, 🇨🇠Switzerland, 🇸🇪 Sweden, 🇪🇸 Spain, 🇿🇦 South Africa, 🇵🇹 Portugal, 🇳🇿 New Zealand, 🇳🇱 Netherlands, 🇮🇪 Ireland, 🇫🇷 France, 🇪🇬 Egypt, 🇨🇱 Chile, 🇦🇷 Argentina: 1 each
That's 27 countries represented—more than we've ever had before. We still need more participation from Africa. We have a scholarship program if that would help you come!
California: The Identity Capital (Again)
Of course, California led the way in states with a whopping 117 attendees, and cities like San Francisco (24), San Jose (19), Oakland, and Mountain View formed a familiar cluster of identity wonks. Other strong showings came from Washington (18 attendees), Utah (12), and the tech corridors of Massachusetts and New York.
One surprise highlight? Seocho-gu, South Korea, which sent 10 participants—a remarkable show of commitment from a single district in Seoul. We're seeing more and more investment from Asia in building open, interoperable identity layers, and it's a welcome sign.
What We Talked About
While I'll save the detailed session notes for the Book of Proceedings (still to come), a few themes emerged repeatedly:
Agent-based architecture is gaining traction, and the discussions around personal digital agents (and their governance) were some of the most animated of the week.
Interoperability wasn't just a buzzword—there were concrete efforts to align schemas, protocols, and credential formats across communities.
Authenticity and trust were explored beyond technology—touching on human governance, decentralized reputation, and context-aware interactions.
And yes, AI made its appearance—both as a tool for agent enhancement and a source of identity risk.
It's worth noting that the sessions weren't just technical deep dives. Some of the most impactful conversations happened in hallway chats, whiteboard scribbles, and shared coffee lines.
IIW Still Feels Like a Meetup (and That's a Good Thing)
Despite this being the 40th edition, IIW retains its uniquely informal, self-organized flavor. There's no main stage, no keynotes, and no vendors hawking wares. Just a grid of ideas and a crowd of people who care enough to show up, share, and build.
That's what makes IIW magical.
To everyone who attended—whether from Sunnyvale or São Paulo, Tokyo or Toronto—thank you for being part of this milestone. Let's keep making identity better.
Permit.io just published the results of a survey they conducted with over 200 developers on access control. There's lots of good data there, but one thing that struck me is that over 50% of developers said that they've never used any of the popular policy languages. I was wondering why that could be and came up with a few reasons why policy languages often feel foreign and frustrating:
It's Not Code as You Know It—Policy languages like Cedar or Rego are declarative. You're not writing a script to execute; you're defining rules that the engine interprets. That's a big mental shift if you're used to imperative programming.
Jargon Overload—Terms like "principal," "resource," and "condition" may make sense to security architects but leave developers guessing. Without real-world examples, they feel like word salad.
You Can't Just Run It—Want to know if your policy works? You might have to build a whole request context and simulate access decisions. That lack of immediate feedback makes learning feel slow and brittle.
Where's My IDE?—Most policy tools lack the rich developer environments we expect from modern programming — no autocomplete, minimal syntax checks, and few ways to step through logic.
Complexity Scales Fast—It's easy to write "Alice can read financial documents." But throw in multi-tenancy, delegated authority, and time-based rules, and suddenly your policy reads like a legal contract.
The Stakes Are High—Unlike a misaligned UI, broken policies result in security breaches or outages. That makes experimentation feel risky instead of fun.
These are real challenges, but many can be overcome with better tooling. Policy languages simplify app logic and make access control more reliable and maintainable—especially when treated like regular code with testing and version control. I'm betting that their benefits will help developers overcome their lack of familiarity with the programming style and come to rely on them more and more.
I've spent the better part of the week thinking about the idea of first-person identity and verifiable relationship credentials after Drummond Reed spoke about them on Monday at VRM day. I decided to write about it to force myself to understand it better.
One of the hard parts of first-person identity is knowing who to trust online. This isn't a new problem. Back in the day, people trying to use Pretty Good Privacy (PGP) faced the same issue when dealing with public keys. Their solution? Key signing parties.
Never heard of a key signing party? Imagine Alice and Bob are at the O'Reilly Open Source conference in 2007, tucked into a side room labeled "PGP Key Signing Party." About a dozen people mill about, each holding a printed sheet of paper covered in strange-looking hexadecimal strings. Alice approaches Bob, both a little unsure of how to proceed.
"Hi, I'm Alice," she says, holding up her badge and offering her driver's license. Bob does the same. They each squint at the other's ID, then down at the printouts, comparing fingerprints. Neither really knows what they're supposed to be verifying beyond the digits matching. Satisfied enough, they nod awkwardly and move on.
Later, back at her laptop, Alice uses the terminal to sign Bob's key and upload the signature to a public key server. It's a little thrilling, in a nerdy kind of way—but the truth is, she's not sure if she'll ever need Bob's key again.
This ritual—half security theater, half social ceremony—was the heart of early attempts at decentralized identity verification. It was a noble effort to build trust without relying on central authorities. But as creative and community-driven as key signing parties were, they never really worked at scale.
Let's talk about why—and how decentralized identifiers and verifiable credentials might offer a better path to first-person trust in the digital world.
Why They Didn't Work
After the conference, Alice doesn't think much more about Bob's key. Sure, she signed it and uploaded the signature to a key server, but that was more out of politeness than practical necessity. Weeks later, when she sees Bob's name in her inbox, she vaguely remembers meeting him—but she has no idea whether she should trust the key attached to his email.
Bob, meanwhile, has been trying to get more people to sign his key. He's collected half a dozen signatures, but they're from people he met once, briefly. The "web of trust" he's supposed to be building still feels like a pile of disconnected threads.
This is where things fell apart:
It wasn't user-friendly and was far too manual—Every step was an opportunity for confusion, mistakes, or simply giving up. And once the key was signed, there was no easy way to use that trust meaningfully in everyday communication. Nothing about the process felt intuitive. Fingerprints were long strings of hexadecimal gibberish. The tools were cryptic and unforgiving. Even for technical folks like Alice and Bob, the experience was brittle. For most people, it was impossible.
The web of trust never reached critical mass—The key idea behind the web of trust was that if Alice trusted Bob, and Bob trusted Carol, then Alice might come to trust Carol, too. But that only works if:
A lot of people are participating
They're actively managing their trust relationships
The connections form a dense, navigable graph
Instead, what Alice and Bob ended up with were isolated clusters—tiny pockets of trust with no meaningful way to bridge between them.
No immediate payoff—The effort required didn't translate into practical value. Alice never encrypted an email to Bob. Bob never used his signed key to unlock any kind of access or reputation. Signing a key became a kind of ceremonial gesture—well-meaning, but ultimately inconsequential.
Trust was binary and shallow—In theory, key signing meant "I've verified this person's identity." In practice, it often meant "I met this person at a conference and glanced at their ID." The depth of trust was thin, and the binary nature of key signatures (signed or not) didn't reflect the nuanced reality of human relationships.
The core idea was right: identity verification shouldn't require a central authority. But the implementation relied on people doing too much, too manually, and for too little benefit. The trust infrastructure never got far enough to be usable in real life—and so, even though Alice and Bob meant well, their efforts ended up as little more than cryptographic footnotes.
What Can We Learn from the Experience?
Let's rewind and replay that moment between Alice and Bob—only this time, they're operating in a modern, decentralized identity system. No key servers. No GPG. No fingerprints printed on paper.
At another tech conference, Alice scans a QR code on Bob's badge or uses her device's NFC reader to create a connection with Bob. Her personal agent (not necessarily AI-powered) resolves the self-certifying, autonomic decentralized identifier (DID) that Bob provided, pulling Bob's DID document—not from a central directory, but from a peer-to-peer interaction.
Bob's agent reciprocates, requesting a DID from Alice. This isn't just identity exchange—it's mutual authentication. Each party cryptographically proves control over their identifier. No centralized certificate authority is involved; trust is rooted in the interaction itself, supported by verifiable credentials issued by organizations and communities both recognize.
But here's where it gets really interesting: by exchanging DIDs, Alice and Bob have created an actionable connection. Their exchange creates a secure, private DIDComm messaging channel. This isn't just for encrypted chat—though it could be. It's a foundation for ongoing interaction: credential presentations, access control, consent requests, proofs of presence, or even contract negotiation. The connection is both trusted and usable.
Later, Alice could send Bob a verifiable credential confirming they met. Bob could follow up by sharing a credential that gives Alice access to a community space. Their agents handle the details behind the scenes, using DIDComm protocols to maintain privacy and ensure integrity.
There are a number of important changes in this new model:
Trust is peer-to-peer—No key servers. No middlemen. Just Alice and Bob exchanging self-certifying identifiers directly and building trust based on verifiable claims and mutual context.
Mutual authentication is built-in—Both parties authenticate each other through cryptographic proof of control and credentials. It's not a one-way lookup; it's a handshake.
DIDs enable ongoing, secure interaction—Unlike traditional key signing, which ended after the ceremony, exchanging DIDs gives Alice and Bob a secure channel for ongoing communication. DIDComm messaging transforms identity exchange into a persistent, actionable relationship.
Trust has become usable—What began as an in-person meeting becomes a functional connection: a secure link over which credentials, messages, and permissions can flow. Trust becomes a bridge, not just a checkmark.
There are no key servers, no command line—Everything happens in the background: the agents manage key material, update DIDs, and maintain the messaging link. Alice and Bob stay focused on their goals—not cryptography.
Key signing parties were built on a noble idea: decentralized, user-driven trust. But they stopped at verification. In the world of DIDs, DIDComm, and Verifiable Credentials, trust becomes a living channel, not a static record. Alice and Bob didn't just verify each other. They connected. And that is a huge difference.
Improving the UX of Trust: Verifiable Relationship Credentials
After Alice and Bob exchange DIDs and establish a secure DIDComm channel, they have the foundation of a relationship. But what if they want to do more than just message each other? What if they want to capture, express, and eventually use the fact that they met—on their own terms? That's where the verifiable relationship credential (VRC) comes in.
Let's say Alice decides to issue a VRC to Bob. She does this through her personal agent, which creates a standard verifiable credential with self-asserted attributes describing her side of the relationship. The credential could include:
Her name and other contact information
A claim that Alice met Bob in person at "IIW XL"
An optional role or label she assigns ("professional contact," "trusted peer," "collaborator")
A brief note about context ("Talked about SSI, aligned on agent interoperability")
A timestamp and a validity window, if she wants the credential to expire
Her DID as the issuer and Bob's DID as the subject
Importantly, her identifier within a shared community context (e.g., her IIW working group handle or project-specific DID)
The VRC is signed by Alice as the issuer. Bob can now store that credential in his wallet—not just as a keepsake, but as evidence of his connection to Alice. He can selectively present this credential to others who might trust Alice, using it to bootstrap his reputation or prove participation in a network. Crucially, this credential is voluntary, signed, and contextual. Alice isn't vouching for Bob's entire identity—just the fact that she knows him, in a specific capacity, at a specific time.
Bob, in turn, can issue a VRC to Alice, reflecting his view of the relationship. These credentials don't have to match. They don't have to be symmetrical. But together, they form a mutual web of attestations—a decentralized, trust-enhancing social layer. Over time, as Bob collects similar credentials from others, he builds a mosaic of relationships that's both verifiable and portable. It's like LinkedIn endorsements, but cryptographically signed and under the subject's control—not platform-owned.
This works better than key signing parties for several reasons:
Trust becomes tangible—Instead of an abstract handshake, Alice gives Bob something concrete: a verifiable statement of trust. It's not absolute—it's scoped to their interaction—but it's actionable.
Portable reputation—Bob can present Alice's credential in other contexts where Alice is known or trusted. It's a decentralized version of "you can use my name."
Contextual and subjective—The VRC reflects Alice's view of Bob. It's self-scoped and doesn't pretend to be a universal truth. That makes it both useful and safe—especially when combined with selective disclosure.
Built for agents—Bob's agent can surface VRCs when interacting with third parties: "Alice has attested to this relationship." This creates a fabric of lightweight, useful credentials that can augment decision-making.
The verifiable relationship credential is simple, but it captures something that key signing never could: the social, situational texture of trust. It turns a peer-to-peer interaction into a reusable proof of connection—issued by people, not platforms. For Alice and Bob, it's no longer just "we exchanged keys." It's "we created a relationship—and here's what it meant."
From Relationships to Reputation: Trust as a Graph
Alice and Bob meet at Internet Identity Workshop (IIW)—a place where decentralized identity isn't just theory, it's hallway conversations, whiteboard sessions, and rapid prototyping in the lounge. After exchanging DIDs and establishing a DIDComm channel, they each issued the other a verifiable relationship credential (VRC). Alice's credential says she met Bob at IIW, discussed personal agents and DIDComm, and found him a thoughtful collaborator. Bob issues a similar credential to Alice, reflecting his side of the relationship.
Fast forward a few months: Bob keeps showing up in conversations, contributing to working groups, and collaborating on new specs. Each new interaction leads to more VRCs—credentials from others in the community who are attesting, in their own words and context, to their relationship with him. These VRCs, taken individually, are simple statements of relationship. But collectively, they form a decentralized, living trust graph—a network of attestations that agents can navigate.
Now imagine Carol, another participant in the identity community, is deciding whether to bring Bob into a working group on credential portability. She doesn't know Bob personally, but she sees that he has a VRC from Alice—a name she recognizes and trusts from prior collaboration. Her agent reviews the credential and spots something important: the community identifier in the VRC Bob presents from Alice is the same one that appears in the VRC Carol received directly from Alice months earlier.
That shared identifier becomes a verifiable thread—linking two private relationships into a meaningful chain of trust. Carol's agent now has high confidence that the Alice in Bob's credential is the same Alice who endorsed Carol. Bob doesn't need to present Alice's global identity—just the portion she's chosen to make consistent in this context. Carol's agent reviews Bob's broader trust graph and finds:
Multiple VRCs from known IIW regulars
Overlapping context (working on agents, involved in open standards)
A consistent pattern of positive, scoped endorsements
Crucially, a link back to someone she already knows and trusts, via Alice's community identifier
Carol doesn't have to "trust Bob" in the abstract. She can trust that Bob is part of her extended network, with specific, verifiable relationships that support the decision she needs to make.
This is reputation without centralization:
Peer-to-peer, not platform-owned
Contextual, not generic
Verifiable, but privacy-preserving
There's no algorithm deciding who's "influential." There's no reputation score being gamed. Each relationship credential is a piece of a mosaic, curated and held by the people who made them.
Personal agents that are augmented with AI could traverse these graphs on our behalf, weighting relationships based on factors like recency and frequency of interactions, the trustworthiness of issuers (based on our past experience), and relevance to the current task or decision. The agent doesn't just tally up VRCs—it reasons about them. It can say, "Bob is trusted by people you've worked with, in contexts that matter, and here's what they said." That's real, usable trust—not a badge, but a story.
This system isn't just more private—it's more resilient. There's no single point of failure. No platform to de-platform you. Just people, agents, and credentials, all stitched together into a flexible, interpretable web of trust. It's the old dream of the PGP web of trust—but with context, usability, and actionability baked in. From one simple moment at IIW, Alice and Bob built not just a connection, but a durable credentialed relationship. And from many such connections, a rich, decentralized reputation emerges—one that's earned, not claimed.
Relationships Are the Root of First-Person Identity
When Alice and Bob met at IIW, they didn't rely on a platform to create their connection. They didn't upload keys to a server or wait for some central authority to vouch for them. They exchanged DIDs, authenticated each other directly, and established a secure, private communication channel.
That moment wasn't just a technical handshake—it was a statement of first-person identity. Alice told Bob, "This is who I am, on my terms." Bob responded in kind. And when they each issued a verifiable relationship credential, they gave that relationship form: a mutual, portable, cryptographically signed artifact of trust. This is the essence of first-person identity—not something granted by an institution, but something expressed and constructed in the context of relationships. It's identity as narrative, not authority; as connection, not classification.
And because these credentials are issued peer-to-peer, scoped to real interactions, and managed by personal agents, they resist commodification and exploitation. They are not profile pages or social graphs owned by a company to be monetized. They are artifacts of human connection, held and controlled by the people who made them. In this world, Alice and Bob aren't just users—they're participants. They don't ask permission to establish trust. They build it themselves, one relationship at a time, with tools that respect their agency, privacy, and context.
In the end, relationships are the root of first-person identity, based on the people we meet, the trust we earn, and the stories we're willing to share. If we want identity systems that serve people, not platforms, we should start where trust always begins: with relationships.
I'm sitting in VRM day listening to Drummond Reed talk about his First Person Project. If you know Drummond or me, you know we've been interested in this idea since 2011 when we were both working on something called a personal cloud. I've written about this idea extensively on this blog, arguing that people have no place to stand on the internet and thus our digital relationships are, as a result, anemic.
As I listened to Drummond, I realized that "first person" is a more powerful descriptor that "self-sovereign". First person describes the idea in words that most people understand and doesn't have the baggage of sovereignty. First person is "I," "me," "my," and "mine." First person describes precisely the kind of thinking that will allow people create their own online relationships without an intermediating administrator like a social network. Drummond's vision is, as you'd expect from someone who's been working on this for 15 years or more, much more extensive that a simple change to branding, but still, I think it's powerful.
Like many, I've grown increasingly disinterested in social media over the last year. I still have accounts on X, Substack, Facebook, and others. But I find that there's less and less there that I actually care about. I find myself wading through lots of crap to find the things I want to see. Still, I do like to browse through ideas while waiting in line, at the doctor's office, and so on.
This post from Cory Doctorow entitled You should be using an RSS reader caught my eye a while ago. I used to use an RSS reader all the time. I've tried to get back into it a time or two, but it didn't stick. Inspired by Cory to try one more time, I downloaded the RSS reader he uses (Newsblur) and gave it another shot. This time I coupled it with moving the RSS reader app on my phone to a more prominent position so when I'm looking for something to browse, I see it first.
First I found RSS feeds for some of my friends and publications I like to read. I also discovered that Substack publications have RSS feeds. Many publications don't make finding RSS easy, but it's almost always there. There are a few authors I like on The New Stack and I found that if you enter /rss after the URL for an author or category page, you get RSS for that author or category. For example, here's the RSS page for Jon Udell. Cool.
After adding RSS feeds for things I like (most online publications have one), I started reading things on Newsblur instead of opening up a social media app. Most newsreaders don't have an algorithm. If they do, it is not usually the default setting and can be turned off. If you subscribe to too many feeds, turn it on and let it prioritize your reading. But regardless, you control the experience. Just like you should.
At the end of his post, Cory writes:
Using RSS to follow the stuff that matters to you will have an immediate, profoundly beneficial impact on your own digital life—and it will appreciably, irreversibly nudge the whole internet towards a better state.
Cory's right, using an RSS reader will make your digital life better. I'm wasting less time scrolling past stuff I don't care about and more time reading things I enjoy. That's a win.
Security professionals have long taught that organizations should limit the access individuals have in computer systems to just those privileges necessary to perform their job. This is known as the principle of least privilege. The problem is that knowing this is a best practice and putting it into practice are two different things. Traditionally, organizations have used access control lists (ACLs) and role-based access control (RBAC) based on groups to authorize activities. These methods are static, requiring that lists or groups be updated manually as people move between roles or leave employment. When this is extended to partners, suppliers, and other services, the problem is that much worse. And excess standing privileges are a real security risk.
Standing privileges are characterized by persistent access regardless of whether the person is using the resource or not, predefined scope where role is used to define broad access, and minimal oversight with little monitoring and accountability. Standing privileges increase the attack surface, letting attackers exploit broad permissions without further escalation. In addition, over time people accumulate permissions beyond what they need to perform their current job, a situation known as privilege creep.
In an ideal world, least privilege is like a shrink wrap, constantly adjusting the access perimeter as the needs of the employee change. Sometimes they expand and the shrink wrap expands to seamlessly grant any access to needed perform a job. Sometimes the needs shrink and the access perimeter of the employee contracts as well. By limiting access to just that necessary to perform tasks, least privilege ensures that the attack surface that an attacker can exploit is as small as possible.
Zero Trust
Sometimes it's easy to get least privilege and zero trust confused. Zero trust is an overall security framework that requires continuous trust verification. Zero trust is a strategic, overarching trust model for an entire organization. Least privilege, in contrast, is more tactical, determining who can access what and when they can do it.
To see how least privilege fits into a zero trust strategy, consider a database administrator (DBA). Least privilege might set access controls such that the DBA can manage databases, but cannot view customer data stored within them. If their credentials are compromised, the attacker cannot steal sensitive information because the DBA’s privileges are tightly scoped. Zero trust relies on the DBA's access being valid, but might also check for unusual activity such that if the DBA appears to be accessing the database from a new location or at an unusual time, access is curtailed until the DBA is re-authenticated.
As the example shows, least privilege is an important part of zero trust, but only part. Other tactics that play in a zero trust strategy include device management, multi-factor authentication, and segmenting applications and processes (i.e., microsegmentation) to make fine-grained access control possible. Still, least privilege is a core part of a zero trust strategy. And least privilege depends on eliminating standing privileges.
Eliminating Standing Privileges
Recent developments in dynamic authorization have made it easier than ever to eliminate standing privileges. Standing privileges are the result when automatically updating an employee's access in response to changing circumstances is difficult. Modern policy-based authorization systems like Cedar allow organizations to control access though policies that state who can access what and under what conditions. These policies are managed like code, making them easier to manage. More importantly, they can automatically respond to changing circumstances.
For example, the first of the following two Cedar policies forbids anyone to access any resource that's considered "critical" unless they're on a managed device with an acceptable security posture. The second permits employees in the Finance group to access any finance application. These policies work together, so that if the finance application is also a critical resource, then finance employees would also have to be on a managed device with an acceptable security posture. As employees change roles that group is automatically updated from the HR system, growing or shrinking access as needed.
forbid(
principal,
action,
resource in Category::"CriticalResources"
) unless {
context.device.security.risk == "Secure" &&
context.device.security.assessment.overall >= 80
};
permit(
principal in UserGroup::"Finance"
action,
resource in Category::"FinanceApplications"
);
While policy-based access control (PBAC) can be used to mimic a role-based access control system, proper system segmentation (i.e. being able to identify finance applications) and device management allows finer-grained access control where employee's actions can be restricted to specific systems and only when their using a company-owned device that is properly secured. Access control can be limited to certain times or from specific locations. All of these reduce the surface area of an employee's access perimeter for better security.
Just-in-Time Access Control
We can shrink the access perimeter even further using just-in-time access control. Just-in-time (JIT) access control is a mechanism that grants users, applications, or processes access to resources only for a limited time and only when it is explicitly needed. This minimizes the risks associated with long-term or persistent access privileges. While the principle of least privilege focuses on ensuring users or systems have the minimum permissions required to perform their roles or tasks, JIT access control refines this further with several other important features:
Time-Bound Privileges:—JIT ensures permissions are time-limited, reducing the window of opportunity attackers have to exploit rarely-used accounts. For example, a developer needing access to a production server might receive elevated privileges only for a specific task and only for a set duration.
Dynamic Privilege Assignment:—Even when policies are evaluated for each access, the permissions they allow are available indefinitely. JIT adds another dimension to the dynamic nature of PBAC where privileges are granted on demand and revoked automatically when no longer needed.
Granular Control:—Dynamic privilege assignment complements PBAC by making access more granular—not just who can access what, but also when and for how long.
JIT access control might, for example, be used to limit access to payroll functions except during the window when payroll is being processed. Another example is in so-called "break-glass" situations where access is granted to production resources in an emergency or in the case of unexpected failure. Other examples use dynamic roles (e.g., on call) to grant access or require a third party (like a manager) to approve access.
These scenarios can fit within a policy-based authorization architecture using mechanisms such as dynamically altering roles or adding information to the authorization request context based on querying other systems or utilizing permission tokens that carry time-based permissions with them. For example, the following policy makes use of an assignment to process payroll in the oncall tracking system to ensure only people with an oncall assignment of "payroll" can process the payroll.
For this to work, the authorization agent that creates the request for the policy authorizer has to ensure that the context for the request includes the correct oncall assignment and oncall assignments need to be automated.
Putting it All Together
Zero trust, the principle of least privilege, and just-in-time access work together to create a comprehensive security framework.
Zero trust enables an overarching strategy that mandates systems, resources, and actions be designed such that it is possible to continuously verify every action.
Principle of Least Privilege forms the heart of the zero trust strategy, mandating authentication and authorization systems that can dynamically grant fine-grained access through policy.
Just-in-time authorization augments the authorization system so that permissions can be granted not just based on who and where, but also only when they are needed to perform critical actions.
The well known adage that you can't buy security, applies to zero trust and JIT. There are products and technologies that make just-in-time, dynamic fine-grained access control possible, but besides putting them in place, you must also integrate them, make any necessary changes to other systems, and implement governance, monitoring, and auditing to ensure they work. These are organizational changes that take time, money, and perseverance. Done right, the payoff is not just a reduced attack surface and better security, but more productive employees as well. This may seem counter-intuitive, but poorly implemented, piecemeal security measures put much of the burden for keeping systems safe on employees who deal with tactics like frequent, yet ineffective password changes or requesting, and then waiting for, permissions to do their job.
When dynamic access control with JIT access is thoughtfully implemented, you shift the burden of security from employees to systems that automate protection, making it proactive and intelligent. Reducing friction so that employees can do their job while also enhancing security requires balance and a holistic approach that aligns technology, process, and culture. This transformation requires real effort but offers substantial rewards: resilient, secure systems; empowered employees; and peace of mind.
Photo Credit: Shrink Wrapped Computers from DALL-E (public domain) Prompt: draw a wide format picture of several colorful, shrink wrapped computers and smartphones.
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.
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.1
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
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.
Phil Windley
// Fri Nov 8 09:23:00 2024 // iiwidentity
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.
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
