SSI is the Key to Claiming Ownership in an AI-Enabled World

Phil Windley // Mon Nov 27 20:07:00 2023 // ssi identity verifiable+credentials ai

I've been trying to be intentional about using generative AI for more and more tasks in my life. For example, the image above is generated by DALL-E. I think generative AI is going to upend almost everything we do online, and I'm not alone. One of the places it will have the greatest impact is its use in personal agents, determining whether or not these agents enable people to lead effective online lives.

Jamie Smith recently wrote a great article in Customer Futures about the kind of AI-enabled personal agents we should be building. As Jamie points out: "Digital identity [is how we] prove who we are to others."​ This statement is particularly resonant as we consider not just the role of digital identities in enhancing personal agents, but also their crucial function in asserting ownership of our creations in an AI-dominated landscape.

Personal agents, empowered by AI, will be integral to our digital interactions, managing tasks and providing personalized experiences. As Bill Gates says, AI is about to completely change how you use computers. The key to the effectiveness of these personal agents lies in the robust digital identities they leverage. These identities are not just tools for authentication; they're pivotal in distinguishing our human-generated creations from those produced by AI.

In creative fields, for instance, the ability to prove ownership of one's work becomes increasingly vital as AI-generated content proliferates. A strong digital identity enables creators to unequivocally claim their work, ensuring that the nuances of human creativity are not lost in the tide of AI efficiency. Moreover, in sectors like healthcare and finance, where personal agents are entrusted with sensitive tasks, a trustworthy, robust, self-sovereign identity ensures that these agents act in harmony with our real-world selves, maintaining the integrity and privacy of our personal data.

In this AI-centric era, proving authorship through digital identity becomes not just a matter of pride but a shield against the rising tide of AI-generated fakes. As artificial intelligence becomes more adept at creating content—from written articles to artwork—the line between human-generated and AI-generated creations blurs. A robust, owner-controlled digital identity acts as a bastion, enabling creators to assert their authorship and differentiate their genuine work from AI-generated counterparts. This is crucial in combating the proliferation of deepfakes and other AI-generated misinformation, ensuring the authenticity of content and safeguarding the integrity of our digital interactions. In essence, our digital identity becomes a critical tool in maintaining the authenticity and trustworthiness of the digital ecosystem, protecting not just our intellectual property but the very fabric of truth in our digital world.

A good place to start is with our "humanness." On an earlier version of this post, Timo Hotti commented that the most important use of verifiable credentials might be to prove that you're human. There are a number of ways to do this. Proof that I have a driver's license, at least for now, proves that I'm human. Bank credentials could also be used to prove humanness because of know-your-customer (KYC) regulations. I suggested something like this a year or so ago as a way of cutting down on bots on Twitter.

As we embrace this new digital frontier, the focus must not only be on the convenience and capabilities of AI-driven agents but also on fortifying our digital identities so that your personal agent is controlled by you. Jamie ends his post with five key questions that we shouldn't lose sight of:

1. Who does the digital assistant belong to?
2. How will our personal agents be funded?
3. What will personal agents do tomorrow that we can’t already do today?
4. Will my personal agent do things WITH me and FOR me, or TO me?
5. Which brands will be trusted to offer personal agents?

Your digital identity is your anchor in the digital realm, asserting our ownership, preserving our uniqueness, and fostering trust in an increasingly automated world, helping you operationalize your digital relationships. The future beckons with the promise of AI, but it's our digital identity that will define our place in it.

dApps Are About Control, Not Blockchains

Phil Windley // Tue Nov 21 06:35:00 2023 // dapps picos blockchain pcaa

I recently read Igor Shadurin's article Dive Into dApps. In it, he defines a dApp (or decentralized application):

The commonly accepted definition of a dApp is, in short, an application that can operate autonomously using a distributed ledger system.

From Dive Into dApps
Referenced 2023-11-12T15:39:42-0500

I think that definition is too specific to blockchains. Blockchains are an implementation choice and there are other ways to solve the problem. That said, if you're looking to create a dApp with a smart contract, then Igor's article is a nice place to start.

