What was the thinking around not recommending any security model for the protocol? Has there been any attempt on adding a Security Extension to the protocol?
In our experience, authentication and authorization is very application specific. Tus servers are often integrated into existing infrastructure and, as such, they usually inherit the security setup from the existing components.
Therefore, we left authentication and authorization up to the user. They can use cookies, the Authorization header, JWTs, etc.
Ya that definitely makes sense. Although, I see enough scope of reusability here. For example, if someone has already implemented say cookie based integration can’t that be used by the community? What’s the take on such platformish evolution?
Yes, you are correct, such implementations can be reused. Many tus servers, such as tusd, go beyond the requirements of the specification and implement additional features. In some cases, these features can be used to implement authentication and authorization as a user. For example, tusd has a hook system using which a user can inspect incoming requests and allow/disallow them based on the request headers. As such, it allows access control using cookies or other authentication headers.
I see, the servers can do custom extension implementations. My concern was also from client side resuability.
Here in this case of security integration, the client side change is just passing additional headers which doesn’t require much changes. The server implementations can follow the extension model to add a security model.
In case we have a much broader extension then we’ll go about making it a part of the protocol. I hope my articulation makes sense.
You are correct. I absolutely second this. We are always open to discussing the idea of adding new extensions to the protocol.