Specify expected default behavior of streams with no subjects

[FragLegs]

On a recent WG call, we had a long discussion about the expected behavior of a stream that has not had any subjects added yet. The conclusion was that, by default, a Transmitter should not send any events until a matching subject has been added to the stream. We need to update the spec to indicate this default behavior.

[ysarig1]

Unless there is an explicit way to override the default when the stream is created, the "The conclusion was that, by default, a Transmitter should not send any events until a matching subject has been added to the stream" conclusion is very problematic for enterprise use cases when there may be tens or hundreds of thousands of users and the expectation is that an enterprise admin make the decision for all users.

[FragLegs]

If a Receiver wishes to get events for all/many subjects, it can exploit the wildcard-like nature of Complex subjects. For instance, if the Receiver adds a Complex subject that specifies a tenant ID and nothing else, then any event for any user on that tenant will be added to the stream.

{
  "format": "complex",
  "tenant: {
    "format": "opaque",
    "id": "1234567"
  }
}

To take that ability even further, if the Receiver adds a Complex subject with no additional claims, then any event for any subject would be added to the stream (assuming the Transmitter approves).

{
  "format": "complex"
}

[appsdesh]

If a Receiver wishes to get events for all/many subjects, it can exploit the wildcard-like nature of Complex subjects. For instance, if the Receiver adds a Complex subject that specifies a tenant ID and nothing else, then any event for any user on that tenant will be added to the stream.

{
  "format": "complex",
  "tenant: {
    "format": "opaque",
    "id": "1234567"
  }
}

To take that ability even further, if the Receiver adds a Complex subject with no additional claims, then any event for any subject would be added to the stream (assuming the Transmitter approves).

{
  "format": "complex"
}

@FragLegs the above approach will take a dependency on an OPTIONAL add subjects API, in turn making it mandatory for large scale implementations.

Another alternative could be to add an OPTIONAL subject claim in create + update stream request, similar to events_requested which is used to filter out which events are needed by the receiver.

This approach will provide flexible way to bootstrap streams with the default subjects.

Potentially, we could deprecate add/remove subjects APIs with this approach

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

{
  "delivery": {
    "method": "urn:ietf:rfc:8935",
    "endpoint_url": "https://receiver.example.com/events"
  },
  "events_requested": [
    "urn:example:secevent:events:type_2",
    "urn:example:secevent:events:type_3",
    "urn:example:secevent:events:type_4"
  ],
    "subject": {
    "format": "email",
    "email": "example.user@example.com"
  },
  "description" : "Stream for Receiver A using events type_2, type_3, type_4"
}

[FragLegs]

Conclusion from 5/14/24 WG call - Add a field in the configuration metadata that indicates whether the Transmitter is an "all subjects by default" or "no subjects by default" transmitter. If not provided, it will default to "no subjects". We will add examples of this in the spec.