Let's start with the goal and work backwards from there. The goal of a dApp is to give people control over their apps and the data in them. This is not how the internet works today. As I wrote in The CompuServe of Things, the web and mobile apps are almost exclusively built on a model of intervening administrative authorities. As the operators of hosted apps and controllers of the identity systems upon which they're founded, the administrators can, for any reason whatsoever, revoke your rights to the application and any data it contains. Worse, most use your data for their own purposes, often in ways that are not in your best interest.

dApps, in contrast, give you control of the data and merely operate against it. Since they don't host the data, they can run locally, at the edge. Using smart contracts on a blockchain is one way to do this, but there are others, including peer-to-peer networks and InterPlanetary File System (IPFS). The point is, to achieve their goal, dApps need a way to store data that the application can reliably and securely reference, but that a person, rather than the app provider, controls. The core requirement for achieving control is that the data service be run by a provider who is not an intermediary and that the data model be substitutable. Control requires meaningful choice among a group of interoperable providers who are substitutable and compete for the trust of their customers.

I started writing about this idea back in 2012 and called it the Personal Cloud Application Architecture. At the time the idea of personal clouds had a lot of traction and a number of supporters. We built a demonstration app called Forever and later, I based the Fuse connected car application on this idea: let people control and use the data from their cars without an intermediary. Fuse's technical success showed the efficacy of the idea at scale. Fuse had a mobile app and felt like any other connected car application, but underneath the covers, the architecture gave control of the data to the car's owner. Dave Winer has also developed applications that use a substitutable backend storage based on Node.

Regular readers will wonder how I made it this far without mentioning picos. Forever and Fuse were both based on picos. Picos are designed to be self-hosted or hosted by providers who are substitutable. I've got a couple of projects tee'd up for two groups of students this winter that will further extend the suitability for picos as backends for dApps:

• Support for Hosting Picos—the root pico in any instance of the pico engine is the ancestor of all picos in that engine and thus has ultimate control over them. To date, we've used the ability to stand up a new engine and control access to it as the means of providing control for the owner. This project will allow a hosting provider to easily stand up new instance of the engine and its root pico. For this to be viable, we'll use the support for peer DIDs my students built into the engine last year to give owners a peer DID connection to their root pico on their instance of the engine and thus give them control over the root pico and all its decedents.
• Support for Solid Pods—at IIW this past October, we had a few sessions on how picos could be linked to Solid pods. This project will marry a pod to each pico that gets created and link their lifecycles. This, combined with their support for peer DIDs, makes the pico and its data movable between engines, supporting substitutability.

If I thought I had the bandwidth to support a third group, I'd have them work on building dApps and an App Store to run on top of this. Making that work has a few other fun technical challenges. We've done this before. As I said Forever and Fuse were both essentially dApps. Manifold, a re-creation of SquareTag is a large dApp for the Internet of Things that supports dApplets (is that a thing?) for each thing you store in it. What makes it a dApp is that the data is all in picos that could be hosted anywhere...at least in theory. Making that less theoretical is the next big step. Bruce Conrad has some ideas around that he calls the Pico Labs Affiliate Network.

I think the work of supporting dApps and personal control of our data is vitally important. As I wrote in 2014:

On the Net today we face a choice between freedom and captivity, independence and dependence. How we build the Internet of Things has far-reaching consequences for the humans who will use—or be used by—it. Will we push forward, connecting things using forests of silos that are reminiscent the online services of the 1980's, or will we learn the lessons of the Internet and build a true Internet of Things?

From The CompuServe of Things
Referenced 2023-11-12T17:15:48-0500

The choice is ours. We can build the world we want to live in.

Permissionless and One-to-One

Phil Windley // Tue Nov 7 20:10:00 2023 // decentralization identity ssi autonomic didcomm

In a recent post, Clive Thompson speaks of the humble cassette tape as a medium that had a "a weirdly Internet-like vibe". Clive is focusing on how the cassette tape unlocked creativity, but in doing so he describes its properties in a way that is helpful to discussions about online relationships in general.

