TSP是英文Trust Spanning Protocol的縮寫，翻譯為信任互聯協議。其中 ‘Spanning’ 也可以理解為 ’跨越‘，即跨越不同的信任域的協議。互聯網起源于不同的物理網絡之間需要 ’跨越‘ 的訴求，比如當時的局域網有以太網(Ethernet)、Token Bus、Token Ring等多種，各自有自己的地址格式、物理介質、和控制協議，加上局域網之間需要另一種廣域網來把它們聯接到一起，這就衍生了Inter-network 網絡之間的網絡的概念和協議(即 Internetworking Protocol 縮寫為IP)，簡稱Internet。

如果說IP協議聯接了不同的網絡，那么TSP協議可以理解為聯接了不同的信任域。TSP的作者最初把它叫做“信任域互聯協議”(Inter-Trust Domain Protocol or ITDP)。什么是信任域呢？信任域可以定義為一個采用統一的數字標識符和信任認證機制的計算機系統的集合。比如采用公開密鑰架構(PKI)下的數字證書認證機構(CA)來給每個系統發放X.509格式證書，系統之間通過對X.509證書的認證來驗明真實身份，那么這樣的一群系統之間就可以互相“信任”了。在這個例子里，所謂的“信任”的基礎是大家都可以信任這些CA，尤其是根CA，我們把這樣的一群系統叫做一個信任域，信任域之內的系統間的信任是可以有統一標準可以遵循的。

信任域可以有無數多個。即使是大家都采用同樣的PKI標準，每個不同的根CA可以派生出一個不同的信任域。同時不少應用場景可能會采用不同的技術標準，比如證書的內容、格式、線下的治理條例、甚至法律規章等都在造就不同的信任域。

單一的信任域不能完全包含整個互聯網里無數的系統和多元的應用場景。比如，企業之間可能沒有上下附屬關系；國際之間可能無法統一對治理規則的認可；針對每個個人的系統(或未來的AI Agent)的數量級會太大，導致集中由CA發布與管理證書的方式不現實成本高；另外單一的CA的安全風險可能太高，等等。這些因數導致互聯網中實際上采用PKI的系統常常是有限的，而且問題很多。互聯網的成功在于其分布式體系結構，PKI的缺點則在于它的集中性，集中化的系統難以規模化，難以接受多元化的應用需求，系統維護成本不斷提高，而且有單一系統單點故障的風險。

這些新的挑戰需要用更加分布式的信任技術來克服。除去單一的中心化模塊才能讓整個系統滿足互聯網級別的規模化要求，滿足無數種應用場景的多元化要求，滿足區域之間數據治理的合規要求，以及克服單點故障的魯棒性要求，等等。

但是如果只是采用多種多個信任域，把互聯網分割成了一個個的孤島，那就違背的互聯網的初心和優點了。所以我們必須同時發展一個可以讓不同的信任域能夠互聯又保持信任的機制，這就是信任互聯協議(Trust Spanning Protocol, or TSP)。

互聯網的原始設計本身不包含一個內涵的信任機制，比如IP的地址和數據包內容很容易被篡改，所以發送與接收雙方都不能確認IP數據包是不是真的從源地址來，到目標地址去，也不能確認收到的數據是真實數據。因為互聯網遍布全球的任何角落，無法在物理網絡層面克服這些問題，我們必須在上層協議上來解決。我們把這一類問題歸結為真實性問題(Authenticity)，包括發送和接收方的身份真實性(Identity Authenticity)，也包括數據的真實性(Message Authenticity)。對應地講，就是我們需要一套身份標識符及其認證機制，加上數據簽名(或MAC)及其認證機制。

