WG Meeting: 2025-09-23

# WG Meeting: 2025-10-07 ## Agenda - New Note 1 ## Attendees - Sean O'Dell (Disney) - Yair Sarig (Omnissa) - Apoorva Deshpande (Okta) - Vatsal Gupta - Thomas Darimont (OIDF) - Kenn Chong (RSA) - Tushar Raibhandare (Google) - George Fletcher (Independent) ## Notes ### Identity Exchange Issue 297 https://github.com/openid/sharedsignals/issues/297 - (Sean) Interesting on the identifier topics and identifiers being used - (Apoorva) Suggested to use same identities - (Tushar) Maybe add this as part of the interop profile for the latest version use identity xyz and processing the events is tough. If the Rx and Tx are not on the same page it makes it tough - (George) Super murky topic. Carefully determine the identifiers being shared and consistent with each Tx/Rx. Example if the email changes its a nightmare to change that. How do you manage your identifiers in your system then? How could SSF say what to use with out being prescriptive but more guidance and what not to use. Is diving into the world of identifiers a space we want to get into? - (Yair) The administration of this is being done on both sides. The customer is the one administering both of them and is usually what ties them together and is usually an agreement ahead of time. What Type of subject is being used? Complex, aliases, simple? It might be up to the different parties to agree. - (Sean) I like alias format, enterprise deployments are complex. - (Tushar) maybe there could be a way to request the subject types from the Tx or explain this user to me or soemthign that is more standard? Maybe the date that is created? Maybe even source it from the streaming mgmt config setup on what identifier does the Rx use (i.e. email, guid, pairwise, phone number) - (George) using another identifier as a primary identifier in your system leads to a bad experience. Makes correlation hard(er). Identities have lots of aliases that are linked to the identifier to the person for that account. This might be out of scope for the Tx that is a discovery endpoint for the bag of aliases. The discovery of identifiers is useful. - (Sean) This is why a lookup api exists - (Apoorva) As long as we do not make a hardened stance in the speak and do it headless and may not be the intention of this. Co-op would help to resolve this outside of the bounds of this spec. - (Yair) Agrees with George about internal Id's. There is always a mapping element of mapping internal/external ID's. When you are communicating between systems there will always be this need. Agrees with Apoorva and George's standpoints. - (Yair) Maybe a configuration enhancment to have a choice - (Tushar) Agreed that maybe a property is needed to maybe expose what to expect with more identifiers? - (Sean) Maybe add an extension to the stream mgmt setup? - (Tushar) yeah, in the realworld how do we interop with identity exchange? Its great to share data but how do we interop. - (Apoorva) We might have already had an issue opened about this. He is looking for it :) https://github.com/openid/sharedsignals/pull/87 - (George) Would it be possible to optionally allow a receiver to send back a response with a new subject, please send me "this" in addition to enrich the subject. It makes teh processing simpler and less critical so the recevier can figure out what it can. George is re-terating the need for a lookup api :) as a 1.1 extenstion to the spec, but leave it optional to be negatiotiated for processing purposes but not prescriptive. - (Vatsal) Its possible the Tx wil not be able to fulfill the Rx's request. - (Yair) DeviceID is extrememly hard to get right and coordiante on. The Tx may not have the info needed for device, realistcially. The option for the extenstion for the Rx to ask, is nice...but must be optional. - (Vatsal) Are there other attributes where this use case breaks down? - (Yair) Device is harder, email is hard. - (Tushar) Session ID is an example. User problem or session problem. - (Apoorva) Device and User have different logical representations in different systems for the same entity. Sessions are more ephemeral and non shared. - (Sean & Apoorva) We should try to add somethign to the spec where the Tx and Rx should have an agreement on identifiers for co-op or interop. - (Yair) See action item number two. - (Thomas) Privacy concerns with aliases. Is there something to allow the Rx to ask for the remaining aliases with a token with scopes to allow for the ask. - (Apoorva) Might be some relevancy here: https://datatracker.ietf.org/doc/draft-ietf-spice-glue-id/ ### Interop Questions and 411 - (Yair) found that during an integration that iat was sent using seconds vs miliseconds. Ask was to add this to the certification and doublecheck. Was an ask to Thomas - (Thomas) Dev environment has been updated and feel free to use that environment for interop tests. https://demo.certification.openid.net/login.html. Added more error handling etc. ### IETF Proposal https://mailarchive.ietf.org/arch/msg/saag/Wk5IZWR5s5upg2cLPrbDQlZhKWg/ (Apoorva) - This would allow for N SET's to be delivered in a channel. (Sean) - We covered this I thought? (Apoorva) - Now we are calling this multi push. (Apoorva) - Please go read and comment and reply on the thread. The SecEvents WG has closed and we need to show that it is/may be needed. (Yair) - If this is adopted we would need a designation for multi-push once it is RFC accepted. ### RSA Announcement (Kenn) - Funding for SSF in RSA next year. Wanting to work in Partnership. Sean Miller will be there in the interop event. ## Action Items TODO: Add somethign to the spec where the Tx and RX have an agreement on identifiers. TODO: With use cases showing examples on this. Maybe an alaises format would suffice _with_ the Tx and Rx admin approval. Focus on data leakeage with external integrations versus internal and call out pros/cons.