# WG Meeting: 2025-12-02
## Agenda
- Interop spec items
- Conformance Testing Update
- Roadmap for 2026
- Google UX Study Highlights

## Attendees
- Atul Tulshibagwale (SGNL)
- Yair Sarig (Omnissa)
- Thomas Darimont (OIDF)
- Mike Kiser (SailPoint)
- John Marchesini (Jamf)
- Kenn chong (RSA)
- Ashish Kedia (Google)
- Tushar Raibhandare (Google)

## Notes
### Update the interop spec (Atul)
- Jen to work on adding the receiver items
- Jen has created a [PR](https://github.com/openid/sharedsignals/pull/302) for updating the spec intro
- Reviewing PR to [Clarify relationship between Tx and Rx](https://github.com/openid/sharedsignals/pull/245)
- Are granular scopes necessary?
- (George) Not sure what is the value of standardizing granular scope
- (George) If we recommend hierarchical scopes, then how does the Tx or Rx behave when they don't understand the scope?
- (Yair) The spec says you are not supposed to honor a scope you don't understand.
- (Jen) We should create a separate issue for the scope discussion, and close this PR
- (George) You need to describe the behavior if you deviate from the RFC6749, or else you need to understand the scopes completely.
- (Atul) What do we gain by standardizing granular scopes?
- (Yair) You're only allowed to do certain actions specified in the scopes. But not sure if is a real use case.
- (Atul) I would propose that we not mention sub-scopes in the interop spec
- (a few people) agree
- (George) We should still have that in a separate PR like Jen suggested

### Roadmap for 2026
- (Atul) I can think of 3 things:
- Certification program
- (Atul) Would be good to have both transmitter and receiver conformance tests if possible.
- Google would be willing to help with receiver tests (to match up with the google RISC transmitters)
- Anyone else intereted in certification should reach out to Atul
- (Thomas) we would need a RISC interop spec to use for that purpose
- Google MAY be involved in this part (benefits by reducing effort on integration with vearious partners)
- Revised specifications
- (Atul) we need to priorize the list of issues (offline), and then review in the weekly meeting.
- that will help clarify what the next version number will look like
- Adoption help
- (Atul) We're seeing some momentum, but it would be good to see more adoption across SaaS companies, etc.
- Atul to publish a whitepaper talking about CAEP and promoting adoption
- (Thomas) Devs ask about libraries that they can use for reference (a lack of central lookup hinders adoption)
- (atul) has put in a request to update OpenID for links / centralization of references (like caep.dev)
- (Yair) Transmitter / receiver are not a library, it's a service
- (Yair) Might have a monthly cadence of "office hours" where they can ask questions, etc.
- (Atul) How do we set that up? Maybe a monthly date where Q&A can take place
- (Mike) The events part is a library, even though the whole transmitter or receiver is not.
- (Thomas) Another option would be a flexible SSF “side-car” service that could run alongside applications and provide SSF transmitter / receiver support that then uses a generic adapter mechanism to interface with a target application.

### Google UX study results
- (Ashish) In order to refine our product, we did a bunch of deep-dive study with about 10-15 customers. Much of that feedback is Google specific, but some of it is applicable to the standards
- (Ashish) Our userbase was people who did not know about SSF at all.
- A lot of users were confused about what is a "signal" and what is an "event". We say "shared signals", but we transmit "events"
- People did not have a way to discover what a Transmitter does. There is no user-friendly documentation. They don't know the product behavior
- Users were also concerned about how new events would be added
- What happens if new signals are onboarded - would it be default enabled? This is something the spec should address.
- Many customers were interested in listening to own signals
- Building a receiver to listen to Google signals!
- They pull events from various Google or non-Google services. SSF would be a great way to unify the implementation
- A low-effort transmitter receiver would help here.
- Another issue was discovery: Which service providers support SSF. Do they talk to each other?
- There was a few variations of this feedback
- (Mike) I've also had similar discovery questions
- (Mike) there's a lot of inexact marketing which incorrectly leads people to believe certain parties support SSF, when they actually don't
- (Tushar) There was also feedback about the work required to support a specific transmitter, e.g. device-id format, subject format, authentication, etc. What happens if I don't have an IdP that is not in Google's list.
- (Ashish) Customers wanted to know how they could express interest that a specific Service Provider should implement SSF.
- (Tushar) For implementors that can also include standardizing subject formats across transmitters and receivers, simplifying auth etc.
- (Ashish) A few decades ago, Google ran a program to encourage service providers to implement OIDC. That resulted in a lot of adoption. So this has been done before.
- (Ashish) There are many open-source projects that implement side-car stuff for other protocols, such as MCP. We should be able to emulate that pattern for SSF.
- (Yair) We should have a directory of who supports SSF.
- (Atul) Does the certification program create a directory of certified implementations?
- (Thomas) [Certified OIDC implementations](https://openid.net/developers/certified-openid-connect-implementations/)
- (Thomas) Similar to [OpenID Certification list](https://openid.net/certification/)
- (Kenn) I'd brought this up earlier to understand how I can make my implementation interoperable.
- (Ashish) We are still conducting more studies, so we will have more updates later.

## Action Items
- Jen to update the PR according to the above discussion
- Everyone please review [PR to update references to final specs](https://github.com/openid/sharedsignals/pull/292)
- Everyone to review issues for prioritization and clarity on what is important (or most important) moving forward
-