Monthly SIG Meeting (29th): 2025-11-05 - Date: 05 November 2025 - Time: 11:00 - 12:00 UTC in 1 hour 07:00 - 08:00 EDT (UTC-4) 12:00 - 13:00 BST (UTC+1) 13:00 - 14:00 CEST (UTC+2) 14:00 - 15:00 EEST (UTC+3) 16:30 - 17:30 IST (UTC+5:30) 20:00 - 21:00 JST (UTC+9) 21:00 - 22:00 AEST (UTC+10) ## Agenda - Workload Identity / Transaction Tokens - OAuth Identity and Authorization Chaining Across Domains - Shared Signals Framework ## Attendees - Vinod Anandan - Thomas Darimont - Dmitry Telegin - Tom Billiet - Francis Pouatcha - Marek Posolda - Pascal Knüppel - Ingrid Kamga - Takashi Norimatsu - Bertrand Ogen - Arndt Schwenkschuster - Rodrick Awambeng - Kannan ## Notes Notes by Topic ## New Support ### 1. Workload/Agentic Identity Specification: - [Transaction Tokens](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/) Dmitry: working on updating PoC - [OAuth Identity and Authorization Chaining Across Domains](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/) Marek: Working on this in the context of token-exchange. Current limitations in external-to-internal token-exchange. Want to use the "draft-ietf-oauth-identity-chaining" as an alternative solution. See: [Issue #43144 OAuth Identity and Authorization Chaining Across Domains](https://github.com/keycloak/keycloak/issues/43144) Uses [RFC7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants](https://datatracker.ietf.org/doc/html/rfc7523), and builds on private_key_jwt Client authentication. Arndt: @Marek Posolda RFC7523 is receiving a bis update. Would be good to consider the security practices when implementing it. See also [JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rfc7523bis-03) for updates on RFC7523. See also: [JWT Client authentication aligned with the latest OIDC specification](https://www.keycloak.org/2025/04/keycloak-2620-released#_jwt_client_authentication_aligned_with_the_latest_oidc_specification) from Keycloak 26.2.0 release blog post. Dmitry: explains how this "OAuth Identity and Authorization Chaining Across Domains" can be used to effectively generalize the idea of defining trusts between parties, e.g. IdPs. Francis: Can this be used as an alternative to FIPA? Dmitry: Probably not, maybe they can work in conjunction, but the specs serve different purposes. - [OAuth 2.0 Dynamic Client Registration with Trusted Issuer Credentials](https://datatracker.ietf.org/doc/draft-kasselman-oauth-dcr-trusted-issuer-token/) - [OAuth Client Registration on First Use with SPIFFE](https://datatracker.ietf.org/doc/draft-kasselman-oauth-spiffe/) - [OAuth SPIFFE Client Authentication](https://datatracker.ietf.org/doc/draft-schwenkschuster-oauth-spiffe-client-auth/) - [Identity Assertion JWT Authorization Grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) Takashi: It is a promising spec for [enterprise-ready MCP](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/646), we are interested in this spec. We have a plan to implement that based on Marek's team work (RFC 7523 and OAuth Identity and Authorization Chaining Across Domains). - [OAuth Client ID Metadata Document](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) Arndt: This is a way to skip client registration, because the client can provides information about itself. Vinod: Clients probably need to have a backend for this? Arndt: There has to be some backened to provide the client metadata. Arndt: This spec is driven by MCP/AI use-cases, but is more generally applicable. Arndt: Link to [Blogpost on Client Registration by Aaron Parecki on modelcontextprotocol.io](https://blog.modelcontextprotocol.io/posts/client_registration/) - [Kubernetes Service Accounts Federation PR#43967](https://github.com/keycloak/keycloak/pull/43967) Tom Billiet: Stian is already working on improving the Kubernetes support for Federated Client Authentication ### 2. Shared Signals Framework (SSF) Thomas: Sent a first PR for adding initial SSF support to Keycloak. This allows to manage SSF Receivers components within a realm that can be connected with a SSF Transmitter. The SSF Transmitter can send SETs (Security Event Tokens) via HTTP Push to an endpoint exposed by the Keycloak realm. A new SsfEventListener SPI can be used to react on received SSF events from a SET. Next steps: make appointment with Pedro from Keycloak team and discuss TODOs Kannan: Which events are supported here? Thomas: The PR contains event definitions for all events defined in CAEP 1.0, RISC 1.0 and SCIM Profile for Events Draft 16. However, currently only the CAEP session revoked event (for a concrete user) is actually mapped to trigger a user session termination. PR: [#43950 Initial Support for SSF Receiver with Push based Delivery via HTTP](https://github.com/keycloak/keycloak/pull/43950) Issue: [#43614 Add initial support for OpenID Shared Signals Framework](https://github.com/keycloak/keycloak/issues/43614) Specification: - [OpenID Shared Signals Framework Specification 1.0 Final](https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html) - [OpenID Continuous Access Evaluation Profile 1.0 Final](https://openid.net/specs/openid-caep-1_0-final.html) - [OpenID RISC Profile Specification 1.0](https://openid.net/specs/openid-risc-1_0-final.html) PoC: [Shared Signals Framework (Receiver and Transmitter) for Keycloak](https://github.com/identitytailor/keycloak-ssf-support) https://openid.net/specs/openid-caep-1_0.html#name-event-types ### 3. OpenID Federation 1.0 (OIDFED) Costas: No update on this Specification: - [OpenID Federation 1.0 - draft 43](https://openid.net/specs/openid-federation-1_0.html) Discussion: https://github.com/keycloak/keycloak/discussions/31027#discussioncomment-14727205 Epic Issue: [#40509](https://github.com/keycloak/keycloak/issues/40509) Slack: https://cloud-native.slack.com/archives/C096PUDTC3U https://github.com/keycloak/keycloak/issues/42634 https://github.com/keycloak/keycloak/issues/42635 ### 4. Attestation-Based Client Auth Specification: - [OAuth 2.0 Attestation-Based Client Authentication](https://datatracker.ietf.org/doc/draft-ietf-oauth-attestation-based-client-auth/) Ticket: [#39287](https://github.com/keycloak/keycloak/issues/39287) Discussion: [#40413](https://github.com/keycloak/keycloak/discussions/40413) PoC : https://github.com/thomasdarimont/keycloak/tree/poc/client-attestation Slack: Discussion on OAuth Attestation-based client authentication https://cloud-native.slack.com/archives/C05KR0TL4P8/p1758286805101949 10.29.2025 - Clarity on : https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-client-auth/issues/152 - Pascal shared his comments on testing wallets: https://github.com/keycloak/keycloak/issues/42505 - For the funke event adorsys used the LISSI Wallet. We tested many wallets and the LISSI wallet was the closest. - Stefan could have this wallet working: https://github.com/eu-digital-identity-wallet/eudi-app-android-wallet-ui - Please let us all gather the comments in the ticket: https://github.com/keycloak/keycloak/issues/42505 - Pascal suggests to add a proof parameter to make it backward compatible. Changed allready made by Ingrid and adorsys team. Adorsys team will submit a pull request. ### 5. Model Context Protocol (MCP) Specification: - [Base Protocol - Authorization](https://modelcontextprotocol.io/specification/draft/basic/authorization) Pull request active: [#35711](https://github.com/keycloak/keycloak/pull/35711) Nov 5th 2025: Takashi: I reviewed the following PR and the PR was merged. Add CORS support to OIDC dynamic client registration endpoints https://github.com/keycloak/keycloak/pull/43625 The PR resolved the issue that prevent MCP Inspector, MCP project’s official tool for debugging MCP Client/Servers, from working with Keycloak. Support dynamic client registration for MCP Inspector https://github.com/keycloak/keycloak/issues/43514 I confirmed that the MCP Inspector works well with the Keycloak built from the latest main branch. ### 5a. OAuth2 Resource Indicators https://github.com/keycloak/keycloak/pull/35711#issuecomment-3380054867 Takashi: [AWS Cognito supported RFC 8707 resource indicator](https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-cognito-resource-indicators-protection-oauth-2-0-resources/). [AWS AgentCore can utilize this support](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-authentication.html#resource-indicators-cognito). ## Refinement ### 6. OpenID Verifiable Credentials Issuance (OpenID4VCI) Draft Blog post : https://github.com/ADORSYS-GIS/keycloak-web/pull/1 PR need help: https://github.com/keycloak/keycloak/pull/43951 Specification: - [OpenID for Verifiable Credential Issuance 1.0 (FINAL)](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html) - Gap Analysis to Final Spec: https://github.com/keycloak/keycloak/issues/43396 Oct 29th 2025: - Takashi sent an email, will be reviewing the PR: https://github.com/keycloak/keycloak/pull/43215 - pascal is requesting to review/approve the same PR. - This PR is also reviewed by takashi: https://github.com/keycloak/keycloak/pull/43182. All comment were reviewed. - Help requested from SIG Members: https://github.com/keycloak/keycloak/pull/43506 - Marek review waiting for Ingrid address: https://github.com/keycloak/keycloak/pull/43599#discussion_r2450929366 - Pascal has created a ticket to control the parameter KeyAttestationRequired: https://github.com/keycloak/keycloak/issues/43801 ### 6.a Token Status List - Adorsys implement's draft 12 in concordance with the draft 16 of OID4VCI. Adorsys is planing to send a pull request to push the code to main stream! https://github.com/oauth-wg/draft-ietf-oauth-status-list?tab=readme-ov-file#implementations-open-source ### 7. Token Exchange Epic Issue: [External to internal token exchange](https://github.com/keycloak/keycloak/issues/38335) Epic Issue: [Internal to external token exchange](https://github.com/keycloak/keycloak/issues/40704) ### Others ## Recordings https://us06web.zoom.us/rec/share/voaaSKTjj3_s0NYmtZRh0ofFmoBtkdoyXSCKkxEyfAQF3o2Nm8ek-PbrUIuPFPOS.rXFi34RCFxgpE0OH Passcode: Ne9=TkWM