[Openid-specs-risc] Notes from today's call

[Atul Tulshibagwale]

Hi all,
Here are the notes from today's call. They are also stored here
<https://hackmd.io/@oidf-wg-sse/wg-meeting-20250826>.

Atul
WG Meeting: 2025-08-26 <#Agenda>Agenda

   - Update on final poll
   - Interop at Authenticate 2025
   - Add/remove suject using alias and other means (Issue 288
   <https://github.com/openid/sharedsignals/issues/288>)

<#Attendees>Attendees

   - Shayne Miel (Cisco)
   - Atul Tulshibagwale (SGNL)
   - Mike Kiser (Sailpoint)
   - Thomas Darimont (OIDF)
   - John Marchesini (Jamf)
   - Apoorva Deshpande (Okta)
   - Sean O'Dell (Disney)
   - George Fletcher (Practical Identity)

<#Notes>Notes <#Update-on-poll>Update on poll

   - Getting close, but need a few votes
   - https://openid.net/foundation/members/polls/373

<#Interop-at-Authenticate-2025>Interop at Authenticate 2025

   - (Thomas) Updated existing tests (for SSF Transmitters) to the latest
   spec version. They are available via the OIDF Conformance Tests demo
   environment <https://demo.certification.openid.net/index.html>
   - (Thomas) Working on the receiver tests

<#Addremove-subject-using-different-means---alias-vs-email-eg--Issue-288>Add/remove
subject using different means - alias vs. email, e.g. () (Issue 288
<https://github.com/openid/sharedsignals/issues/288>)

   - (Atul) Since aliases represents the same subject for all of the alias
   members, removing using one of those members should remove the whole
   subject.
   - (Shayne) what about adding using a member, but removing using an alias?
   - (Atul) If it is indeed the alias for the same subject, then the
   "remove subject" should remove that subject
   - (Thomas) Is this a dynamic filtering method?
   - (Shayne) If you take that view, then you are not adding or removing
   the subject, you are adding / removing the filter
   - (Atul) If you are referring to the same entity then you are removing
   it as a whole. If you add this alias and remove the email…if the same
   user is represented by a phone number, should we still get events for that
   "subject"?
   - (Shayne) If you have an alias and email filter, you have not modified
   your aliases filter. You would have to add or remove the filter to change
   it.
   - (Atul) - no matter the alias it is the same entity, per the spec.
   Shayne and Thomas is about filtering and adding it to the source of the
   events. If you remove or add to the filter.
   - (Sean) We might not be using simple subjects that often. You're always
   going to be using complex subjects. At a minimum, the complex subject will
   be aliased. This is a choice we have made (in our implementation). So if an
   employee is let go, anything that references that employee (employee ID,
   phone number, etc.) will be impacted.
   - (Shayne) But if you have added an alias with email and phone number,
   and then just removed the phone number, then it should not remove the email.
   - (Sean) I see Shayne's point now. If …
   - (Shayne) To repeat: So you've added a simple subject id format, and
   then you want to remove that simple subject id format.
   - (Shayne) I'm talking specifically about the alias subject format. You
   can add any number of aliases to a stream. Let's say I have 3 simple
   subjects: Sean's email, Sean's phone number and Sean's guid.
   - (Shayne) I've added all three in an alias to the stream, and I only
   remove the phone number, then should we remove the rest of the aliases too
   (i.e. email, guid)
   - (Thomas) But what if the user's phone number has changed? How would
   you do that?
   - (Sean) Having an accurate representation of your data is important.
   The spec should not solve for the data / identity sync use case.
   - (Thomas) If I have alias added with email and phone number, and I get
   events for the old phone number. But now the user changes the phone number,
   do we need to add the alias with the new phone number?
   - (Atul) The spec should have a position on what does "Add Subject mean?"
   - (Shayne) The receiver should be a source of truth for who the identity
   is
   - (Mike) In the context of the stream. The receiver specifies the
   description of the subject in the stream
   - (Atul) Say a transmitter is capable of sending events using email as
   the subject, but a receiver specifies the user using an employee id, then
   should the transmitter send events with the email?
   - (Mike) The transmitter should send events using a complex subject that
   lists the email and the employee id, so that the receiver knows what the
   event is about.
   - (George) Are there any leakage issues with giving the receiver more
   than it specified in the "add subject"
   - (George) SSF should be about signals, the entity model should not
   matter. If a receiver wants a phone number to be a subject, and not
   anything else, then I worry that we will create too much dependency on the
   underlying entity model of the other participant.
   - (Shayne) I agree we should not expect participants to understand each
   others' entity model
   - (George) If specific CAEP events are about specific identities, then
   it might make sense in that context
   - (Mike) I need to think through the use of aliases in the context of
   SSF.
   - (George) What if the receiver cares about is say, "families". But the
   transmitter cares about individuals. The transmitter sends events about the
   individual.
   - (George) We can't require the transmitters and receivers to have
   sync-ed entity models.
   - (Thomas) Isn't that one rationale why this should be generic
   (understand subjects as filters, rather than the underlying entities).
   - (Shayne) The remove is a "negation" or exclusion filter.
   - (Mike) This can get messy
   - (Shayne) which takes precedent? The addition or the removal?
   - (Mike) We can note our thoughts in the issue.

<#Action-Items>Action Items

   - (Sean) - dropping notes here…I dont think there should be a
   correlation of subject type and subject/stream mgmt (companies are complex)
   - (Atul) Copy the notes to the issue.


--

 Atul Tulshibagwale

 CTO

  <https://www.linkedin.com/in/tulshi/> <atul at sgnl.ai>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250826/3b6189d4/attachment-0001.htm>