Clive doesn't speak about cassette tapes being decentralized. In fact, I chuckle as I write that down. Instead he's focused on some core properties. Two I found the most interesting were that cassette tapes allowed one-to-one exchange of music and that they were permissionless. He says:

If you wanted to record a cassette, you didn’t need anyone’s permission.

This was a quietly radical thing, back when cassette recorders first emerged. Many other forms of audio or moving-image media required a lot of capital infrastructure: If you wanted to broadcast a TV show, you needed a studio and broadcasting equipment; the same goes for a radio show or film, or producing and distributing an album. And your audience needed an entirely different set of technologies (televisions, radios, projectors, record players) to receive your messages.

From The Empowering Style of Cassette Tapes
Referenced 2023-11-02T08:01:46-0400

The thing that struck me on reading this was the idea that symmetric technology democratizes speech. The web is based on assymetric technology: client-server. In theory everyone can have a server, but they don't for a lot of reasons including cost, difficulty, and friction. Consequently, the web is dominated by a few large players who act as intervening administrative authorities. They decide what happens online and who can participate. The web is not one-to-one and it is decidedly not permissionless.

In contrast, the DIDComm protocol is symmetric and so it fosters one-to-one interactions that provide meaningful, life-like online relationships. DIDComm supports autonomic identity systems that provide a foundation for one-to-one, permissionless interactons. Like the cassette tape, DIDComm is a democratizing technology.

Photo Credit: Mix Tape from Andreanna Moya Photography (CC BY-NC-ND 2.0 DEED)

Cloudless: Computing at the Edge

Phil Windley // Thu Nov 2 09:01:00 2023 // cloudless picos iot tesla

Doc Searls sent me a link to this piece from Chris Anderson on cloudless computing. Like the term zero data that I wrote about a few weeks ago, cloudless computing is a great name that captures an idea that is profound.

Cloudless computing uses cryptographic identifiers, verifiable data, and location-independent compute¹ to move apps to the data wherever it lives, to perform whatever computation needs to be done, at the edge. The genius of the name cloudless computing is that it gets us out of the trenches of dapps, web3, blockchain, and other specific implementations and speaks to an idea or concept. The abstractions can make it difficult get a firm hold on the ideas, but it's important to getting past the how so we can speak to the what and why.

You'd be rightly skeptical that any of this can happen. Why will companies move from the proven cloud model to something else? In this talk, Peter Levine speaks specifically to that question.

One of the core arguments for why more and more computing will move to the edge is the sheer size of modern computing problems. Consider one example: Tesla Full Self Driving (FSD). I happen to be a Tesla owner and I bought FSD. At first it was just because I am very curious about it and couldn't stand to not have first-hand experience with it. But now, I like it so much I use it all the time and can't imagine driving without an AI assist. But that's beside the point. To understand why that drives computing to the edge, consider that the round trip time to get an answer from the cloud is just too great. The car needs to make decisions onboard for this to work. Essentially, to put this in the cloudless perspective, the computation has to move to where the data from the sensors is. You move the compute to the data, not the other way around.²

And that's just one example. Levine makes the point, as I and others have done, that the Internet of Things leads to trillions of nodes on the Internet. This is a difference in scale that has real impact on how we architect computer systems. While today's CompuServe of Things still relies largely on the cloud and centralized servers, that model can't last in a true Internet of Things.

The future world will be more decentralized than the current one. Not because of some grand ideal (although those certainly exist) but simply because the problems will force it to happen. We're using computers in more dynamic environments than the more static ones (like web applications) of the past. The data is too large to move and the required latency too low. Cloudless computing is the future.

Notes

1. Anderson calls this deterministic computer. He uses that name to describe computation that is consistent and predictable regardless of how the application gets to the data, but I'm not sure that's the core idea. Location independence feels better to me.
2. An interesting point is that training the AI that drives the car is still done in the cloud somewhere. But once the model is built, it operates close to the data. I think this will be true for a lot of AI models.

Photo Credit: Cloudless Sunset from Dorothy Finley (CC BY 2.0 DEED - cropped)

Internet Identity Workshop 37 Report

