Pith. sign in

REVIEW 3 major objections 5 minor 29 references

WSEmail: A Retrospective on a System for Secure Internet Messaging Based on Web Services

T0 review · 3 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper argues that WSEmail, a web-services redesign of email from 2005, demonstrates how email and instant messaging could have been unified securely and privately while preserving openness and extensibility.

desk verdict A solid retrospective of a 2005 system, not a new-results paper; its central plug-in auto-download security story is load-bearing and unanalyzed. read the letter →

arxiv 1908.02108 v2 pith:AN2EP7SJ submitted 2019-08-06 cs.NI cs.CRcs.SE

Michael J. May , Kevin D. Lux , Carl A. Gunter This is my paper · ORCID
classification cs.NIcs.CRcs.SE
keywords WSEmailwebservicesemailsecurityinstantmessagingplug-inarchitectureon-demandattachmentsformalverificationSOAP
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

WSEmail is a 2005 system that reimagines electronic mail as a family of SOAP-based web services instead of SMTP. The paper argues that this architecture could have delivered messaging that is secure, open, and extensible at the same time, unifying email and instant messaging in one platform. As evidence, it presents three working applications—instant messaging, routed business workflow forms, and on-demand attachments—along with a formal proof that the on-demand attachment retrieval protocol is sound and performance measurements showing about 284 ms per request on modest hardware. The intended takeaway is not that WSEmail itself should be resurrected, but that it is a model for how next-generation messaging could avoid the closed, centralized designs that dominate today.

What carries the argument

The central mechanism is the plug-in architecture. Both the mail user agent and the mail transfer agent load code libraries that implement named interfaces—ISendingProcessor, IDeliveryProcessor, and IExtensionProcessor—so new message semantics can be added without changing the base protocol. A sender attaches a "form" created by a plug-in; the receiver's client either loads the plug-in from a local registry or downloads it from the network location the sender supplies, then feeds the XML payload to the plug-in. Security is carried by a three-tier authentication model (user credentials or federated tokens, server certificates, and root certificates) with XMLDSIG signatures checked by each hop, plus hop-by-hop TLS for confidentiality.

What would settle it

A practical test would be to send a WSEmail client a message carrying a plug-in that, once the user approves the download, reads the user's federated token and transmits it to a third party; the paper reports no such test and no formal analysis of the plug-in download path, so observing a successful exfiltration would refute the claim that the extensibility mechanism is secure.

Watch

Extended reading notes

Core claim

The paper's central claim is that WSEmail serves as a model for unifying email and IM in a secure, private way without sacrificing extensibility or openness. The system's messages are SOAP messages with XMLDSIG signatures; its three-tier authentication handles users, servers, and root certificates; and its plug-in architecture lets both clients and servers add new message semantics dynamically. The authors demonstrate the claim with three implemented applications: secure-channel instant messaging, workflow forms that route through sign-off chains, and on-demand attachments where the file stays on the sender's server. They also cite a formal correspondence proof for on-demand attachments and present latency data that they interpret as showing performance is not a barrier.

Load-bearing premise

The load-bearing premise is that having a receiving client download and run a plug-in from the sender's supplied network location, after only a user approval and a check of a self-signed Authenticode signature, is safe; if a malicious message can persuade a user to approve a malicious plug-in, the extensibility that WSEmail advertises becomes an attack path.

Editorial extensions

