Recommendations for RFC8935/8936 and Assigning Endpoints
Closed this issue · 2 comments
As per the Aug 22 call, I reviewed the SSF draft 2 spec and did not find any issues with needing tokens to determine stream.
However, a lot of implementations of RFC8935/8936 use stream specific tokens in order to push or pull events. Since stream id is a notion of SSF, it might be worth while talking about a couple of trade-offs.
-
Given that SSF enables an automated stream creation process have SSF return a unique URL for each stream. Remembering the path is not really an issue since the automated workflow is configuring the endpoints. A stream specific endpoint might look like: ssf.example.com/events/{streamid} or ssf.example.com/events?streamId={streamId}. This uncouples access from stream selection allowing an access control layer to determine if a subject identified by an authorization header is allowed access to the resource. Also, this avoids the need for token rotation and expiry issues. This also doesn't preclude the use of tokens. Another benefit is detecting mis-configuration.
-
Use a special bearer token which contains a stream_id claim and a common endpoint. (ssf.example.com/events) A concern here is that for publishers/receivers dealing with multiple streams, diagnosis can be harder because the stream_id is "hidden" in the token. Another concern is should a general shared OAuth AS server be used, or an SSF specific server.
There may be some other guidance we can apply to 8935/8936 usage.
I'm pretty sure option 1 is already called out in the spec. It says that a stream MUST create a unique endpoint if delivery is polling. I'll try to link the relevant section when I get back to my computer.