Phil Windley // Sun Oct 22 14:58:00 2023 // identity iiw

We recently completed the 37th Internet Identity Workshop. We had 315 people from around the world who called 163 sessions. The energy was high and I enjoyed seeing so many people who are working on identity talking with each other and sharing their ideas. The topics were diverse. Verifiable credentials continue to be a hot topic, but authorization is coming on strong. In closing circle someone said (paraphrashing) that authentication is solved and the next frontier is authorization. I tend to agree. We should have the book of proceedings completed in about a month and you'll be able to get the details of sessions there. You can view past Books of Proceedings here.

As I said, there were attendees from all over the world as you can see by the pins in the map at the top of this post. Not surprisingly, most of the attendees were from the US (212), followed by Canada (29). Japan, the UK, and Germany rounded out the top five with 9, 8, and 8 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 IIW38, please let us know. If you're working on identity, we want you there.

In terms of states and provinces, California was, unsurprisingly, first with 81. Washington (32), British Columbia (14), Utah (11), Ontario (11) and New York (10) rounded out the top five. Seattle (22), San Jose (15), Victoria (8), New York (8), and Mountain View (6) were the top cities.

Doc Searls has several hundred photos from Day 1, Day 2, and Day 3 of IIW on his Flickr account.

As always the week was great. I had a dozen important, interesting, and timely conversations. If Closing Circle and Open Gifting are any measure, I was not alone. IIW is where you will meet people to help you solve problems and move your ideas forward. Please come! IIW 38 will be held April 16-18, 2024 at the Computer History Museum. We'll have tickets available soon.

Photo Credits: Doc Searls

Zero Data

Phil Windley // Thu Oct 5 15:17:00 2023 // zero+data identity verifiable+credentials zero+trust

A few weeks ago, I came across this article from StJohn Deakin from 2020 about zero data. I've been thinking a lot about zero trust lately, so the name leapt out at me. I immediately knew what StJohn was speaking about because I've been talking about it too. My new book, Learning Digital Identity, talks about the concept. But the name—zero data—is simply brilliant. I want to dig into zero data in this post. I'll discuss the link between zero data and zero trust in a future post.

StJohn describes the idea like this:

Personal data should be held by humans first, and by the companies, organisations and governments that humans choose to interact with, second. The ultimate in ‘data minimisation’ is for the platforms in the centre to simply facilitate the interactions and not hold any data at all. This is the exact opposite of our Google/Facebook/Amazon dominated world where all human data is being concentrated in a few global silos.

A zero data society doesn’t mean that data isn’t shared between us, quite the opposite. With increased trust and participation, the data available and needed to drive our global society will explode exponentially.

From The Future of Data is ‘Zero Data’
Referenced 2023-09-30T17:37:15-0600

If you think about this in the context of how the internet has worked for the last three decades, the concept of zero data might seem baffling. Yet, consider a day in your life. How often do you establish lasting relationships—and thus share detailed information about yourself—with every individual or entity you come across? Almost never. It would be absurd to think that every time you grab a coffee from the local store, you'd need to form a lasting bond with the coffee machine, the cashier, the credit card terminal, and other customers just to facilitate your purchase. Instead, we exchange only the essential information required, and relevant parties retain just the data that is needed long term.

To build a zero data infrastructure we need to transfer trustworthy data just-in-time. Verifiable credentials (VCs) offer a way to represent information so that its authenticity can be verified through cryptographic means. They can be thought of as digital attestations or proofs that are created by an issuer about a subject and are presented by the holder to a verifier as required.

Here are some of the interaction patterns facilitated by verifiable credentials:

