Dock Labs

I put an hypothesis to Andrew Shikiar (CEO, FIDO Alliance) that we have been working through internally at Dock Labs. He agreed with it, and then added a part I hadn't fully considered: This hypothesis about EUDI comes in two layers. At the bottom is the regulated core. The Personal Identity Document (PID) provided by the member states. This is the foundational government-backed credential a citizen actually holds. Above that sits an open layer. Companies that never issue a government credential themselves, but build on top of one, using it to issue credentials of their own for a specific purpose. In EU terminology, electronic attestations of attributes (EAAs). Or as I like to call them, derived credentials. Our bet is that the bigger opportunity is in that second layer, because one verified identity underneath can serve a very large number of use cases. His response was that derived credentials will become a very common model, and that he is not sure everyone has got their head around that yet. I think the mechanic is simple. Pull the attributes you need from a verified national ID credential, combine them with your own first party data, and issue your own credential resting on the cryptographic proof underneath. In Andrew's framing, this will be a high assurance identity delivered without having to reprove the identity from scratch each time. In my view, this model would convert a repeated per-event verification cost into a one-time proofing event you can reuse across many relationships. A different business, not a cheaper version of the existing one. Here is what he added: Interoperability stops being a preference and becomes critical once you are in the derived credential world. You can only build on top of someone else's foundational credential if every wallet in the chain implements the same profile the same way. Same formats. Same presentation protocols. Same reliability, trust, and privacy models. Get that wrong and this fragments into per-wallet integrations. I’ll leave the link to the full recording of the conversation with Andrew in the comments below.

Here’s the clearest way I’ve found to explain AP2, the Agent Payments Protocol created by Google: An AI agent is about to buy something on your behalf. But, right now, it’s very difficult to verify: • You authorized the agent to act • You defined what it was allowed to buy • You set limits on the merchant, price, payment method or timing • The final transaction stayed within those limits AP2 addresses this by representing your authorization and constraints as cryptographically signed mandates that can be shared and verified across the transaction. The Checkout Mandate captures what the agent is authorized to buy and the conditions the checkout must satisfy. The Payment Mandate authorizes payment for that checkout, including constraints such as the amount, payee, payment instrument and timing. In an autonomous flow, the user first approves open mandates that set the boundaries for the purchase, such as “buy two tickets for no more than $300.” The agent then shops within those boundaries. Once it finds a qualifying option and receives the final checkout details from the merchant, it creates closed mandates that record the exact tickets, merchant, price and payment being authorized. Instead of asking everyone in the payment chain to trust the agent’s version of events, AP2 gives the relevant participants evidence they can independently verify before relying on the transaction. The merchant does not have to take the agent’s word for it. The payment provider does not have to reconstruct consent from internal logs. And the user does not have to return to approve every step, provided the transaction remains within the constraints approved in advance. That is the simplest way I think about AP2: It is the authorization and coordination layer payments needed when the buyer is software. We’ve now implemented AP2 mandate issuance and verification on Truvera, so you can start testing these flows without building the underlying credential infrastructure yourself. If you’re exploring AP2 or agentic commerce, get in touch. I’d be happy to discuss where it could create the most value in your payments strategy.

I'm heading to the Global Digital Collaboration conference in Geneva, September 1-3. Dock Labs will be on panels about Business Wallets, telecom identity use cases, and agentic identity. Three topics I've been deep in lately, so I'm looking forward to the opportunity to share our experience with the community. As cool as it feels to be on a panel, I am genuinely worried on what I will be missing from the other sessions, getting to hear how others across the ecosystem are approaching the same problems. The program spans alternatives to mDL, EU Business Wallets under eIDAS, organizational identity, data minimization, decentralized trust, and more. Will be great to see familiar faces and meet new ones, so come say hi.

