Changes between Initial Version and Version 1 of Ticket #510, comment 15
- Timestamp:
- 2011-09-08T18:35:38Z (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #510, comment 15
initial v1 10 10 11 11 When developing a new HTTP(S)-based protocol, we have to decide whether to implement our own encryption to manage authorization or to continue using the "enablers" design on top of SSL/TLS (thus making it be an HTTPS 12 -only protocol and not an HTTP-protocol). I think it may actually ease deployment and usage to do the former, because SSL/TLS is a bit of a pain to deploy. I think it may actually also simplify the protocol! This is somewhat surprising, but what we need is an authorization protocol and what SSL/TLS provides is a two-party confidential, integrity-preserving channel with server-authentication. It kind of looks like implementing our own crypto authorization protocol may be simpler(such as described in comment:11) may result in a simpler protocol than implementing an authorization protocol layered on top of a secure channel protocol.12 -only protocol and not an HTTP-protocol). I think it may actually ease deployment and usage to do the former, because SSL/TLS is a bit of a pain to deploy. I think it may actually also simplify the protocol! This is somewhat surprising, but what we need is an authorization protocol and what SSL/TLS provides is a two-party confidential, integrity-preserving channel with server-authentication. It kind of looks like implementing our own crypto authorization protocol (such as described in comment:11) may result in a simpler protocol than implementing an authorization protocol layered on top of a secure channel protocol. 13 13 14 14 Our custom protocol would also be a bit more efficient, where efficiency is measured primarily by number of required round-trips.
