Security use cases

[yolocs]

/area security

Problem
Parent: #1449
We want to come up with and agree on valid security use cases. Only based on that can we properly define security policy.

Persona:
Consumer/Producer/Integrator

Exit Criteria
Document (as checked in markdown) what security use cases we want to support.

[yolocs]

Here are the use cases I come up with.

1. Specify whether an event publisher (an identity) is allowed to send events to a broker? (policy set on the broker to restrict ingress; enforced on runtime)
2. Specify whether a user is allowed to create triggers (with potential conditions, like source=foo, type=bar) on a broker? (policy set on the broker to restrict egress; enforced on trigger creation)

Depending on policy enforcer implementation, the "identity" types in # 1 could get richer over time. Whether the identity is verifiable is not important as long as the policy enforcer has its way to really enforce the policy.

[yolocs]

Also paste use cases from security task force.

• A service must have an identity, it can be permitted to receive or send events.
• An event type is a unique identifier. When a customer refers to a specific event type, it has only one meaning, only one schema, regardless of which service emitted that event type.
• Given an identified service, identify which event types that service is allowed to emit. The service must therefore have a unique identity.
• Given an identified service, identify which event types the service is allowed to ingest.
• Given an identified service, identify which other services may receive events from the service.
• Given an identified service, identify which other services may send events to the service.

[mikehelmick]

/cc @mikehelmick

[mikehelmick]

/close

security use cases are captured in the security feature proposal
https://docs.google.com/document/d/1Nymrlp__dXKsp02Dpif0GN_Pskm6YXv6WjeF8trYzzk/edit?ts=5e26534f#heading=h.40sx8g1rk63h