第二類的問題是數據保密的問題(Confidentiality)。這類問題大部分開發人員和用戶都比較熟悉，即所謂的加密機制以保證沒有其他第三方可以讀到數據包中的內容。也有人把這類問題叫做保護個人隱私，但只包括對數據內容的隱私保護(Content Privacy)。為了準確起見，我們采用私密性(Confidentiality)來表示這一類問題。我們熟悉的TLS協議就是主要用來支持私密性的。私密性一般必須首先滿足真實性，沒有真實性的話私密性也就無從談起，比如說A送一個私密信息給B，如果第三方C能夠冒充是B，那么什么加密都是沒有用的。所以我們需要把Authenticity和Confidentiality綁在一起使用。比如TLS采用X.509格式的證書來驗證身份。

那么為什么需要設計一個新的協議而不直接使用成熟的TLS呢？首先，TLS(和相關的HTTPS協議等)采用PKI和基于X.509的證書。如上所述，這樣的系統無法滿足現代和未來互聯網的需求，我們希望采用分布式無中心點(即去中心化)的可認證標識符。其次，現有的TLS實現都只要求服務器端提供證書，不包括客戶端，從而導致客戶的認證只能依靠微弱的密碼方式或損害隱私的聯邦認證方式來實現。另外，即使采用雙向TLS，對客戶端和服務器都發證書，PKI管理的效率很低，所以證書數據的質量非常微弱，實時性差，安全效益很低而部署成本很高。這也是X.509證書的使用沒有遍布互聯網的根本原因。我們認為真正有效的解決方案需基于分布式系統。更重要的是，即使在某些應用場景規模不大可以采用PKI下的X.509證書，它所提供的安全系數還是不強。比如TLS在認證了證書之后通過協議產生一個對稱的密鑰，所以從根本上講無法區分發送方和接收方，也就不能滿足不可抵賴性。這些問題嚴重地限制可以實現的安全性和隱私保護的要求。

所以，我們需要一套新的更強的安全協議，基于分布式無中心的架構，充分保證真實性和私密性，來作為未來應用的安全基礎。這就是TSP協議設計的出發點。

TSP還提供了一套全新的工具來解決第三類問題：元數據的私密性(Meta-data Privacy)。這方面的問題在以前(包括TLS)的技術方案中考慮很少，但現在越來越影響到用戶的隱私。由于互聯網的底層(比如TCP/IP)沒有私密性，即使我們的應用采用了端到端的加密，其數據流的TCP端口和IP地址等元數據還是可以在網上觀察到的，并且可以與其他信息聯合在一起從而了解到很多個人信息。TSP協議為解決這第三類問題提供了基于中間點(Intermediaries)的解決方案，即可保護元數據的私密性，又可以實現TSP系統的規模化，滿足整個互聯網規模的需求。

綜上所述，在TSP協議中，真實性是首要保證的，同時可根據實際應用需求選擇數據私密性和/或元數據私密性。TSP的主要技術特點可以總結為以下幾個方面：

• 多種多類可認證標識符(Verifiable Identifiers)，尤其包括去中心化標識符(Decentralized Identifiers，DID)

作為信任域之間的橋梁，TSP是為多種類可認證標識符(Verifiable Identifier)設計的，包括去中心化的標識符(DID)但不僅限于此。比如我們正在開發基于傳統X.509格式的did:x509，基于WEB的did:web，以及基于自認證標識符(Self-Certifying Identifier, SCID)的did:webs、did:tdw (trusted web)、和KERI AID等。未來可以出現更多的可認證標識符以滿足多元的應用需求，只要它們滿足TSP定義的“可認證性”的要求。

• 有方向性的信任關系(Directional Relationship)

A信任B并不代表B信任A，這是個常理，也常常是許多應用的安全和隱私保障機制里重要的區分，但現有的安全體系一般都是不完全區分通訊的雙方的。TSP的基礎信任架構是一種有方向性的信任關系(Directional Relationship)：A -> B，其中A和B以Verifiable Identifier來代表，而他們之間的通訊通過非對稱密鑰算法來實現。

• 采用基于非對稱密鑰的真實性和私密性保障(Public Key Authenticated Encryption)

