Decentralized Identity Secures AI Agent Trust
Mike Vizard talks with Alexander Shcherbakov of DSR Corporation about why AI agents need stronger identity, trust and credentialing models as agent-to-agent communication becomes more common. Shcherbakov explains how decentralized identity, verifiable credentials, OpenID Connect and selective disclosure can help organizations manage delegation, privacy, auditability and cross-organization trust. The conversation also explores agent registries, chains of trust, Linux Foundation decentralized trust projects and why AI agents will need identities that are both cryptographically verifiable and operationally practical.
Transcript
Hey everybody, we're back at the Open Source Summit here in Minneapolis, and we're having a little chat about AI agents and identity. Alex, welcome to the show. Thank you.
I think we're all familiar with human identities, and we have some passing familiarity with the notion of non-human identities. And then there's these AI agents that kind of sit in between those two things. In some cases, they inherit my permissions as the end user.
In other cases, they're kind of autonomous and they exist as their own kind of being, for lack of a better phrase. How should we be thinking about identity and management of these AI agents as this whole era evolves? Yeah.
Identity is always a very essential part of any communication between humans and humans, between humans and machine, and of course, machine to machine, agent to agent. And what we can see these days in this agent-to-agent protocols era, it's more and more communication between agents to agents, and trust, identity, security, it's all pretty important. And I think sometimes people try to have some shortcuts here, which of course work short term.
And of course, there are cases that traditional identity like enterprise view and identity, OAuth, OpenID Connect, it works in many cases. But at the same time, we should still consider the power of decentralized identity here. For example, there are cases when it's not sufficient just to have a static token with some privilege.
It's better to have more dynamic capability, qualification-based credentials, like verifiable credentials. And what's important here, it's maybe quite trivial for people who came from this decentralized identity world, maybe less clear for people who just going into AI world, that decentralized identity, verifiable credentials, decentralized ID, these things are actually not that new. It's been adopted in the world.
It's been there for 10 years. There are stable versions of the protocol. And moreover, they've been used by many industries, by many governments all around the world.
Mm-hmm. And of course, it's worth mentioning mobile driver license initiative in US. There is a decentralized identity being applied in Bhutan.
There is, of course, IDS too, and UDI wallet. It's one of the most huge adoption of these principles on the whole European Union level. So for example, by next year, every citizen or resident of European Union will have a possibility to use a wallet to use verifiable credentials and to apply these to various use cases.
It's banking, fintech, digital KYC, AML checks, whatever. And it's pretty important also since humans have this power, since technology's already there, it's very clear that we should actually apply the very same principles to agent-to-agent world. It's sad to say, but I think a lot of people haven't done anything yet.
And then so for those folks, what's the trade-offs between centralized and decentralized approaches? What's the benefit of one versus the other? Yeah.
Of course, if you are talking about a closed system, like enterprise system, probably for this very closed environment, you don't need a very fancy decentralized identity principle. So you may just share the same authorization server, and it works. Standard OAuth 2 approaches, they will work for sure.
But let's assume that we are working in a more open cross-boundary, cross-organizational flows, of course, where we may not just have technically this shared common authorization service, the same patterns. We want to be more dynamic. So we want agents to discover other agents.
We want agents to have this mutual trust. So on one hand, it should be cryptographically proven. On the other hand, it should be open without any restrictions.
And that's where decentralized identity may help. So there, actually, the agents can just trust credentials issued by people, by organizations, by humans. It's very important.
And the second important thing where decentralized identity can actually help, it's a use case for delegation. So basically, usually we have two patterns how decentralized identity can be applied to agent-to-agent world. The first pattern is exactly about this delegation.
So for example, a human may delegate some tasks to the agent for autonomous execution later on, and these cryptographically verifiable credentials can actually help here to have this essential chain of trust. And what we can see, these principles are already being adopted that chain. So the protocols like AP2 protocol, verifiable intent protocol being developed by Google, MasterCard, it's already the standards applying the very same principles for that real payment, agent commerce, agent-to-agent communication.
Right? The second pattern here that, of course, for some activities, we may still have a human in loop. So we may still require the agent to trigger a callback to the human to approve some action, to give consent, to present any information which is missing, and it's still a valid pattern.
It's of course, maybe even easier for some initial integration, initial adoption on one hand, and maybe still critical, maybe a way to go for some high-stake use cases. So kind of these two pattern, autonomous delegation from humans to the agent, and the second one, when human is still in the loop, it's kind of callback. And this very same credential can be used.
There are attributes that make up our identities, and we use that to essentially authenticate and authorize. And what attributes should an AI agent have as part of its identity that everybody should know how to program to, and is that standard, or is that still being developed? Well, I think there are two pieces here.
So the first one is technical standards, and they're already there. There's the very same standard being adopted, for example, by the government, as for the FIDO wallet IDs too. 0C, it's probably the most adopted standard as of now from OpenID Foundation about how actually this issuance and presentation should work under the hood.
And it's also based on OAuth. So it's like this very same common principles for enterprises, but with the new kind of use cases. And there's formats for verifiable credentials.
So all these foundational technical layers are already there. And the second piece, of course, it's the use case and how exactly we apply it to the agents and what exact claims should be there, how they should be approved by the users. Here we are still, I believe, evolving, but already there are two standards that I mentioned, AP2 and Verifiable Intent from Google.
I think they all can be considered as a very good example how this problem can be solved. So for example, for this payment use cases, as part of AP2 or Verifiable Intent, they have a concept of mandates. It's like a set of claims.
It's a defined schema, what claims should be there. And this kind of the claims where the user has explicit consent and cryptographic signature that agrees for this particular checkout, particular goods to be paid by the agent, and also the particular payment received and credential being verified also by the payment network. So this kind of logical part, like a schema part, what exact claims are there, it's also being developed, and it's also, I believe, should be adopted pretty soon.
Yeah. Are we going to see, for lack of a better phrase, will miscreants and other folks create agents that are essentially imposters of other agents and try to load those onto our workflows and into our environments? And I don't think people are thinking about that particular issue, but it seems like it's a logical extension of what will happen.
Yes, that's true. And I think these technologies can also help to have honest agents and kind of restrict what they can do, right? Because every agent should not just do whatever they want.
They should, of course, be open in their operational discovery on one hand, but still, they should have clear boundaries what they're allowed to do by humans, by other agents. And it's very important that it all should be cryptographically verifiable. So it's not just some agent decided that a subsequent agent can do anything.
No, it should still be verifiable up to the source of trust. And the source of trust can be a human who started this task, or even maybe the organization who issued credential for that human. For example, a bank issued a credential for a human that know your customer check has passed, right?
And the whole communication from the agent, for example, the agent is some agent working with DeFi or permissioned DeFi protocol, where it's important to prove that the corresponding user has passed this KYC. So it can be like a chain of cryptographical credentials trust back to the issuer. So it's all cryptographically verifiable and uses the same trust rails to make it- Mm-hmm ...
trust worthy. Well, some of these agents might also be, for lack of a better phrase, secret agents, and they may be performing the task assigned to them, but they could be in the background doing all kinds of stuff that I have to go look for, right? Yes, of course.
Of course. It should be like a central layer in all this communication. And also what is important here, I think, it's a concept of selective disclosure.
So the decentralized identity technology, one of the core principle, of course, is to care about the privacy. And actually, when we are talking about the agents, on one hand, we may say, well, it's a bit the opposite. We should have audit log what agents are doing.
And that's true. And of course, the cryptographic signature allows us to create this log. But on the other hand, still the agents may operate with some of our PAI's, some of our data when we delegate some task.
And yeah, for example, if agent performs a checkout, probably some personal information needs to be filled in. And these selective disclosure properties can still be useful here. So for example, we may instruct the agent from our instruction, user instructions, and from the underlying technology to disclose only necessary information.
For example, if some action requires a check that the user should be over 21, it's sufficient just to prove this fact that the user is over 21, right? Or over 18. Mm-hmm.
That doesn't need to disclose even the exact age, the address, the name, et cetera. It's probably not needed. Just the fact that over 21.
And the agents can also leverage this very nice important privacy preserving properties. Are we, as part of this process, going to create something that feels like the equivalent of a whitelist for AI agents that are authorized, that we now know and acknowledge? And do they register themselves somewhere?
How does this all come to be? Yeah. It's a good question.
And these days we have, I believe, a new agent registry protocol appearing like every day. Because yeah, people realize this problem, of course, and there can be different ways how it can be solved. You can leverage blockchain, the centralized ledgers, you can have this trust.
And I think right now it's too early to say how exactly it will look like in future. So there is, I believe, a couple of concepts, frameworks being developed and adopted. One of the approach here from my point of view is, as I mentioned before, one of the ways how to solve it can be not just explicit whitelist, but kind of a chain of trust.
So you have a whitelist of root entries, like issuers. It's the same principle, for example, how TLS work in these days, right? How the certificates work.
You have a limited list of trusted entities, and you have a hierarchical chain. Right? So people or organizations can be the source of trust, and we can just leverage the very same rails being adopted now, for example, as part of different industries or governments, whatever.
And they can delegate cryptographically sign the corresponding credentials, keys, certificates, and so on. Can be one approach. Another approach, of course, can be that there is something like a whitelist.
And there is a number of also approaches here. Blockchain, distributed ledger, I think it can be a very use case for some of these things. For example, there are some ERC, ERC-804 standard being developed these days.
And yeah, it kind of allows to have a registry, a record on chain for an agent with their capability, with their metadata. And also what is important here when we are talking about this registry is some kind of reputation should probably be attached, right? So it's kind of agents and humans should see what is the history of...
Not maybe explicitly history, but what is the reputation? Is it trustworthy? Any malicious behavior detected, and so on.
On the first day of this show, I think they were talking about using DNS also to maybe help manage some of these AI agents and et cetera. Yeah. It feels like we're going to have to build a stack of capabilities that are going to become a central, well, or decentralized, depending.
Yeah. But it's a set of services that we're going to use to have these AI agents kind of alert us to their presence and what they're doing and what actions they're taking. Exactly.
Is that the framework? Yes, exactly. One of the approaches, yes, DNS from GoDaddy, they mentioned it.
So perhaps there won't be just one solution for this problem. Depending on the industry, depending on the framework they've been using. So for example, if the industry, the enterprise uses some existing distributed ledger technology or blockchain technology, maybe for that use case, it would be essential to have some whitelist on the very same blockchain, right?
Because they already have a trust rooted on this blockchain distributed ledger, like a set of Linux Foundation project like Besu or Fabric or open networks like Ethereum or Hedera, of course, Cairo is very good example here. So they just don't need to invent something new. They can leverage the approaches applicable to their existing infrastructure.
For some use cases, of course, which are more open, they can use whatever also fit them. Is it something like DNS or, you know. How long will all this take?
And I'm asking the question because I think everybody's playing around with AI agents, but when I look at it, everybody's, an individual is using it to perform some task. We're not really having our agents kind of interoperate with each other to collectively do something, and maybe some folks are, but generally speaking, it's not commonplace yet. So how long will it take to put this infrastructure that you're describing in place to make all that commonplace?
I think it will coincide with the development of adoption of the centralized identity, and what we have seen here is already happening. For example, EUIWA that I mentioned this year, next year, I believe, are very crucial years for the whole deployment. So next year, I think it will be really mass adoption of these technologies.
And eventually, it will be applied not only to humans, but to the agents as well. It's one thing. The second thing that the tools, the open source tooling is already there.
So, agent-to-agent protocol, and actually DSR Corporation, we contributed the extension, the working extension, to agent-to-agent protocol. It's also an agent-to-agent organization, which applies OpenID for VC protocol verifiable credential to this problem. So the tooling is there.
It can be used. And also open source projects like, for example, Hiero HeCA, they already have a working examples how it may all work together and how it can be applied to existing use cases. So the tools are there.
The regulations, the governance is coming. It's almost there. I believe once it's all kind of converges.
And are you working with any arms of the Linux Foundation on any of this? Or what exactly is your company and the relationship- Yeah ... with the foundations?
What are you guys doing? Yeah. DSR Corporation, we are the members of Linux Foundation and members of Linux Foundation decentralized trusts, and also Open Wallet Foundation is like one of the two main foundations working with these technologies.
And we've been working with these technologies for many years, like for 10 years plus. And personally, I was a maintainer and contributor of one of the very first pioneering frameworks for decentralized identity, Hyperledger Indy. And since then, yeah, we are still contributing to many things.
Our recent contributions are this extension to agent-to-agent protocol. And here we've been working with the agent-to-agent community, to kind of make it instrumental extension an official one. I think good chances to make it happen in a very near future.
And also as part of LFDT, this HeCA framework, it's also was recently open sourced by DSR as part of Hiero Hedera. But yeah, of course, it's can one of the options to use Hedera Ledger as a source of trust, but it has multiple things besides the different options also. So kind of this is one of the two main recent initiatives.
But besides of this, yeah, of course, we've been applying different technologies. And Linux Foundation, I believe it's a very good place for these frameworks to be found. As part of LFDT, very nice frameworks like Besu for Ethereum client, Hyperledger Fabric, Hiero Hedera.
As part of Open Wallet Foundation, a lot of frameworks like APY, Credor, Bifold, MultiPass, which are like existing tools that people can just take and use for their use cases by applying this principle. So yeah. The DSR, of course, we've been contributing and using all these technologies.
All right. Folks, AI agents, they're not having an identity crisis yet, but they sure will soon. So Alex, thanks for coming by.
Thank you. And we'll be back in a minute.