|
|
# Requirements
|
|
|
|
|
|
After some time, I managed to write this list of requirements for Fenrir:
|
|
|
* **Efficiency**: The protocol must not be above the 5th layer of the ISO/OSI pile and must be a binary one -- no XML.
|
|
|
* **Completeness**: The protocol must handle authentication, authorization, encryption of the connection.
|
|
|
* **Flexibility**: It must be adaptable to multiple needs -- udp or tcp-like trasmission with retransmission or not, as the programmer of the application using it desires.
|
|
|
* **Interoperbility**: A developer must be able to use a single library for multiple vendors, without any change (f**k OAuth).
|
|
|
* **Federation**: As in kerberos, federated Authentication must be possible.
|
|
|
* **Token-based**: We don't like to give our password away too often...
|
|
|
* **Nonce-based**: I really don't like to keep synchronized clocks between client and server...
|
|
|
* **Securely desinged**: The protocol must not have any amplification attack.
|
|
|
|
|
|
These are just the main requirements. a lot of other small but important stuff is:
|
|
|
* **Stream-based**: We like having multiple streams in a connection.
|
|
|
* **Reconnect** Without big handshakes: - tcp handshake + ssl handshake + OAuth handshake takes a **LOT** of time, being able to associate once and then reuse the association even after a quick network failure is a good thing.
|
|
|
* **Multi-homing** support: Possibly dynamic for long connections and mobile clients.
|
|
|
* Do something about the ridiculous **[X.509](X.509) certificate** situation.
|
|
|
* Make **coffee**: and a **good** one. I'm Italian, after all. |