同時保障真實性和私密性是大部分應用場景的公共要求，但是以前的實現通常最終歸結為發送方和接收方之間的共享對稱密鑰的，從而在信任關系上無法區分他們，也不能滿足“不可抵賴性”(Non-Repudiation)。以前這樣的對稱性設計是因為效益原因，對稱性算法遠比非對稱算法成本低，但也是源于Client/Server模式的信任關系：一般都是服務器方在主導從而私密性不是主要考慮。在TSP架構下，通訊的雙方是對稱平行的。TSP采用公開密鑰認證加密算法(Public Key Authenticated Encryption, PKAE)，基于RFC9180(HPKE)定義的格式，同時也支持開源軟件中常用的Nacl/Libsodium實現的Sealed Box。這兩種實現是基本一致的，我們希望將來他們會最終統一為一種兼容的實現。

PKAE本身仍然有一些值得重視的安全和隱私缺陷，比如在密鑰泄露時可能被第三方冒充的弱點(Key Compromise Inpersonation, KCI)，TSP通過發送方簽名來克服這個弱點。另外TSP采用ESSR算法來加強某些配置下的接收方不可冒充性的功能(Receiver UnForgeability, RUF)等。

結合這些非對稱性算法和協議技術，TSP為互聯網通訊提供了最安全又最私密的保障。

• 采用嵌套式信息包來加強元數據私密性(Nested Messages)

隨著互聯網應用的普及，很多原先不太重要的設計細節的缺點浮出水面。元數據的泄露就是其中之一，包括IP、TCP、HTTPS等等協議的Header中的諸多信息。把這些元信息和其他個人信息交叉索引，尤其是采用AI算法，可以非常準確地還原許多個人信息。所以個人信息的保護常常不能停留在數據內容層面，也需要在元數據層面采取保護措施。TSP的嵌套式信息包可以隱蔽內部真正使用的VID，避免被交叉索引算法所用。

• 采用路由信息包，通過中間點系統保證規模化實現，并同時加強元數據私密性(Routed Messages)

雖然點對點的信任關系是TSP協議的基礎，在實際部署中因為多種原因，引入高性能的中間服務節點是至關重要的：幾乎所用的現代互聯網應用都采用大型數據中心作為服務器；移動手機應用必須解決間斷性聯網的問題，某個服務器必須替不能永久聯網的節點作為信息存儲器；我們也需要解決用戶間互相發現的問題，大型中間服務可以幫助這方面的實現；同時網路的路由，以避開出問題的節點和不可信的資源等，仍然需要某種路由協議經過中間節點來解決。

TSP不僅僅引入的中間點的結構，同時設計了可以通過中間點加強對用戶元數據私密性保護的路由機制。TSP的路由機制為上層應用提供在互聯網基礎上的端對端路由信息包(Routed Messages)通訊，其中的中間節點無需知道確切完整的路由途徑，從而為兩端的用戶提供又高性能又安全私密的通用信息包服務。如果有必要，上層應用還可以將前一節里介紹的嵌套式信息包和路由結合在一起，更加加強路由協議下的元信息私密性。

• 支持最現代的加密和認證算法，支持后量子計算加密和認證算(Post-Quantum Cryptography, or PQC)

HPKE定義了一套指定加密和認證算法的統一規格，因此TSP可以不僅支持現階段最新最現代的算法，而且可以在必要時快速地采用新的算法，無需TSP協議本身的改動。這個優點也包括了對后量子密碼算法的支持。TSP的另一個重要特點是每個TSP的數據都采用自編碼單元(Self Encoding)，這更是對協議的未來演變的高度保障(Future-Proof)。

• 采用高效益編碼系統

非常高效益的編碼系統又是另一個TSP的技術特點。TSP的數據包結構(Message Structure，即用戶內容除外的包的結構部分)采用可組合事件流表達式(Composible Event Streaming Representation, CESR)來實現數據結構的線性轉化(Serialization)。“可組合”意味著在“編碼”和“串聯“兩個操作之間的可交換性，也就是說，先編碼再串聯與先串聯在編碼會得到完全同樣的結果。可組合性為軟件實現提供很多的方便，包括支持高性能的流處理實現。CESR同時設計了高效的編碼表，在TSP這樣高程度使用密碼操作的協議里，這種效益的成本優勢非常明顯。另外，如上一節所述，CESR是一個完全自編碼的數據格式，它支持更好的未來可擴張可演變性。TSP協議的內容部分(即用戶數據主體)則可以是任何常見的協議，包括JSON、CBOR、MsgPak等。這也是自定義格式的一個優點，數據單元可以采用每個應用所需的格式而不必強求統一。