• Selective Disclosure: VCs enable users to share only specific parts of a credential. For instance, a user can prove they are of legal age without revealing their exact date of birth.
• Credential Chaining: Multiple credentials can be linked together, enabling more complex proofs and interactions. For example, an employer might hire an employee only after receiving a VC proving they graduated and another proving their right to work.
• Holder-Driven Data Exchange: Instead of organizations pulling data about users from third parties, VCs shift the interaction model to users pushing verifiable claims to organizations when needed.
• Anonymous Credential Proofs: VCs can be designed to be presented anonymously, allowing users to prove a claim about themselves without revealing their identity. For example, VCs can be used to prove the customer is a human with less friction than CAPTCHAs.
• Proofs without Data Transfer: Instead of transferring actual data, users can provide cryptographic proofs that they possess certain data or prove predicates about the data, reducing the exposure of personal information. For example, VCs can be used to prove that the subject is over 21 without revealing who the subject is or even their birthdate.
• Adaptive Authentication: Depending on the sensitivity of an online interaction, users can be prompted to provide VCs of varying levels of assurance, enhancing security in adaptable ways. I plan to talk about this more in my next post about zero data and zero trust.

These interaction patterns change traditional data management and verification models, enabling businesses to retain considerably less data on their clients. Verifiable credentials have numerous benefits and features of that provide a positive impact on data management, security, and user trust:

• Data Minimization: As we've seen, with VCs, users can prove facts without revealing detailed data. By selectively sharing parts of a credential, businesses only see necessary information, leading to overall reduced data storage and processing requirements.
• Reduced Redundancy & Data Management: Trustworthy VCs reduce the need for duplicate data, simplifying data management. There's less need to track, backup, and maintain excess data, reducing complexity and associated costs.
• Expiration, Revocation, & Freshness of Data: VCs can be designed with expiration dates and can be revocable. This ensures verifiers rely on up-to-date credentials rather than outdated data in long-term databases.
• Trust through Standardized Protocols: VCs, built on standardized protocols, enable a universal trust framework. Multiple businesses can thus trust and verify the same credential, benefiting from reduced integration burdens and ensuring less custom development.
• Enhanced Security & Reduced Exposure to Threats: Data minimization reduces the size of the so-called honey pot, reducing the attraction for cyber-attacks and, in the event of a breach, limit the potential damage, both in terms of data exposed and reputational harm.
• Compliance, Regulatory Benefits & Reduced Liability: Adhering to data minimization aligns with many regulations, reducing potential legal complications. Storing minimal data also decreases organizational liability and regulatory scrutiny.
• Cost Efficiency: By storing less data, organizations can achieve significant savings in storage infrastructure and IT operations, while also benefiting from focused data analytics.
• Enhanced User Trust & Reputation: By collecting only essential data, organizations can build trust with users, gaining a competitive edge in a privacy-conscious market that is increasingly growing tired of the abuses of surveillance capitalism.

In essence, verifiable credentials shift the paradigm from "data collection and storage" to "data verification and trust." This is what Marie Wallace means with her analogy between VCs and music streaming. Online interactions are provided with the assurance they need without the business incurring the overhead (and risk) of storing excessive customer data. Zero data strategies not only reduce the potential attack surface for cyber threats but also offers a variety of operational, financial, and compliance benefits.

The biggest objection to a zero data strategy is likely due to its decentralized nature. Troves of user data make people comfortable by giving them the illusion of ready access to the data they need, when they need it. The truth is that the data is often unverified and stale. Nevertheless, it is the prevailing mindset. Gettng used to just-in-time, trustworthy data requires changing attitudes about how we work online. But the advantages are compelling.

And, if your business model depends on selling data about your customers to others (or facilitating their use of this data in, say, an ad network) then giving up your store of data may threaten precious business models. But this isn't an issue for most businesses who just want to facilitate transactions with minimal friction.

Zero data aligns our online existence more closely with our real-world interactions, fostering new methods of communication while decreasing the challenges and risks associated with amassing, storing, and utilizing vast amounts of data. When your customers can prove things about themselves in real time, you'll see several benefits beyond just better security:

• Reduced Sign-Up Friction: For services that rely on verified attributes (e.g., age, membership status, qualifications), users can provide these attributes quickly with VCs, eliminating lengthy sign-up or verification processes.
• Cross-Platform Verification: A VC issued by one service can be verified and trusted by another, facilitating smoother cross-platform interactions and reducing the need for users to repetitively provide the same information.
• Fewer intermediaries: VCs can allow for direct trust between parties without the need for a centralized authority. This fosters more direct and decentralized interactions.

