# WG Meeting: 2025-08-26
## 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
- 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
### Update on poll
- Getting close, but need a few votes
- https://openid.net/foundation/members/polls/373

### 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

### 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
- (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.~~
-