If this is right

  • A single WSEmail-style stack can serve both email and instant messaging, with IM messages delivered through the same server, client, and security mechanisms as email.
  • On-demand attachments remove the need for third-party attachment storage while keeping access control on the sender's server, and the retrieval protocol is formally provable.
  • Business workflows can travel as signed XML forms across organizational boundaries, with auditable X.509 sign-off and delegation rules encoded in server-side plug-ins.
  • XML security overhead is not prohibitive: at roughly 284 ms per request on Pentium 4 hardware, WSEmail stays within a few hundred milliseconds of plain SMTP.
  • The plug-in mechanism allows new message types to be deployed without modifying the base protocol or libraries, preserving interoperability.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same plug-in-on-demand pattern could be tested against today's federated messaging protocols, where the usual trade-off is open transport versus closed end-to-end features.
  • If the plug-in download path were hardened with a trusted-signature or sandbox requirement, WSEmail's extensibility model would be a plausible template for safe bots and mini-apps in open messaging systems.
  • The latency data imply that SOAP verbosity, not cryptography, is the main overhead; a modern implementation with compressed XML or JSON encodings would likely match SMTP latency.
  • A direct comparison of routed-form workflows across two independently administered WSEmail domains with cross-trusted certificate authorities would test whether the multi-enterprise workflow claim holds in practice.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper presents WSEmail, a system that redesigns email and instant messaging as a family of SOAP-based web services. It describes the base architecture, the plug-in mechanism for client and server extensions, and three implemented applications: secure-channel instant messaging, business workflows with routed forms, and on-demand attachments. It cites a previously published formal proof of the on-demand attachment protocol using TulaFale/ProVerif and reports performance measurements from a .NET prototype, finding an average latency of 284 ms per request under a mixed workload. The paper argues that WSEmail demonstrates an evolutionary path in which messaging can be secure, private, open, and extensible, unlike today's closed messaging platforms.

Significance. If the central claim holds, WSEmail is a useful architectural existence proof: web-services-based messaging can integrate email and IM while retaining distributed control and extensibility, and at least one core protocol admits machine-checked security verification. The paper's strengths include the availability of the source code (GitHub), the use of a formal verification toolchain (TulaFale/ProVerif) rather than informal argument, the description of three working applications, and an honest statement that confidentiality is hop-by-hop rather than end-to-end. However, the claimed 'secure and private' extensibility rests on a client plug-in download path that is not analyzed, and the performance evidence is a single test run with a non-comparable baseline, so the significance is conditional on whether these gaps can be closed.

major comments (3)
  1. [Section 3.2 (Client-side Plug-ins); Abstract; Section 7] The automatic plug-in download path is load-bearing for the paper's central claim that WSEmail unifies email and IM 'in a secure and private way without hindering extensibility and openness' (Section 7). Section 3.2 states that a receiving client downloads a plug-in from a sender-supplied network location after user approval, that the code is self-signed with Authenticode, and that plug-ins 'have access to authentication information in the mail client and may petition users for access to their federated token.' A self-signed Authenticode signature establishes no trusted publisher identity, and no sandbox, permission model, or publisher verification is described for the code that then executes in the client process. The formal proof cited in Section 4.3 is scoped to the on-demand attachment protocol and explicitly deferred to an external reference, so it does not cover this path. Because the abstract presents automatic plug-in download as the basis for 'rich extensions without changing the base protocol,' this unanalyzed code-execution path directly contradicts the security half of the central claim; the authors should either add a concrete mitigation (e.g., publisher verification, sandboxing, or least-privilege token access) or narrow the security claim to the base protocol and clearly state the plug-in path as a trust assumption.
  2. [Section 5.4 (Analysis), Table 1] The comparison between WSEmail's 284 ms average latency and SMTP's 170 ms latency is not apples-to-apples. The WSEmail average is over a workload of send, list, retrieve, and delete operations in roughly equal proportions (Table 1), whereas the SMTP figure is for sending a single message of similar size under no load. The 114 ms difference therefore conflates different operation types, different message sizes, and different load conditions, and cannot be attributed solely to XML parsing and cryptography as the text claims. The capacity extrapolation to 1787 messages/minute is derived by inverting this average latency, but list/retrieve/delete requests are not message sends, so the extrapolation does not follow. The analysis should either report per-operation latencies against a comparable SMTP send baseline or clearly label the capacity figure as a rough upper-bound heuristic.
  3. [Section 5.3 (Procedure and Results)] The performance conclusion rests on a single 1830-second test run with no replication, no confidence intervals, and no variation of message size, authentication type (all clients used username tokens), or client count. The reported variance of 138.9 ms characterizes the spread within the run rather than the uncertainty of the mean, so the claim of 'about a quarter of a second per transaction under load' is a single data point. Additionally, the latency stops at the server's 'message received confirmation,' which 'does not mean that the message was delivered to the final recipient' (Section 5.3), so end-to-end delivery latency is understated. The authors should either add more runs or acknowledge explicitly that the measurement is anecdotal from a legacy testbed.