Zero data, facilitated by verifiable credentials, represents a pivotal transition in how digital identity is used in online interactions. By minimizing centralized data storage and emphasizing cryptographic verifiability, this approach aims to address the prevalent challenges in data management, security, and user trust. Allowing online interactions to more faithfully follow established patterns of transferring trust from the physical world, the model promotes just-in-time data exchanges and reduces unnecessary data storage. As both businesses and individual users grapple with the increasing complexities of digital interactions, the integration of verifiable credentials and a zero data framework stands out as a practical, friction-reducing, security-enhancing solution for the modern digital landscape.

Digital Identity Podcasts

Phil Windley // Wed Sep 20 09:53:00 2023 // identity podcast ldid ssi

I've been invited to be on a few more podcasts to talk about my new book Learning Digital Identity from O'Reilly Media. That's one of the perks of writing a book. People like to talk about it. I always enjoy talking about identity and especially how it's so vital to the quality of our lives in the digital world, so I'm grateful these groups found time to speak with me.

First, I had a great discussion about identity, IIW, and the book with Rich Sordahl of Anonyome Labs.

I also had a good discussion with Joe Malenfant of Ping Identity on digial identity fundamentals and future trends. We did this in two parts. Part 1 focused on the problems of digital identity and the Laws of Identity.

Part 2 discussed how SSI is changing the way we see online identity and the future of digital identity. We even got into AI and identity a bit at the end.

Finally, Harrison Tang spoke with me in the the W3C Credentials Community Group. We had a fun discussion about the definition of identity, administrative and autonomic identity systems, and SSI wallets.

I hope you enjoy these. As I said, I'm always excited to talk about identity, so if you'd like to have me on your podcast, let me know.

Zero Trust

Phil Windley // Mon Aug 28 20:42:00 2023 // zero+trust identity authorization authentication security

My new book Learning Digital Identity from O'Reilly Media covers many of the topics in this post such as multi-factor authentication, authorization and access control, and identity policy development in depth.

Zero Trust is a security framework that is better attuned to the modern era of sophisticated threats and interconnected systems. Past practices included techniques like virtual private networks (VPNs) that tried to emulate the idea of an intranet where trusted computers and people were protected from hackers by a firewall that "kept the bad stuff out." As more and more work has gone remote and personal devices like phones, tablets, and even laptops are being used for work, a firewall—virtual or physical—offers less and less protection. Often the bad actors are hard to tell apart from your employees, partners, and customers.

Zero Trust operates on a simple yet powerful principle: "assume breach." In a world where network boundaries are increasingly porous and cyber threats are more evasive than ever, the Zero Trust model centers around the notion that no one, whether internal or external, should be inherently trusted. This approach mandates continuous verification, strict access controls, and micro-segmentation, ensuring that every user and device proves their legitimacy before gaining access to sensitive resources. If we assume breach, then the only strategy that can protect the corporate network, infrastructure, applications, and people is to authorize every access.

Defense in Depth

Zero Trust solutions offer a multifaceted defense against the evolving threat landscape, encompassing various aspects of network security, infrastructure protection, user authentication, and application security. These solutions collectively work together to uphold the "never trust, always verify" principle. Here are some of the different kinds of Zero Trust solutions that safeguard networks, infrastructure, people, and applications from malicious actors:

1. Network Security:
   • Micro-Segmentation: Dividing the network into smaller segments to limit lateral movement of threats and control access between different segments.
   • Software-Defined Perimeter (SDP): Creating an invisible perimeter around resources, allowing authorized users and devices to connect while remaining invisible to unauthorized entities.
2. Infrastructure Protection:
   • Identity and Access Management (IAM): Implementing strong identity verification and access controls to ensure that only authenticated users can access critical resources.
   • Endpoint Security: Employing solutions that monitor and secure devices (endpoints) to prevent malware infiltration and unauthorized access.
3. User Authentication:
   • Multi-Factor Authentication (MFA): Requiring users to provide multiple forms of verification (e.g., password, fingerprint, OTP) before granting access.
   • Risk-Based Authentication: Assessing user behavior and context to dynamically adjust authentication requirements based on potential risks.