• 與網絡載體解耦

TSP可以完全與網絡載體解耦，它可以用于任何底層傳輸協議之上，也可以用在非互聯網載體中，比如云存儲、Bluetooth、NFC、甚至QR或信件等等。這樣的設計讓它的應用面非常廣，同時開發者可以根據應用要求作合適的調整，又不妨礙協議的信任互聯可互操作性。

• 為多種多元的上層應用設計

TSP的設計遵循最小化的原則。作為一個互聯協議，TSP對應用層提出的限制越小越好，TSP才能越被普遍地采用。TSP為確實需要的信任任務提供必須的互操作性服務，其他功能一律排除在外，留給應用按具體情況來實現。這樣的設計理念將TSP和許多其他類似的協議區分開來，TSP只是一個工具，真正的應用將會是應用層軟件和TSP的結合。

• 開源協議實現和編程界面

TSP的開源實現也是一個重要的特性。TSP的SDK使用Rust語言編程，大幅提高加密和認證代碼的可靠性和安全性，防止常見的C語言的內存安全性弱點，同時又支持高效高性能。為了給常見的開發場景提供方便，TSP的開發社區也將提供相關的編程環境Bindings，比如JS、Python、WASM、C、Android、iOS等等。TSP的SDK為上層軟件提供方便又簡易安全的編程界面，讓原先非常復雜又高風險的信任協議的編程變得簡單清晰。

【1】W. Chu, S. Smith, “Trust Spanning Protocol (TSP) Specification”, Implementer’s Draft, https://trustoverip.github.io/tswg-tsp-specification.

【2】The OpenWallet Foundation TSP Lab Project, https://github.com/openwallet-foundation-labs/tsp.

【3】R. Barnes, K. Bhargavan, B. Lipp, C. Wood, RFC 9180, “Hybrid Public Key Encryption”, https://datatracker.ietf.org/doc/rfc9180/. Feb 2022.

【4】Libsodium (Nacl) Documentation，https://doc.libsodium.org/.

【5】J. H. An, “Authenticated Encryption in the Public-Key Setting: Security Notions and Analyses”, Cryptology ePrint Archive, Paper 2001/079, https://eprint.iacr.org/2001/079.

【6】M. Spony, A. Guy, M. Sabadello, D. Reed, et al, “Decentralized Identifiers (DIDs) v1.0”, https://www.w3.org/TR/did-core/. W3C Recommendation, 19 July 2022.

【7】S. Smith, K. Griffin, “Composable Event Streaming Representation (CESR)”, v1.0, https://trustoverip.github.io/tswg-cesr-specification/.

【8】D. Hardman, S. Curran, S. Curren, et al, “ Peer DID Method Specification”, v1.0, https://identity.foundation/peer-did-method-spec/.

【9】S. Curran, J. Jordan, A. Whitehead, B. Richter, “Trust DID Web - did:tdw”, Draft, https://bcgov.github.io/trustdidweb/.

【10】P. Feairheller, D. Hardman, S. Smith, L. Byrd, et al, “ToIP did:webs Method Specification v0.9.15”, https://trustoverip.github.io/tswg-did-method-webs-specification/.

【11】M. Prorock, O. Steele, O. Terbu et al, “did:web Method Specification”, 06 May 2023, https://w3c-ccg.github.io/did-method-web/.

【12】E. Scouten, W. Chu (co-Chairs), et al, “did:x509 Method Specification”, Work in progress in the Trust over IP (ToIP) X.509 based DID Task Force X5VTF. https://github.com/trustoverip/tswg-did-x509-method-specification.