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