I’m excited to share something we’ve been heads-down building: Truvera now lets you issue and verify AP2 mandates that provide verifiable proof of what an AI agent was authorized to do on a user’s behalf. AI agents will increasingly research products, compare options and make purchases for us. That could be genuinely useful, but it raises a fundamental question: How does anyone know that an agent had permission to do what it just did? At the core of AP2 v0.2 are two primary mandate types: → A Checkout Mandate records what the agent is authorized to purchase and the conditions it must meet. → A Payment Mandate records how the purchase is authorized to be paid for, including constraints such as the payment method, amount and timing. When the customer is not present, they can approve constraints in advance, such as the permitted merchant, items, spending limit or time period.  Before processing the purchase, merchants and payment providers can verify that the transaction meets those constraints. Google announced AP2 in collaboration with more than 60 organizations, including Mastercard, PayPal and Etsy. In April, Google contributed it to the FIDO Alliance. That is a strong signal that the industry is taking the trust problem in agentic commerce seriously. We built Truvera’s AP2 support to make it easier for organizations to start acting on this. Through our MCP servers, you can issue and verify AP2 mandates without building the underlying credential infrastructure from scratch. If you’re exploring AP2, I’d love to connect and discuss where it could add the most value to your agentic commerce strategy.

I’m excited to announce that you can now issue and verify AP2 mandates through Truvera, providing merchants and payment providers with verifiable proof of what an AI agent was authorized to do on a user’s behalf. Today’s payment infrastructure assumes a person is present and clicking “buy.” When an AI agent acts instead, businesses need to know that the transaction falls within the authority granted by the user. Without that evidence, disputes become much harder to resolve. Google announced AP2 in collaboration with more than 60 organizations, including Mastercard, PayPal and Etsy. In April, Google contributed it to the FIDO Alliance, where it will continue to be developed through an open standards process. At the core of AP2 v0.2 are two primary mandate types: → A Checkout Mandate records what the agent is authorized to purchase and the conditions it must meet. → A Payment Mandate records how the purchase is authorized to be paid for, including constraints such as the payment method, amount and timing. When the user is not present, they can approve constraints in advance, such as the permitted merchant, items, spending limit or time period. The agent can proceed only when those conditions are met. The mandates give merchants and payment providers evidence they can verify before processing the transaction. We built Truvera’s AP2 support so teams can start testing agentic commerce flows without having to build the underlying credential and verification infrastructure themselves. If you’re exploring AP2, send me a message. We’d be happy to discuss where it could create the most value in your agentic commerce strategy.

Everyone's asking the wrong question about EUDI. I keep hearing "how do we comply?" But that framing quietly throws away the actual opportunity. Every EU member state will soon offer citizens a government-issued digital identity wallet with a verified ID document inside (a PID). So most companies are lining up to treat it as a checkbox: verify the person, confirm they are who they say they are, move on. Verifying the PID once gets you a verified person. That's it. But the government-issued credential is deliberately narrow. It contains name, date of birth, national ID. That says nothing about the customer's relationship with you: their account tier, their status, their entitlements, their history. In my view, the value was never in re-verifying identity on every interaction.  It's in taking that government-backed foundation, enriching it with what you uniquely know, and issuing a new credential your customer carries forward. Do that, and something shifts. That credential becomes reusable trust infrastructure.  Your partners can accept it for multiple verification and auth purposes because the government-verified data AND all the context you provide about the customer travels inside it. You stop being a consumer of identity and become an identity provider in your own right. Most will treat EUDI as a checkbox. I think the winners in this ecosystem will treat it as a starting point. If you see it the same way, get in touch. We can help you prepare for when the EUDI ecosystem launches, so that you can consume government-issued PIDs and issue new credentials that combine verified identity attributes with your own business-specific data.

Andrew Shikiar, CEO of the FIDO Alliance, is joining us live on the podcast to talk about where passkeys and verifiable credentials complement each other, FIDO's plans for wallet certification, the role the EUDI Wallet could play globally, and what a service actually needs to know before trusting an AI agent to transact. Register now: https://lnkd.in/gyPhYhtw If you're thinking about where identity, authority, and trust are heading, this is a good hour to block out. 📅 July 30th, 9am California / 5pm London. Online and free.