4. Application Security:
   • Application Whitelisting: Allowing only approved applications to run, preventing the execution of unauthorized or malicious software.
   • Application-Centric Authorization and Security: Implementing application-specific authorization policies and implementing security measures directly within applications, such as encryption, code signing, and runtime protection.

These Zero Trust practices collectively work to defend corporate assets in depth and implement a security architecture that assumes breach and enforces rigorous access controls. This not only reduces the attack surface, but also minimizes potential damage. By safeguarding networks, infrastructure, people, and applications, organizations can better defend against the increasingly sophisticated tactics employed by malicious actors in the digital realm. A comprehensive Zero Trust approach ensures that security is embedded at every layer, providing a robust defense against cyber threats.

Implementing Zero Trust

Some of the components of a zero trust strategy can be bought. For example, network equipment vendors offer products that make it easier to implement micro segmentation or define a perimeter. You can buy IAM solutions that make it easier to up your authentication game to simultaneously reduce phishing and the burden on your employees, partners, and customers (hint: use passkeys). You can buy a endpoint security clients for devices that make it easier to manage corporate devices and to know the security posture of both corporate and personal devices. Authorization platforms like Cedar are available to control access to your infrastructure and applications.

While vendors provide ready-made solutions for many aspects of Zero Trust, you'll still need to tailor these solutions to your organization's unique needs and integrate them into a coherent strategy. Here's breakdown of the things you need to do on your own (i.e., you can't buy these):

1. Policy Development:
   • Access Policies: You'll need to design access policies that define who can access what resources and under what circumstances.
   • Authentication Policies: Developing policies for user authentication, device verification, and authorization.
   • Organizational Policies: The organization must define how it governs the various aspects of Zero Trust and the underlying identity infrastructure.
2. Identity and Access Management (IAM):
   • Identity Management Infrastructure: Building a user identity repository, user directories, and user profiles.
   • Access Control Logic: Developing the logic that enforces access controls based on user roles and permissions.
3. Custom Integrations:
   • Integration with Existing Systems: If you have legacy systems, you might need to develop custom integrations to ensure they adhere to the Zero Trust model.
4. Training and Awareness:
   • Security Awareness Programs: Creating training materials and programs to educate employees and stakeholders about Zero Trust principles and best practices.
5. Continuous Monitoring and Analysis:
   • Threat Detection Logic: Developing mechanisms to continuously monitor network traffic, endpoints, and applications for suspicious activities.

The Zero Trust components in the preceding list require internal expertise and a deep understanding of your organization's structure and workflows. You might need to change how your organization does authentication, develop a process for installing and maintaining device clients, perform numerous integrations, create authorization policies as well as organizational policies, build threat dashboards, and institute a training program. You can get help doing this, but ultimately it's up to you.

Zero Trust represents a big change for many organizations. Implementing a Zero Trust strategy involves not just changing the architecture of your network, infrastructure, and applications, but your organizational culture as well. In a hyper-connected digital landscape marked by relentless cyber threats and evolving attack vectors, the Zero Trust model is the best defense available. By challenging the conventional "trust but verify" approach, Zero Trust asks organizations to embrace an "assume breach" mindset, demanding continuous vigilance to authorize every access.

Photo Credit: Open Gate from aitoff (Pixabay License)

Using Amazon Cognito Tokens for Fine-Grained Access Control

Phil Windley // Mon Jun 26 10:27:00 2023 // access+control amazon openid abac identity

Earlier this month Amazon launched Amazon Verified Permissions, a "scalable permissions management and fine-grained authorization service for the applications that you build." Verified Permissions has been in gated preview since November, but now it's available to everyone.

My team worked on an integration between Verified Permissions and Amazon Cognito, Amazon's OpenID Connect service. The idea is pretty simple: if you're using Cognito to manage the people who use your application, then you will likely want to use the information that is stored in Cognito for your access control policies.

