[Openid-specs-risc] openid/sharedsignals: New Issue opened

[github at oidf.org]

openid/sharedsignals event

Issue opened
Issue Title: Make subject filters a first class entity
https://github.com/openid/sharedsignals/issues/293

The SSF spec made a good choice relying on the Subject Identifiers specification to identify the subjects being referred to in the events flowing over the stream. However, that same specification is _not_ a good choice as a way for the Receiver to tell the Transmitter what subjects it is interested in. Instead, the `add_subject` endpoint should take some kind of "subject filter" that allows the Receiver to say, "I want events pertaining to subjects that _look like this_." Some evidence for this claim: - We have seen a lot of requests to be able to say "Give me all subjects whose emails match *@company.com". - The logic around what it means to add and remove an Alias or Complex subject format via the `add_subject` and `remove_subject` endpoints is very confusing. - We had to implement a fairly confusing "default_subjects" method so that some streams can send all subjects. In fact, many implementations completely skip the `add_subject` endpoint because it doesn't work as smoothly as it should. Ideally, the Receiver should be able to add a subject filter that matches all subjects instead of having different default behaviors. To address this problem, we should change the spec so that `add_subject` and `remove_subject` take a SubjectFilter instead of Subject as an argument. The SubjectFilter language should be flexible enough to allow for wildcard matching, perhaps even regex matching.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20250916/79c761d4/attachment-0001.htm>