I keep coming back to an idea from last week's fraud hearing on Capitol Hill: a credential that was true the day it was issued doesn’t necessarily tell you about who is holding it today. Jordan Burris of Socure told Congress that a single fraud ring created nearly 25,000 synthetic identities and launched more than 35,000 attacks in just 30 days. His point was blunt: the adversary has changed, but the federal identity model has not. For decades, matching a name, date of birth, and SSN against government records counted as proof of identity. That is no longer enough. Dr. David Maimon of SentiLink described how criminals now combine stolen identities with AI-generated faces and deepfake video to defeat liveness checks, using face-swapping software available to anyone.  Marisol Cruz Cain, CIPP-G, CIPP-US, CISSP of the GAO pointed to the structural gap: login.gov did not meet the NIST IAL2 standard because it never linked a user to a real-life identity through a biometric comparison. That last point is the one I keep coming back to. Here is the pattern I see across almost every one of these breaches: Systems verify identity once, at enrollment, and then trust that result forever. But a credential that was true the day it was issued doesn’t tell you about who is holding it today. If there is no binding between the person and the credential, a stolen or synthetic identity walks straight through every check that comes after. This is exactly why we built biometric-bound credentials into Truvera. The credential is cryptographically tied to the holder's biometric, so verification is not a one-time gate at signup. It is continuous.  Every time the credential is presented, you are confirming the same person who was verified at issuance is the one using it now, not someone who bought their PII on a forum. Maimon made the case that the signal criminals cannot easily fabricate is historical evidence of a real person over time. I would add one more: the live binding between a human and their credential. AI can generate a face. It cannot generate possession of a credential locked to a specific person's biometric. Curious how others here are thinking about continuous verification versus one-time proofing. Is binding the credential to the person the missing piece, or are you solving this another way?

The most common worry I hear about EUDI: am I going to have to juggle three or four different wallets? I think that's the wrong question. Here’s why: A wallet doesn't have to be a standalone app. The state wallet will be its own thing, yes. But private wallets can be embedded inside applications you already use. Your bank credentials live in your bank app. Your work credentials live in your work app. You already do this. Your concert ticket is in one wallet, your transit card in another, your building access somewhere else, and you never think of them as separate wallets. You just think "I need my ticket." Here's the part that gets lost in the wallet-count debate: those private credentials aren't all the same kind of thing, and they don't all carry the same weight. Under EUDI there are two flavors of private attestations: A QEAA (Qualified Electronic Attestation of Attributes) is issued by a Qualified Trust Service Provider and is regulated, so it carries legal presumption across the EU. Think of a university attesting a degree. An EAA (Electronic Attestation of Attributes) is the unregulated version: any organization can issue one, and it's trusted on the strength of the issuer's own reputation and the ecosystem it lives in. For example: account status, a loyalty tier, an employee badge, a membership. Same underlying plumbing, different trust levels. And critically, both can live in the same embedded wallet. The user doesn't sort them into buckets, and the wallet app decides what to use depending on what a given interaction needs: a step-up payment might demand the QEAA, logging in might only need the EAA. If we're doing our jobs right as builders, the user stays happily oblivious to the plumbing. They don't know or care whether the credential they just presented was qualified or not, they just know it worked.  P.S: we’re working fast so that you can issue EAAs using our Truvera platform. News soon!

When I’m talking about ID wallets and people hear “web wallet”, they think “custodial”. They think that means that someone else holds your keys. If that were the model, I'd object to it too. But it isn’t. Hear me out: The key that decrypts the contents is provided by the holder. Not by us, or by any hosting organization.  It can be a passkey on a mobile device, or it can be derived from a biometric. We are not using cloud holder key infrastructure, and we are not asking anyone to trust a server with their keys. The vault is encrypted.  The custodian who is hosting the wallet can't access the credentials inside. What this actually does is combine the convenience of a hosted solution with the holder knowing their information is end-to-end encrypted and readable only by them. And to be clear, cloud isn't the answer for everything.  It isn't the right fit for every use case, which is why we also support mobile wallets depending on what's needed.  Credentials that require tight device key binding have a home. This is not "in the cloud instead of on device." It's "the right holder controls the key, wherever the vault lives."