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

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

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

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

這些新的挑戰(zhàn)需要用更加分布式的信任技術(shù)來克服。除去單一的中心化模塊才能讓整個系統(tǒng)滿足互聯(lián)網(wǎng)級別的規(guī)模化要求，滿足無數(shù)種應用場景的多元化要求，滿足區(qū)域之間數(shù)據(jù)治理的合規(guī)要求，以及克服單點故障的魯棒性要求，等等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)合這些非對稱性算法和協(xié)議技術(shù)，TSP為互聯(lián)網(wǎng)通訊提供了最安全又最私密的保障。

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

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

• 采用路由信息包，通過中間點系統(tǒng)保證規(guī)?；瘜崿F(xiàn)，并同時加強元數(shù)據(jù)私密性(Routed Messages)

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

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

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

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

• 采用高效益編碼系統(tǒng)

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

• 與網(wǎng)絡載體解耦

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

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

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

• 開源協(xié)議實現(xiàn)和編程界面

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

【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.