-
Notifications
You must be signed in to change notification settings - Fork 7
20250731 ‐ Meeting notes: July 31, 2025
- [1 minute] Note Well and Note Really Well
- [5 minutes] Tobin’s Regular Section: What happened in AI / agent IAM this week
- [10 minutes] Atul & Gail’s AI Use Cases workshopping [slide]
- [15 minutes] (Nick Steele) AuthZ/AuthN ideas about MCP (Discussions around defining a credential store in MCP + using OID4VP & SIOP to manage access)
| Name | Affiliation | Participation Agreement signed? |
|---|---|---|
| Atul Tulshibagwale | SGNL | Yes |
| Jeff Lombardo | AWS | Absent |
| Tobin South | WorkOS & Stanford | Yes |
| Rick Burta | Okta | Yes |
| Alex Keisner | Vouched | Yes |
| Sarah Cecchetti | Independent | Yes |
| Paul Templeman | Independent | Yes |
| Stan Bounev | Blue Label Labs | Yes |
| Eve Maler | Venn Factory | Yes |
| Nick Dawson | Self | Yes |
| Cleydson Andrade | Independent | Yes |
| Max Gerber | Stytch | Yes |
| Eleanor Meritt | Independent | Yes |
| Sean Connolly | Roche | Yes |
| Flemming Andreasen | Cisco | Yes |
| Simon Russell | Prefactor | Yes |
| Dan Moore | FusionAuth | Yes |
| Vladi Berger | PlainID | Yes |
| Victor Lu | Independent | Yes |
| Tom jones | ind | yes |
| George Fletcher | Practical Identity LLC | Yes |
| Nick Steele | 1Password | Yes |
| Jay Huang | Visa | Yes |
Tobin - what’s going on in agents
Discussions are going on in the MCP repo in github and discord: https://discord.gg/Fv7NquND
Atul
Discussion initiated by Gail - how should we categorize our discussions? Are there specific areas we want to focus and not focus on? [slide]
George - questions of cross-domain boundaries, privacy, transitive trust, transitive authorization. “Am I a single agent using MCP capabilities to do something? What are those things I’m trying to do?” Vs “I’m a multi-agent environment where identifiers become much more complicated” Maybe all of these apply in two different dimensions - single domain, and multi-domain. That might enable us to break down the problems.
George - separating single-domain, single agent concerns from cross-domain, multi-agent stuff will help us make more progress.
Sarah: Whats the difference between areas of work and use cases?
Use cases: Problem drive
Areas of work: solution-driven
Victor - this group should focus on enterprise. Other groups are focusing on b2c. MCP and A2A are more enterprise, right? Agents are peer to peer - decentralized.
Atul - not necessarily. These standards apply to consumer technology as well, and OpenID Foundation is focused on the privacy risks in the consumer space. OpenID has typically focused on distributed identity, so this is a place where we are experienced.
Tobin - what do we need to take MCP to enterprise is a good question, e.g. people building OAuth flows for MCP. We don’t hear a lot about SAML integration. How do we make sure OIDC works well. We’ve touched upon Aaron’s cross-domain work.
Sarah: We are focusing on security and trust, which are consumer problems. We should not take consumer out of scope.
Nick: Agree that consumer is important there’s a baseline level of work we need to do before we get into the enterprise side of the house. That’s table stakes for what we’re doing on the enterprise side of the house. User experience is going to be different between consumer and enterprise, but they will both involve permissions, attestations, and data sharing. We need to provide pii and contextual data in a way that’s trusted.
Sarah - User experience is a big part of security which is overlooked and is a cause of many scams. This CG can focus on that.
Paul: With the use cases and areas of work are we differentiating between AI within an enterprise (internal concerns) vs inter-organizational concerns? At the ecosystem level, the OIDF Ecosystem Support CG may be worth liaisoning with at the ecosystem level.
Atul - Does this align with George’s earlier statement of separating single domain / agent and multi domain / agent?
Paul - Yes.
Stan: We should add the use case of authorization across LLMs. I have an agent, and I want to have as a first step a request, and use the output of that as the input to another LLM. The second one will have to inherit permissions from the original.
Questions on the use-cases diagram
- What is an agent?
Nick - AuthZ/AuthN ideas about MCP
Two topics - secure credential store for AI clients to use. At some point there will be consolidation around what “client” looks like for LLMs. We want security guarantees around credentials so we have a baseline of security. There is currently little guidance around how MPC clients should be managing credentials and tokens. MCP guidance merely says to follow OAuth best practices, but there is no way to verify that the client black box is doing things securely.
Tokens and keys should be stored and managed by the client and instantiated will each new client. However, sometimes the credentials are stored at the host and reused in host config files, so if one client is compromised, all clients are compromised. Could there be an intermediate service or application that hosts could use to manage credentials.
Sarah - does this work with SPIFFE?
This is the same architecture as SPIFFE/SPIRE. The IdP is on one side, the TPM is closer to the user. If it’s running on the user’s device, we can tie it to secure processes on a specific device.
Atul - Use of long-term tokens should be avoided. Would prefer to derive the token from the credential manager for a short-lived session token.
Nick - Yes. My ideal flow in this model is to sign with tokens, not release tokens. We store the refresh token, but when it comes to access tokens, there will be a policy saying that there’s a time to live of 30 seconds or something. That can be configured. We can present some sort of attestation.
George - would the manager also manage the OIDC experience? Who owns the user experience for these flows? Would the host do the UX? We need to figure out where that piece lives.
Nick - When a host goes to instantiate a client, the manager will get the credentials, and then the client will be able to access those. The credential manager will step in and handle that flow of authenticating the user.
George - in that space, we need to handle the step up use cases. It’s not just the initial authentication.
Nick - Yes, credential managers will manage that.
Sarah - That flow might need to go outside the credential manager, to wherever policies are stored and that policy engine may have to initiate a flow where it can tell the manager/host exactly what information it needs in order to grant permissions.
Atul - it’s very difficult for users to determine between a real and fake UI. How do users know it’s trusted?
Sarah - So is FIDO talking about putting something in the “chrome” of the browser? Which is a trusted UI?
Nick - next step is to draft an MCP standard enhancement proposal. What would a credential manager look like? I’ll be presenting this at MCP developer days in New York in August.
Nick - the stock version of OAuth adds complexity and treats agents like people. That might not work in an enterprise context. We could do OIDC verifiable presentation flow and hand back an OAuth token ID after the OAuth flow, but we could also have a self-issued OpenID Provider. The resource server could define another provider they trust. Similar to an authorization grant flow. This would be more usable in cases where you have “consumer providers” - more players than just enterprise IdPs.
George - OpenID provider is functionally bound to the client in a self-issued context. It’s running on my personal device and issuing tokens on my behalf. Does that fit on top of OpenID for VP? The idea that an MCP server would trust something pushed from an individual device is interesting, but we’d have to have a well-defined governance process. Probably more viable in enterprise than consumer.
Nick - Agreed. It’s cleaner in an enterprise use case. I’ll reach out to some OIDC folks to vet the idea.
Tom - Every agent that’s ever involved will know who I am? You can’t pass these things through. You have to regenerate the request every time.
Nick - We’re just talking about presenting permissions tokens, not literal PII.
George - the privacy issues of identifiers flowing across trust domains is interesting. Agents may hide or transform it in some way that could create compliance issues. These are high level issues that haven’t been resolved and need to be considered as we go through the process. But if we regenerate the request at every trust domain, there has to be a way for domains to understand what is and isn’t allowed. As a relying party, there are real reasons why I might want to know why someone delegated and who delegated an agent to talk to me. There are real privacy implications, but we need to evaluate the intent of specific uses and figure out where the balance is. We can’t ignore all attributes.