The result are (very) short protocol programs, a well-specified and flexible interaction API, and clean separation between security protocol and application. Taken together you get several benefits:
- Security protocols become short, textual descriptions. These are more understandable than 30,000 lines of code, with blurred boundaries between cryptography, protocol machinery, and application.
- Easily replaceable, especially compared to the normal approach of redesigning/patching, recompilation, relinking, redeployment, versional control of binaries, and so on.
- The requirements and results of the protocol becomes clear. The application can inspect a script to see what it needs to run and what it provides. If neither is understood by the application, another script can be selected.
- A novel way of communication. Not only what, but how is now communicable. The security protocol itself has been parameterized by means of easily transferable scripts.
- Experimentation. You can, for example, choose to disable the common assumption that the ordering of components within a message mattersthis raises considerable heated debate, but so far it seems that the assumption is just an optimization, and that many protocols can function correctly without it (at O(N!) cost).