these posts mention being called in to consult with small client/server startup that wanted to do payments on their server ... and they had this technology called SSL.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

some of the work for deployment including doing some of the stuff for taking a technology and turning it into a business process. this is now frequently called electronic commerce and is probably the main use of SSL in the world today.

misc. other posts about the business process related to the digital certificates for the SSL process
http://www.garlic.com/~lynn/subpubkey.html#sslcert

i've mentioned before that we subsequently worked on x9.59 financial transaction protocol
http://www.garlic.com/~lynn/x959.html#x959

which can be considered to obsolete much of the work that we had previously done in conjunction with SSL (for what is comingly now called electronic commerce). recent post here
http://www.garlic.com/~lynn/aadsm26.htm#70 WSJ: Soft evidence on a crypto-related breach

Now this recent post makes some slight reference to issues with using a connection protocol for transaction operation
http://www.garlic.com/~lynn/2007j.html#38 Problem with TCP connection close

... for some minor historical drift ... while tcp/ip is the technology basis for the modern internet, we claim that the operational basis for the modern internet came with the NSFNET backbone. Here is some old collected email working on various aspects of NSFNET backbone ... and then not being allowed to bid (even tho subsequent NSF audit
of what we already had running claimed that it was at
least five yrs ahead of all NSFNET backbone bids to build something new):
http://www.garlic.com/~lynn/lhwemail.html#nsfnet

we also served on what was the "XTP" technical advisory board ... attempting to do both high-speed protocol as well as support reliable transactions. The above post references that session TCP operation requires a minimum of seven packet exchange ... and that VMTP/RFC1045 required minimum of five packet exchange. XTP only needed a minimum of three packet exchange for reliable transaction operation.

misc. posts mentioning XTP as well as folly of attempting to get an XTP high-speed protocol work item into ISO standards ... where ISO network standards had a requirement that only work on network standards could be done for things that dont' violate OSI model (and turns out that both IP, internetworking protocol and LAN/MACs violate OSI).
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

now these series of posts mention that general internet public key distribution could be done as part of DNSSEC that includes registering public keys with DNS as part of domain name registration. The basic objective improves the integrity of DNS ... which the SSL domain name certification authorities rely on when they are attempting to validate SSL digital certificate applications. However, it could also be used to obsolete the need to have SSL digital certificates for public key distribution (doing real-time, online, trusted distribution) ... creating something of a catch-22 for the certification authority industry
http://www.garlic.com/~lynn/subpubkey.html#catch22

If registered public key could be piggy-backed on the standard DNS domain to ip-address response (along with any required crypto preferences) ... then the client would have the server's public key before even contacting the server (w/o any additional protocol chatter). for other topic drift some old crypto related email
http://www.garlic.com/~lynn/lhwemail.html#crypto
including one from may81 about a online network service for trusted public key distribution
http://www.garlic.com/~lynn/2006w.html#email810515

Coupled with XTP, an extremely simplified, transaction SSL is possible ... a client could generate a random secret key, encrypt transaction message with the secret key, encrypt the secret key with the server's public key ... and send the combination (encrypted transaction message and encrypted secret key) to the server in a single message

This is separate from the x9.59 transaction scenario with regard to whether it is necessary to hide/encrypt the information at all; x9.59 transaction could be sent via XTP to a server w/o requirement for hiding/encryption.

re:
http://www.garlic.com/~lynn/aadsm27.htm#0 H6.2 Most Standardized Security Protocols are Too Heavy

for a little additional topic drift ....

in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for *ALL* retail payments ... which results in x9.59 financial standard protocol
http://www.garlic.com/~lynn/x959.html#x959

there were various other efforts going on in the area of secure payment protocols at the time ... attempting to improve what had already been done for electronic commerce with SSL

typical of the genre from the period ... there were protocols proposed that would increase the payload of typical payment transaction by a factor of 100 times (enormous payload bloat) as well as processing by a factor of 100 times (enormous processing bloat) ... misc. past posts mentioning some of the activity from the period that would result in enormous bloat
http://www.garlic.com/~lynn/subpubkey.html#bloat

"Most apps are message oriented" too true, plus a lot of your risk of winding up in the WSJ (in a bad way) is in the data/message. Further, yoru average corporate data center terminates SSL at its outer edge, many hops from the web/app server.