<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body>

openid/sharedsignals event <br>

<br>

Issue opened <br>

Issue Title: Make subject filters a first class entity <br>

https://github.com/openid/sharedsignals/issues/293 <br>

<br>

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.

</body>

</html>