Adding/removing subjects with the "aliases" format

[TakahikoKawasaki]

If a subject with the "aliases" format (RFC 9493 Subject Identifiers for Security Event Tokens, Section 3.2.8. Aliases Identifier Format) is added to a stream using the Add Subject Endpoint (OpenID Shared Signals Framework Specification 1.0, Section 8.1.3.2. Adding a Subject to a Stream) like below,

POST /ssf/subjects:add HTTP/1.1
Host: transmitter.example.com
Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo=

{
  "stream_id": "f67e39a0a4d34d56b3aa1bc4cff0069f",
  "subject": {
    "format": "aliases",
    "identifiers": [
      {
        "format": "email",
        "email": "[email protected]"
      },
      {
        "format": "phone_number",
        "phone_number": "+12065550100"
      },
      {
        "format": "email",
        "email": "[email protected]"
      }
    ]
  }
}

and then a subject with one of the aliases is removed from the stream using the Remove Subject Endpoint like below,

POST /ssf/subjects:remove HTTP/1.1
Host: transmitter.example.com
Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo=

{
  "stream_id": "f67e39a0a4d34d56b3aa1bc4cff0069f",
  "subject": {
    "format": "email",
    "email": "[email protected]"
  }
}

how should the transmitter behave? Should events related to {"format":"email", "email":"[email protected]"} be still delivered via the stream or not?

Likewise, if two Add Subject calls with a simple subject are performed like below,

POST /ssf/subjects:add HTTP/1.1
Host: transmitter.example.com
Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo=

{
  "stream_id": "f67e39a0a4d34d56b3aa1bc4cff0069f",
  "subject": {
    "format": "email",
    "email": "[email protected]"
  }
}

POST /ssf/subjects:add HTTP/1.1
Host: transmitter.example.com
Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo=

{
  "stream_id": "f67e39a0a4d34d56b3aa1bc4cff0069f",
  "subject": {
    "format": "phone_number",
    "phone_number": "+12065550100"
  }
}

and then a Remove Subject request including the added subjects as aliases is made like below,

POST /ssf/subjects:remove HTTP/1.1
Host: transmitter.example.com
Authorization: Bearer eyJ0b2tlbiI6ImV4YW1wbGUifQo=

{
  "stream_id": "f67e39a0a4d34d56b3aa1bc4cff0069f",
  "subject": {
    "format": "aliases",
    "identifiers": [
      {
        "format": "email",
        "email": "[email protected]"
      },
      {
        "format": "phone_number",
        "phone_number": "+12065550100"
      }
    ]
  }
}

how should the transmitter behave? Should events related to the subjects be still delivered via the stream or not?

In other words, the question is whether an Add Subject / Remove Subject request with "format":"aliases" should be treated as a bulk operation on the subject identifiers listed in the "identifiers" array.

[tulshi]

Notes from the call on 8/26/2025:

• (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.