# WG Meeting: 2024-03-05 https://hackmd.io/@oidf-wg-sse/wg-meeting-20240305/edit ## Agenda - De-coupling SSF from CAEP / RISC - [Issue 140](https://github.com/openid/sharedsignals/issues/140) - Allow Receiver to supply public key - [Issue 141](https://github.com/openid/sharedsignals/issues/141) - Mark Stream Configuration fields as optional/required ## Attendees - Sean O'Dell (Disney) - Dean H Saxe (Amazon) - Steve Venema (ForgeRock?) - Jen Schreiber - Stan Bounev - Apoorva Deshpande ## Notes ### De-coupling SSF from CAEP / RISC - (Sean) Starting to push SSF at Disney. Lots of interest in privacy events. FAPI needs fraud signals, not identity signals. - (Dean) SSF will be most successful internally in large companies. There will be some sharing externally. We need some specific schema per industry. Don't want to go too far and have a bunch of schemas. But we want to expand people's mindds about utility. - (Apoorva) - (Sean) SSO has needs to send onboarding info. - (Apoorva) Sharing OAuth signals? - (Jen) Who is onboarding to who? Could be beneficial with dynamic client registration. If the RP doesn't want to update OP when rotating keys, could use SSF - (Steve) Onboarding not just an SSO problem. Federation requires pre-established trust relationship. - (Jen) Biggest gap is in SAML onboarding. - (Shayne) We have a messaging problem. When people think of shared signals, they think CAEP. - (Stan) I don't know if we need to do anything on the technical side - (Dean) It is a marketing problem. We've bound them together. But if we start giving talks about SSF by itself. - (Sean) Gave a talk at Identiverse 2023 about different kinds of events flowing through Shared Signals. Use cases will set you free. - (Apoorva) On the other hand, do we need some kind of base set of signals that can be sent? - (Shayne) Can the verification and status change events do that? - (Stan) We are in this situation because we _always_ use CAEP as our examples. Spend more time talking about the framework. - (Sean) CAEP is fraud-ish. Can we find use cases that drive the need for other event types? - (Steve) As we come up with new events, do we want to add them to CAEP/RISC? - (Dean) We want to be sure we are defining the events well enough. Need to manage the risk. Need clear event definitions. - (Shayne) Why do we need to define these event types? Can't I just publish one on Github? - (Sean) We want there to be a review board and some standardization. - (Shayne) What about OCSF? - (Dean) If you tie yourself to OCSF, you are tied to their processes. IANA has a process for adding things like these events. - (Steve) The value of external event definition registries are that they become a forum for many different people to comment on the event. - (Dean) Passkeys are relevant here because you have 3rd party passkey providers. They all want to allow you to migrate them. We want to send an event when these Passkeys are moved. Perhaps we could create an ecosystem around passkey management. - (Apoorva) Same argument when you change the password for a vault - (Dean) Passkeys may be special because they have to live within a passkey management system. - (Sean) Guiding principles about how to present SSF - (Shayne) +1 - (Jen) The spec could be a good place for explaining the difference between SSF and CAEP in a non-normative place - (Sean) You can make SSF events prescriptive or informative. - (Dean) These signals are already very informative. Have to view the event through the receivers eyes, unless there is some prior agreement about what to do with the events. - (Apoorva) One of our partners wanted a very prescriptive event, so we created a new event type - (Shayne) We could create a whole new set of prescriptive events - (Apoorva) Do we need to acknowledge these prescriptive events - (Dean) The receiver could send back an informative event. We need prescriptive events for dealing with death so that people can set up what they want to happen to their data when they pass. ### [Issue 142](https://github.com/openid/sharedsignals/pull/142) - (Apoorva) Please provide feedback ### For next time - (Steve) IIW coming up. Do we want to get together there? Mountain View. - (Dean) OIDF meeting at Google Campus. Week of April 15th ## Action Items