[Openid-aiim] Meeting notes

chris phillips cjphillips at gmail.com
Fri Sep 26 17:49:55 UTC 2025


Thanks everyone for the time yesterday..

Presentation is attached and I also recorded another take after the call if
you want the demo:
 https://youtu.be/qKm1hDVafMs

Some great questions came in on slack and are below to coalesce them here.

Comments and feedback on or off list are always welcome..

Thanks!

Chris.


--from OIDF slack thread: #cg-aiim channel:
https://oidf.slack.com/archives/C091VMU2R3P/p1758819816498409

Sarah Cecchetti  Yesterday at 1:03 PM
<https://oidf.slack.com/archives/C091VMU2R3P/p1758819816498409>
Sorry, I had to drop for another meeting before Chris was done taking
questions. Is the intent of the OIDC integration to prevent like “MCP
phishing” where an attacker stands up a malicious MCP server that looks
like a valid one? Are there other attacks that this would protect against?
Has anyone put together a comprehensive list of MCP threats we could work
backwards from?
4 replies
------------------------------
chris phillips  Yesterday at 2:24 PM
<https://oidf.slack.com/archives/C091VMU2R3P/p1758824645902379?thread_ts=1758819816.498409&cid=C091VMU2R3P>
@Sarah Cecchetti <https://oidf.slack.com/team/U094FEXPP42>, yes, those
classes of risks can be diminished or mitigated. Employing a trust model
means the client does some validation and the trust mark issuer does their
due diligence. Today, MCP clients can connect promiscuously or with low
verification of just plumbing them in and using them. To me this is why a
lot of patterns have 1 MCP (ex: Metamcp
<https://github.com/metatool-ai/metamcp>) and just consider it a win to
reduce  configuration effort.
Trusted subsystem problems proliferate quickly. In a proxy model you get
whatever was configured downstream and the API keys for that. e.g. github
MCP and using a regular access token(all your repos) vs a personal access
token(just repo xyz).  Who should connect to that MCP with your  tokens as
'you? and when?  Lots of aspects to think about..
2 files
Download all

Jeff Lombardo (AWS)  Yesterday at 6:34 PM
<https://oidf.slack.com/archives/C091VMU2R3P/p1758839650247809?thread_ts=1758819816.498409&cid=C091VMU2R3P>
nice presentation @chris phillips <https://oidf.slack.com/team/U08S5FND5GU>,
I still have questions:

   -  on the second diagram.... where is the client? From my poor and
   recent understanding of
   https://openid.net/specs/openid-federation-1_0.html, a FedMgr Client is
   not defined as an actor. Is there another profiling of OpenID Federation  I
   need to look at?
   - In your second diagram, the traffic goes through the FedMgr gateway,
   this means that the FedMgr gateway needs to be a MCP server by itself right?
   - But in your demo it was unclear if got only the credential from the
   FedMGR Gateway or all the traffic went through it...
   - If the traffic goes within the FedMgr Gateway what happens behind it?
   is the Token received is pass forward to the real MCP Server?
      - If so what would prevent one from using the token directly with the
      backend MCP server?
   - Finally is there a longer demo somewhere. I am very interested into
   understand how one MCP Server will acquire its trust marking from OpenID
   Federation

(edited)
[image: openid.net]openid.net
OpenID Federation 1.0 - draft 43
<https://openid.net/specs/openid-federation-1_0.html>
A federation can be expressed as an agreement between parties that trust
each other.
In bilateral federations, direct trust can be established between
two organizations belonging to the same federation.
In a multilateral federation, bilateral agreements might not be practical,
in which case, trust can be mediated by a third party.
Show more
chris phillips  Today at 12:16 AM
<https://oidf.slack.com/archives/C091VMU2R3P/p1758860182462829?thread_ts=1758819816.498409&cid=C091VMU2R3P>
Thanks @Jeff Lombardo (AWS) <https://oidf.slack.com/team/U08NSUHB1L1>..
great questions .. some thoughts below:

   -  on the second diagram.... where is the client? From my poor and
   recent understanding of
   https://openid.net/specs/openid-federation-1_0.html, a FedMgr Client is
   not defined as an actor. Is there another profiling of OpenID Federation  I
   need to look at?

Chris: Right now, not that I know of. I think a handful are working on
this. AFAIK, i'm the only one active in the AI specific space. Other
interop events have happened, and an R&E presentation day
<https://wiki.geant.org/spaces/G52W5/pages/1139736659/Cycle+10+final+Demo>
(with
slides
<https://wiki.geant.org/spaces/G52W5/pages/1049624681/Cycle+10+half-time+Demo>)
today had some other updates on their progress. No profiles, but technology
and large scale testing

   - In your second diagram, the traffic goes through the FedMgr gateway,
   this means that the FedMgr gateway needs to be a MCP server by itself right?

Chris: It is not an MCP but a 'client'. In my case, a web app at
localhost:3001 that is registered with github as an OAuth App. In turn it
mints another token with the trustmark.  I chose this route rather than a
CLI client as it was a bit easier than to docker compose an OIDC OP.  In
the demo I take the reminted token from the gui and cut and paste that into
VSCode so it can be used when I communicate with the MCP server on
localhost:4001.

   - But in your demo it was unclear if got only the credential from the
   FedMGR Gateway or all the traffic went through it...

Chris: great point, The Gitlab JWT is not being passed but the newly
re-minted one with the trust mark because github can't issue it at this
time. There could be a point in time in the future when platforms could do
this but not right now.  As well, the audience is http://localhost:3001 if
i recall correctly.

   - If the traffic goes within the FedMgr Gateway what happens behind it?
   is the Token received is pass forward to the real MCP Server?

Chris: the JWT is re-minted, not passed forward.

   - If so what would prevent one from using the token directly with the
   backend MCP server?

Chris: At first I believed(wrongly) i could just use a re-minted token with
the trustmark everywhere 'as is' (after the trust marking) BUT the OAuth2
audience requirements preclude that for security reasons. Replaying the
token to the wrong endpoint should result in an error for that alone BUT it
could also be  construed as revealing a private token to another party who
in turn could replay it against the proper audience, at least until it
expired.
This is why being able to determine trust before connection is important
IMO. Good token hygiene and duty of care handling them matter.

   - Finally is there a longer demo somewhere. I am very interested into
   understand how one MCP Server will acquire its trust marking from OpenID
   Federation

Chris: my longer demo was less polished than this one and does not dig into
the enrolment and registration processes and is less focused than this one.
In all cases, I have manually set the CA and entity registration as a POC
for a docker-compose.  It was manually done thus explicit registration.
Dynamically and automatically 'trusting' and issuing a trust mark(s) has
it's place to match the appropriate risks in doing that but I shy away from
that as 'good practice' for now as trust to me means doing more than just
registering something.
For who's doing what, check:
https://openid.net/developers/openid-federation-implementations/ and then
see what they're doing is what I'm keeping an eye on for inspiration on
what's needed.
I've been working on instantiating a bootstrap 'admin' federation that will
have an explicit admin designation and then when you sign into it, you can
start doing the interesting things.  This way, the tooling uses its own
techniques to operate and realizes a use case of a personal federation.
There are so many ways things can be done but getting a base global admin
bootstrapped is key to unlocking the other elements.Great questions and
help identify areas I need to elaborate more or clarify.
I recorded the presentation again <https://youtu.be/qKm1hDVafMs> (after the
call!) which has a bit more on the demo side there (but nothing on
registration)
(edited)
[image: openid.net]openid.net
OpenID Federation 1.0 - draft 43
<https://openid.net/specs/openid-federation-1_0.html>
A federation can be expressed as an agreement between parties that trust
each other.
In bilateral federations, direct trust can be established between
two organizations belonging to the same federation.
In a multilateral federation, bilateral agreements might not be practical,
in which case, trust can be mediated by a third party.
Show more
[image: OpenID Foundation - Helping people assert their identity wherever
they choose]OpenID Foundation - Helping people assert their identity
wherever they choose
OpenID Federation Implementations - OpenID Foundation
<https://openid.net/developers/openid-federation-implementations/>
OpenID Federation Implementations These OpenID Federation implementations
are listed by programming language, followed by a list of products C#
spid-cie-oidc-aspnetcoreSPID/CIE OIDC Federation SDK for AspNetCoreLicense:
Apache 2.0 Go go-oidfedGo implementation of OpenID Federation – Work in
ProgressLicense: MIT Java Nimbus OAuth 2.0 SDK with OpenID Connect
extensionsOpenID Federation core functionality, including trust chain
validation and metadata
Sep 5th, 2024 (17 kB)
https://openid.net/developers/openid-federation-implementations/
<https://openid.net/developers/openid-federation-implementations/>
Jeff Lombardo (AWS)  Today at 8:51 AM
<https://oidf.slack.com/archives/C091VMU2R3P/p1758891064839609?thread_ts=1758819816.498409&cid=C091VMU2R3P>
thanks for all the details, will look into your recording!
--end--



___________________________________________________________________________________________

chris at chrisphillips.ca | https://www.linkedin.com/in/chris-phillips-cidpro/


On Thu, Sep 25, 2025 at 9:32 PM Atul Tulshibagwale via Openid-aiim <
openid-aiim at lists.openid.net> wrote:

> Hi all,
> The notes from today's AIIM CG call are saved here:
> https://github.com/openid/cg-ai-identity-management/wiki/20250925
>
> Thanks very much to Chris Phillips
> <https://www.linkedin.com/in/chris-phillips-cidpro/>, Tobin South
> <https://www.linkedin.com/in/tobinsouth/> and Nick Steele
> <https://www.linkedin.com/in/nickelsteele/> for their presentations
> today. Presenters, please share the decks for your presentations to this
> mailing list.
>
> I'm copying them below for convenience.
>
> Atul
>
> --
>
>  Atul Tulshibagwale
>
>  CTO
>
>   <https://www.linkedin.com/in/tulshi/> <atul at sgnl.ai>
>
> ---
> Sep 25, 2025Attendees
>
> Name
>
> Affiliation
>
> Participation Agreement signed?
>
> Tobin South
>
> WorkOS & Stanford
>
> Yes
>
> Atul Tulshibagwale
>
> SGNL
>
> Yes
>
> Rick Burta
>
> Okta
>
> Yes
>
> Subramanya N
>
> Independent
>
> yes
>
> Eleanor Meritt
>
> Independent
>
> yes
>
> Dan Moore
>
> FusionAuth
>
> Yes
>
> Tal Skverer
>
> Astrix Security
>
> Yes
>
> Vaibhav Narula
>
> Independent
>
> Yes
>
> Asanka Samaraweera
>
> Independent
>
> Yes
>
> Ricky Padilla
>
> 1Password
>
> Yes
>
> Nick Steele
>
> 1Password
>
> Yes
>
> Paul Templeman
>
> Independent
>
> Yes
>
> Paul Lanzi
>
> IDenovate
>
> Yes
>
> Sarah Cecchetti
>
> Beyond Identity
>
> yes
>
> Bertrand Carlier
>
> Wavestone
>
> Almost there…
>
> Andrew Moran
>
> Independent
>
> Yes. First time!
>
> Stan Bounev
>
> Blue Label Labs
>
> Yes
>
> Lukasz Jaromin
>
> Raidiam
>
> Yes
>
> Adwait Shinganwade
>
> Independent
>
> Yes
>
> Victor Lu
>
> independent
>
> yes
>
> Tom jones
>
> ind
>
> yes
>
>
>
>
>
>
> Aldo Pietropaolo
>
> Sophos Advisor
>
> Yes
>
> Max Crone
>
> 1Password
>
> Yes
>
> Anuradha Karunarathna
>
> WSO2
>
> Yes
> Agenda
>
>    -
>
>    Tobin’s weekly updates (5 minutes)
>    -
>
>    Chris Phillips on OpenID Federation and MCP (20 minutes)
>    -
>
>    Tobin: MCP Dev Summit preview: Agent Auth (20 minutes)
>    -
>
>    Nick Steele <nick.steele at 1password.com>: Agent Payment Protocol Intro
>    (10 mins) - Slides
>    <https://docs.google.com/presentation/d/1PU0pl2TI-MzZfMthlMcRXGPEA7EYQJK15nwuS7bIa-Q/edit?usp=sharing>
>
> NotesChris Phillips’ Presentation
>
>    -
>
>    Chris Phillips’ presentation: Improving AI Identity, Trust and
>    Provenance using OpenID Federation
>    -
>
>    Background in federated identity in the research and education sector
>    -
>
>    Challenges:
>    -
>
>       Shadow MCP
>       -
>
>       “Rug pull problem”
>       -
>
>       (many others in the slides)
>       -
>
>    Multi-lateral federation is an opportunity for the AI space.
>    -
>
>       Take things that are happening in past protocols and bring them to
>       AI
>       -
>
>    “Federation guides who you can trust. OAuth / OIDC still decides what
>    you can do.”
>    -
>
>    OpenID Federation is great at trust, but you still need a registry of
>    “what you can trust”
>    -
>
>    OpenID Federation is a trust fabric:
>    -
>
>       A Trust Anchor (e.g. CA) signs an “Entity Statement”
>       -
>
>       Each participant OP/ RP/ RS exposes an Entity Configuration
>       -
>
>    Just like a browser flags untrusted certifications, a missing or
>    untrusted attestation can flag untrustworthy participants in MCP
>    -
>
>    It’s ready for primetime:
>    -
>
>       Italy’s Public Digital Identity System (SPID)
>       -
>
>       OpenID Federation pilot takes it to 10k entities to enable SAML2
>       federation
>       -
>
>    Candidate use cases:
>    -
>
>       Defense against rogue MCP
>       -
>
>       SBOM for MCP servers
>       -
>
>       Shard usage based on user’s role (authorization)
>       -
>
>       Safe personal use of MCP
>       -
>
>       Readiness for PQC
>       -
>
>    Demo of gateway MCP
>    -
>
>    Critical to secure AI
>    -
>
>    “Meta MCP”
>    -
>
>    Questions / comments:
>    -
>
>       (Lukasz Jaromin) Connections in MCP do not require prior
>       registration, so having trust marks would be good
>       -
>
>       (Chris) Just like you can connect anonymously to a website, and
>       then be challenged for authentication, you should be able to do something
>       similar in MCP
>       -
>
>       (Atul) How does this tie into threat modeling?
>       -
>
>          (Chris) This is going to be important.
>          -
>
>          The process of issuing a trust mark will be tied to threat
>          modeling
>          -
>
>          I’ve done a Safe MCP analysis
>          -
>
>       (Paul Templeman) How do you see dynamic / unstructured ecosystems
>       play into this
>       -
>
>          (Chris) Think of an MCP Server that has “get customer
>          information” as a tool. Who is the user that is asking the question?
>          -
>
>          MCPs can be in multiple “venn diagrams” (trust domains?) Which
>          one takes priority?
>          -
>
>       (Tom Jones) i have posted an AI threat model - OIDC does not fit
>       that - does anyone have a threat model for using this trust structure with
>       AI?
>       https://github.com/w3c-cg/threat-modeling/blob/main/models/ai-in-browser.md
>
> Tobin’s Presentation
>
>    -
>
>    We are publishing the “future of agent identity” white paper in the
>    OIDF soon.
>    -
>
>    There’s an MCP Dev Summit next week.
>    -
>
>    Tools can be highly dynamic - based on user roles and permissions
>    -
>
>       Creates a bunch of security risks
>       -
>
>    Cross-app authorization is an interesting proposal from Aaron
>    -
>
>    Background agents are cool - you just get a PR from the agent.
>    -
>
>    Hard to define the full scope of permissions in order for the agent to
>    be effective
>    -
>
>    Attenuation of permissions is also interesting (especially in
>    transitive use cases)
>    -
>
>    What does MCP look like in a world of fully autonomous agents?
>    -
>
>    What are we missing as far as authorization in AI? Love to get
>    opinions on this:
>
> Questions:
>
>    -
>
>    (Tom Jones) If you are talking about an AI, you need rich policy. We
>    don’t have anyone working on that as far as I know.
>    -
>
>    (Nick) ID-JAG (cross-app access) was meant to deal with the multiple
>    trust boundary issue. If I have a central auth server, it solves some
>    issues.
>    -
>
>       (Tobin) Going to talk about agentic payments stuff
>       -
>
>       ID-JAGs work as long as you are using the same IdP. If you are
>       delegating to another organizations’ agent, then it might not work
>       -
>
>       (Nick) We had multiple IdPs / gateways in Cisco, but being able to
>       have a central authority across trust boundaries is better
>       -
>
>    (Chris) It takes multiple ingredients to make a good cake. You’re
>    going to have different contexts for different regions.
>    -
>
>    It’s such a high step function today to do everything, that it needs
>    to be brain dead easy to do some of the basic stuff first.
>    -
>
>    (Atul) What’s the distinction between background agents and async
>    agents
>    -
>
>       (Tobin) You expect background agents to be able to prompt
>       -
>
>    (Lukasz) Everything on your last slide makes sense. Couple of options
>    on that list make the multi-domain thing work. But there is a question of
>    adoption and how to make it tangible.
>
> Nick’s Presentation on AP2
>
>    -
>
>    AP2 works on top of MCP and A2A, and facilitates payment transactions
>    -
>
>    “Intent mandates” with an attestable chain of events
>    -
>
>    “Cart mandate” that reflects the intent.
>
> --
> Openid-aiim mailing list
> Openid-aiim at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-aiim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-aiim/attachments/20250926/35bbd77f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Adiuco-CP-OpenIDFedAndMCP.pdf
Type: application/pdf
Size: 1208329 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-aiim/attachments/20250926/35bbd77f/attachment-0001.pdf>


More information about the Openid-aiim mailing list