minor comments (5)
  1. [Section 5.4] The sentence 'the extra latency would likely be unnoticeable a typical client/server environment' is missing the word 'in' before 'a typical.'
  2. [Section 2 (Security Architecture)] The phrase 'at the cost of full end-to-end confidentiality' could be clarified: the architecture provides hop-by-hop confidentiality via TLS, not end-to-end encryption, and the text should state that trade-off explicitly to avoid implying the opposite.
  3. [Section 5.2, 5.3] The GitHub URL 'https://github.com/lux-k/wsemail' is split across two lines in the PDF; ensure it appears as a single hyperlink.
  4. [Section 4.3] The theorem for on-demand attachments is stated informally; including the precise correspondence property in a definition or displayed equation would make the paper more self-contained, since the proof is in an external reference.
  5. [References] The online appendix URL (http://www2.kinneret.ac.il/mjmay/wsemail/) should include an access date, as it may not be stable.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the machine-checked proof and measured performance data are independent of the paper's own conclusions.

full rationale

The paper's derivation chain is self-contained against external benchmarks. The formal security claim for on-demand attachments (Section 4.3) is explicitly deferred to Lux et al. [20], a self-citation, but this is not circular: the cited proof was produced with the TulaFale specification language, which compiles to ProVerif, an automated protocol verifier, so the mathematical result is machine-checked with stated assumptions rather than assumed by the present paper. The performance claims (Section 5) are measured latencies from a described testbed using four standard operations; they are reported data, not fitted predictions, and the extensibility claims are backed by three implemented use-case plug-ins (Sections 4.1-4.3). The automatic plug-in download path (Section 3.2) is a genuine security risk because plug-ins are self-signed with Authenticode and execute after only user approval, and the conclusion's strength does exceed the verified scope, but that is an evidentiary or correctness concern, not a circular derivation. No equation or parameter is defined in terms of the claimed conclusion, and no load-bearing step reduces by construction to the paper's own inputs.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The paper introduces no new physical or formal entities. The free-parameter list is empty because no model is fitted to data; the capacity figure is a deterministic extrapolation, not a fit. The axioms above are the unstated premises the claims rest on.

assumptions (3)
  • domain assumption Cryptographic primitives (public key signatures, TLS, salted password authentication) are secure as idealized in the TulaFale/ProVerif model.
    The cited formal proof of on-demand attachments relies on the standard Dolev-Yao style idealizations of crypto built into ProVerif; the paper does not prove the primitives themselves.
  • ad hoc to paper The client's access control check and user approval are sufficient to ensure that downloaded plug-ins are trustworthy.
    Sections 2 and 3.2 describe the plug-in download mechanism but provide no formal or empirical analysis of its security; it is a load-bearing assumption for the extensibility claim.
  • domain assumption DNS SRV records are correctly configured and trusted for routing.
    Section 5.1 says WSEmail uses DNS SRV records for routing; the paper does not analyze threats to DNS integrity (DNSSEC is mentioned as an email hardening, not used here).

how reviews work

0 comments
Cite this review

Pith. "Pith review of WSEmail: A Retrospective on a System for Secure Internet Messaging Based on Web Services." pith.science (2026). https://pith.science/paper/AN2EP7SJ

@misc{pith2026190802108,
  author       = {Pith},
  title        = {Pith review of: WSEmail: A Retrospective on a System for Secure Internet Messaging Based on Web Services},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AN2EP7SJ}},
  note         = {Machine review of arXiv:1908.02108}
}
read the original abstract