Our bit of code allows developers to just submit the tokens they get back from Cognito as a result of the authentication process to Verified Permissions. Verified Permissions uses the attributes they contain to perform a policy evaluation. I wrote a blog post for the AWS Security blog about how this works called Simplify fine-grained authorization with Amazon Verified Permissions and Amazon Cognito. I'll describe the basic idea here, but the blog post has details and links.

Suppose you've got a policy that allows anyone to view any resource so long as their location is USA:

permit(
  principal,
  action == Action::"view",
  resource
)
when {principal.location == "USA"};

If Alice wants to view VacationPhoto94.jpg, then your call to Verified Permissions might look like this if you're not using the Cognito Token:

//JS pseudocode
const authResult = await avp.isAuthorized({
    principal: 'User::"alice"',
    action: 'Action::"view"',
    resource: 'Photo::"VacationPhoto94.jpg"',
    // whenever our policy references attributes of the entity, isAuthorized 
    // needs an entity argument that provides those attributes
    entities: [
        {
            "identifier": {
                "entityType": "User",
                "entityId": "alice"
            },
            "attributes": {
                "location": {
                    "String": "USA"
                }
            }
        ]
});

You have to supply information about the principal and any relevant attributes so the policy has the context it needs to evaluate correctly. Now, suppose your Cognito token contains location information as an attribute:

{
 ...
 “iss”: “User”,
 “sub”: “alice”,
 “custom:location”: “USA”,
 ...
}

Assuming the token is stored in a variable named cognito_id_token you can make a call like this:

const authResult = await avp.isAuthorizedWithToken({
    identity_token: cognito_id_token
    action: 'Action::"view"',
    resource: 'Photo::"VacationPhoto94.jpg"'
});

Using isAuthorizedWithToken, you don’t have to supply the principal or construct the entities argument. Pretty slick.

Take a look at the blog post I mentioned earlier if you're interested in using this in your application. There's more information about the configuration process and how to add resource attributes to the call. This was a fun project.

Photo Credit: Puzzle Pieces from Erdenebayar (Pixabay Content License)

Rule-Based Programming and the Internet of Things

Phil Windley // Wed Jun 7 13:35:00 2023 // picos iot rules events

Picos are a rule-based system for programming in the Internet of Things (IoT). Rules are a good fit for IoT programming because so much of what happens with things is event-based. Events say something happened. They are different from commands (telling) or requests (asking). A sensor might indicate the door opened, a light came on, or the temperature passed some threshold. An actuator might indicate its current status.

Rules, triggered by an event, determine what should be done to respond to the event. IoT rule-systems use event-condition-action (ECA) rules: when something happens, if this is true, do this. Multiple rules can be triggered by the same event. This allows functionality to be layered on. For example, an event that contains the temperature reported by a sensor might also report the sensor's batter level. One rule that responds to the event can handle the temperature report and another, independent rule can handle the battery level.

Picos are an actor-model programming system. Actors are a good match for IoT programming using rules. Actors keep state information and respond to events (messages) by changing their state, taking action, and possibly raising other events. Actors provide lock-free concurrency, data isolation, location transparency, and loose coupling. These are great features to have in IoT programming because devices are naturally decentralized, each acting independently.

Building a functional system usually involves multiple picos, each with a number of rules to respond to the events that the pico will handle. For example, I recently built a sensor network using picos for monitoring temperatures in a remote pump house using Lorawan. There is one pico for each sensor and a community sensor that manages them. The temperature sensor pico acts as a digital twin for the sensor.

As the digital twin, the sensor pico does all the things that the sensor is too low-powered (literally) to do. For example, one rule receives the heartbeat event from the sensor, decodes the payload, stores values, and raises new events with the temperature values. Another rule processes the event with the new values and checks for threshold violations. If one occurs, it raises an event to the sensor community pico. Another rule sees the new value event and takes an action that plots the new value on an external site. And there are others. The point is that rules make it easy to break up the tasks into manageable chunks that can thread execution differently, and concurrently, depending on Pixabay what's happening.

I've been using picos to program IoT systems for over a decade now. Rule-based, actor model systems are a great match for IoT workloads.