Web services offer an opportunity to redesign a variety of older systems to exploit the advantages of a flexible, extensible, secure set of standards. In this work we revisit WSEmail, a system proposed over ten years ago to improve email by redesigning it as a family of web services. WSEmail offers an alternative vision of how instant messaging and email services could have evolved, offering security, extensibility, and openness in a distributed environment instead of the hardened walled gardens that today's rich messaging systems have become. WSEmail's architecture, especially its automatic plug-in download feature allows for rich extensions without changing the base protocol or libraries. We demonstrate WSEmail's flexibility using three business use cases: secure channel instant messaging, business workflows with routed forms, and on-demand attachments. Since increased flexibility often mitigates against security and performance, we designed WSEmail with security in mind and formally proved the security of one of its core protocols (on-demand attachments) using the TulaFale and ProVerif automated proof tools. We provide performance measurements for WSEmail functions in a prototype we implemented using .NET. Our experiments show a latency of about a quarter of a second per transaction under load.

Figures

Figures reproduced from arXiv: 1908.02108 by the authors.

Figure 1
Figure 1. Messaging architecture demand attachments. Section 5 presents our imple￾mentation and its performance. Section 6 has re￾lated work and compares WSEmail to similar messag￾ing systems. Section 7 concludes. Interested readers can find more information in the online appendix at http://www2.kinneret.ac.il/mjmay/wsemail/. 2 Base Architecture The base protocols for WSEmail are illustrated in [PITH_FULL_IMAGE:figures/full_… view at source ↗
Figure 2
Figure 2. Security Architecture Our design is based on a three-tier authentication system combined with an extensible system of federated identities. The first tier provides user (MUA) authentication based on passwords, public keys, or federated identity tokens. The second tier provides server (MTA) authentica￾tion based on public keys with certificates similar to those used for Transport Layer Security (TLS). The [PITH_FULL… view at source ↗
Figure 3
Figure 3. Component diagram for WSEmail client, server, and associated services. The plugins are elaborated [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (11 more)
Figure 4
Figure 4. Figure 4: Component diagram for some example plug-ins. Message dependent plug-ins require that a message be present to execute. They can be inserted in var￾ious places in the delivery cycle, including at initial receipt of a message (ISendingProcessor) or at the final destinatio…
Figure 5
Figure 5. Figure 5: An overview of server-side plug-ins interface (IExtensionProcessor). On initializing, the plug-ins provide the server with an extension identi￾fier. It is used by the server to route incoming re￾quests to the appropriate plug-in. There is no re￾quired or defined struct…
Figure 7
Figure 7. Figure 7: New message screen [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Inbox screen platforms for these features from software vendors, we can use WSEmail as a foundation for a suite of inte￾grated applications that share common code, routing, security, and other features. To illustrate, we sketch three applications that we implemented wi…
Figure 11
Figure 11. Figure 11: Instant Messaging Overview [PITH_FULL_IMAGE:figures/full_fig_p008_11.png]
Figure 10
Figure 10. Figure 10: Client-side plug-ins from the recipient’s [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]
Figure 13
Figure 13. Figure 13: Sample Workflow Scenario A workflow in our system can send its result to another program. The receiving program could then validate the entire form and perform the required op￾erations (e.g. file an order, perform database ma￾nipulations). With an increasing number of…
Figure 14
Figure 14. Figure 14: On Demand Attachments Protocol [PITH_FULL_IMAGE:figures/full_fig_p010_14.png]
Figure 15
Figure 15. Figure 15: Testbed Architecture tination was local (i.e. the recipient was on Si), the message was stored in Sdb. If the destination was ex￾ternal, the message was forwarded to Se. We allowed the local and external server to share a database and DNS server since they were not pe…
Figure 16
Figure 16. Figure 16: Server implementation class diagram 17 [PITH_FULL_IMAGE:figures/full_fig_p017_16.png]
Figure 17
Figure 17. Figure 17: Server architecture with plugins 18 [PITH_FULL_IMAGE:figures/full_fig_p018_17.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

29 extracted references · 29 canonical work pages

  1. [1]

    Abadi, N

    M. Abadi, N. Glew, B. Horne, and B. Pinkas. Certified email with a light on-line trusted third party: design and implementation. In Proceed- ings of the Eleventh International Conference on World Wide Web , pages 387–395. ACM Press, 2002

    work page 2002

  2. [2]

    Raja Afandi, Jianqing Zhang, and Carl A. Gunter. AMPol-Q: Adaptive middleware policy to support QoS. In Proceedings of the 4th Inter- national Conference on Service-Oriented Com- puting, ICSOC’06, pages 165–178, Berlin, Hei- delberg, 2006. Springer-Verlag

    work page 2006

  3. [3]

    Forensic analysis of WhatsApp messenger on Android smartphones

    Cosimo Anglano. Forensic analysis of WhatsApp messenger on Android smartphones. Digital In- vestigation, 11(3):201–213, 2014. Special Issue: Embedded Forensics

    work page 2014

  4. [4]

    Web Services Policy 1.2 - Framework (WS-Policy)

    Siddharth Bajaj, Don Box, Dave Chap- pell, Francisco Curbera, Glen Daniels, Phillip Hallam-Baker, Maryann Hondo, Chris Kaler, Dave Langworthy, Anthony Nadalin, Nataraj Nagaratnam, Hemma Prafullchandra, Claus von Riegen, Daniel Roth, Jeffrey Schlimmer, Chris Sharp, John Shewchuk, Asir Vedamuthu, ¨Umit Yal¸ cinalp, and David Orchard. Web Services Policy 1.2 ...

    work page 2006

  5. [5]

    Bartel, J

    M. Bartel, J. Boyer, B. Fox, B. LaMacchia, and E. Simon. XML-signature syntax and process- ing. W3C recommendation, World Wide Web Consortium, Feb 2002

    work page 2002

  6. [6]

    Bhargavan, C

    K. Bhargavan, C. Fournet, and A. Gordon. A se- mantics for web services authentication. In Pro- ceedings of the 31st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Lan- guages, pages 198–209, New York, NY, 2004. ACM Press

    work page 2004

  7. [7]

    Bhargavan, C

    K. Bhargavan, C. Fournet, A. D. Gordon, and R. Pucella. TulaFale: A security tool for web services. In International Symposium on Formal Methods for Components and Objects (FMCO’03), LNCS. Springer, 2003

    work page 2003

  8. [8]

    Silver needle in the Skype

    Philippe Biondi and Fabrice Desclaux. Silver needle in the Skype. In BlackHat Europe 2006 . Black Hat, March 2006. 15

    work page 2006

Show all 29 references
  1. [9]

    Blanchet

    B. Blanchet. An efficient cryptographic protocol verifier based on Prolog rules. In Proceedings of the 14th IEEE Workshop on Computer Security Foundations, page 82. IEEE Computer Society, 2001

    2001

  2. [10]

    Bobba, O

    R. Bobba, O. Fatemieh, F. Khan, C. A. Gunter, and H. Khurana. Using attribute-based access control to enable attribute-based messaging. In 2006 22nd Annual Computer Security Applica- tions Conference (ACSAC’06) , pages 403–413, Dec 2006

    2006

  3. [11]

    Off-the-record communication, or, why not to use PGP

    Nikita Borisov, Ian Goldberg, and Eric Brewer. Off-the-record communication, or, why not to use PGP. In Proceedings of the 2004 ACM Workshop on Privacy in the Electronic Society , pages 77–84, New York, NY, USA, 2004. ACM

    2004

  4. [12]

    A formal security analysis of the Signal messag- ing protocol

    Katriel Cohn-Gordon, Cas Cremers, Benjamin Dowling, Luke Garratt, and Douglas Stebila. A formal security analysis of the Signal messag- ing protocol. Cryptology ePrint Archive, Report 2016/1013, 2016. eprint.iacr.org/2016/1013

    2016

  5. [13]

    Gioachin, R

    F. Gioachin, R. Shankesi, M. J. May, C. A. Gunter, and W. Shin. Emergency alerts as RSS feeds with interdomain authorization. In Second International Conference on Internet Monitor- ing and Protection (ICIMP 2007) , pages 13–13, July 2007

    2007

  6. [14]

    Peer-to-peer calling in Hangouts

    Google. Peer-to-peer calling in Hangouts. Hangouts Help [Online], 2018. last accessed 22 Nov 2018. https://support.google.com/ hangouts/answer/6334301?hl=en

    2018

  7. [15]

    Can my GTalk discussion be tracked? Google Talk Help Discussion Archive [Online], 21 Nov 2006

    GoogleTalkGuide. Can my GTalk discussion be tracked? Google Talk Help Discussion Archive [Online], 21 Nov 2006

    2006

  8. [16]

    Huang, P

    Q. Huang, P. P. C. Lee, C. He, J. Qian, and C. He. Fine-grained dissection of WeChat in cellular networks. In 2015 IEEE 23rd In- ternational Symposium on Quality of Service (IWQoS), pages 309–318, June 2015

    2015

  9. [17]

    Is Slack’s WebRTC really slacking? webrtcH4cKS, 24 Mar 2016

    Yoshimasa Iwase. Is Slack’s WebRTC really slacking? webrtcH4cKS, 24 Mar 2016

    2016

  10. [18]

    Karpisek, I

    F. Karpisek, I. Baggili, and F. Breitinger. What- sApp network forensics: Decrypting and under- standing the WhatsApp call signaling messages. Digital Investigation , 15:110–118, 2015. Special Issue: Big Data and Intelligent Data Analysis

    2015

  11. [19]

    Cryptocat: Adopting accessibility and ease of use as security properties

    Nadim Kobeissi and Arlo Breault. Cryptocat: Adopting accessibility and ease of use as security properties. CoRR, abs/1306.5156, 2013

    2013 arXiv

  12. [20]

    Lux, Michael J

    Kevin D. Lux, Michael J. May, Nayan L. Bhat- tad, and Carl A. Gunter. Wsemail: Secure in- ternet messaging based on web services. In 2005 IEEE International Conference on Web Services (ICWS), Orlando, FL, USA, July 2005. IEEE

    2005

  13. [21]

    Web services se- curity: SOAP message security 1.1 (WS- Security 2004)

    Anthony Nadalin, Chris Kaler, Ronald Monzillo, and Phillip Hallam-Baker. Web services se- curity: SOAP message security 1.1 (WS- Security 2004). Standard wss-v1.1-spec-os- SOAPMessageSecurity, OASIS, Feb 2006

    2004

  14. [22]

    A look at WeChat security, 17 Sept 2013

    Roberto Paleari. A look at WeChat security, 17 Sept 2013

    2013

  15. [23]

    Restful web services vs

    Cesare Pautasso, Olaf Zimmermann, and Frank Leymann. Restful web services vs. ”big”’ web services: Making the right architectural decision. In Proceedings of the 17th International Confer- ence on World Wide Web , WWW ’08, pages 805–814, New York, NY, USA, 2008. ACM

    2008

  16. [24]

    An ag- gregated technique for optimization of SOAP performance in communication in web services

    Kennedy Mutange Senagi, George Okeyo, Wil- son Cheruiyot, and Michael Kimwele. An ag- gregated technique for optimization of SOAP performance in communication in web services. Service Oriented Computing and Applications , 10(3):273–278, Sep 2016

    2016

  17. [25]

    Security White Paper: Slack’s Approach to Security, 2019

    Slack. Security White Paper: Slack’s Approach to Security, 2019

    2019

  18. [26]

    Petmail Design

    Brian Warner. Petmail Design. Petmail, 20 July

  19. [27]

    WhatsApp encryption overview

    WhatsApp. WhatsApp encryption overview. Technical white paper, WhatsApp, 16 Nov 2016

    2016

  20. [28]

    Dan Zhou, J. C. Kuo, S. Older, and S. K. Chin. Formal development of secure email. In Proceed- ings of the 32nd Annual Hawaii International Conference on Systems Sciences , Jan 1999. A UML Class Diagrams Figures 16 and 17 show the UML class diagram for the server-side implemen...

    1999

  21. [2005]

    last accessed 13 Aug 2019

    2019

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.