Merge pull request #98 from trustoverip/wenjing-TAS

update authenticity, metadata privacy, VID defs & diagrams with VID labels

spec/spec.md

@@ -225,12 +225,13 @@ With regard to the first design goal, establishing trust between [[xref: toip, p
 
 1. **Authenticity:** is the receiver of a communication able to verify that it originated from the sender and has not been tampered with?[^1]
 2. **Confidentiality:** is the contents of a communication protected so only authorized [[xref: toip, parties]] have access?
-3. **Privacy:** will the expectations of each [[xref: toip, party]] with respect to usage of shared information be honored by the other [[xref: toip, parties]]?
+3. **Metadata Privacy:** is the metadata of a communication protected so that unauthorized parties can not collect metadata for tracking or correlating with other identifying data?[^2]
 
-Note that, in some [[xref: toip, trust relationships]], confidentiality and privacy may be optional. Thus our design goal with the [[xref: toip, ToIP stack]] is to achieve these three properties in the order listed.[^2]
+Note that, in some [[xref: toip, trust relationships]], confidentiality and metadata privacy may be optional. Thus our design goal with the [[xref: toip, ToIP stack]] is to achieve these three properties in the order listed.[^3]
 
 [^1]: With respect to this design goal, authenticity includes **message integrity**, i.e., a communication is not authentic if it has been tampered with in any way. <br>
-[^2]: Another important property of the architecture is **availability**. This is a concern with the design and implementation of operational deployments of the ToIP stack and should be addressed in the associated operational governance frameworks.
+[^2]: In addition to confidentiaility and metadata privacy, additional notions of privacy can be built with trust tasks and applications above the trust spanning layer. <br>
+[^3]: Another important property of the architecture is **availability**. This is a concern with the design and implementation of operational deployments of the ToIP stack and should be addressed in the associated operational governance frameworks.
 
 With regard to the second design goal, the ToIP reference architecture shares the same goal of global scalability as the original Internet architecture. This involves several intertwined considerations that overlap and reinforce each other as summarized by the first four [Design Principles for the ToIP Stack](https://www.trustoverip.org/wp-content/uploads/Design-Principles-for-the-ToIP-Stack-V1.0-2022-01-17.pdf):
 
@@ -307,10 +308,10 @@ Design Principle #5 ([Cryptographic Verifiability](https://trustoverip.org/perma
 
 VIDs can be divided into two subclasses as shown in figure 9:
 
-  1. **[[xref: toip, Self-certifying identifiers]] (SCIDs)** are cryptographically bound to the original key pair used to generate the VID. This means the binding between the VID and the key pair can be verified purely using cryptography—without reference to any external system. SCIDs have the advantage of being highly secure (as strong as the cryptographic algorithm used), maximally decentralized (because no external system is required), and fully portable (any external system can be used as a [[xref: toip, witness]], and the [[xref: toip, VID controller]] can change witnesses at will).
+  1. **[[xref: toip, Self-certifying identifiers]] (SCIDs)** are cryptographically bound to the original key pair used to generate the VID and subsequent key material where key rotation is supported. This means the binding between the VID and the key material can be verified purely using cryptography—without reference to any external system. SCIDs have the advantage of being highly secure (as strong as the cryptographic algorithm used), decentralized (because no external system is required), and portable.
   1. **[[xref: toip, Externally-verified identifiers]] (XVIDs)** are generated by an interaction between the VID controller's [[xref: toip, agent]] that has access to the [[xref: toip, digital wallet]] holding the cryptographic key pair and some type of external system or authority, such as a [[xref: toip, blockchain]], [[xref: toip, distributed hash table]], or [[xref: toip, certificate authority]] (CA) that is outside of the autonomous boundary of the [[xref: toip, VID controller]]. Verification of an XVID requires the [[xref: toip, verifier]] to interact with that [[xref: toip, supporting system]].
 
-Currently, the best-known form of VID is a [[xref: toip, decentralized identifier]] (DID) as defined by the [W3C Decentralized Identifiers (DID) V1.0 Specification] TODO-REFERENCE. In general, DIDs fulfill the requirement of Design Principle #4 ([Decentralization by Design and Default](https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf)). The W3C DID specification defines a generic syntax for DIDs and a standard data model for a [[xref: toip, DID document]]—the artifact obtained through [[xref: toip, DID resolution]] that contains the [[xref: toip, cryptographic keys]] and [[xref: toip, service endpoints]] bound to the DID. The syntax for a specific type of DID and the process for creating, reading, updating, or deactivating the associated DID document is defined by a [[xref: toip, DID method]]. As of mid-2024, there are almost 200 DID methods registered in the W3C DID Spec Registry, all of which can be classified as either a SCID or an XVID.
+Currently, the most common form of VID is a [[xref: toip, decentralized identifier]] (DID) as defined by the [W3C Decentralized Identifiers (DID) V1.0 Specification] TODO-REFERENCE. In general, DIDs fulfill the requirement of Design Principle #4 ([Decentralization by Design and Default](https://trustoverip.org/permalink/Design-Principles-for-the-ToIP-Stack-V1.0-2022-11-17.pdf)). The W3C DID specification defines a generic syntax for DIDs and a standard data model for a [[xref: toip, DID document]]—the artifact obtained through [[xref: toip, DID resolution]] that contains the [[xref: toip, cryptographic keys]] and [[xref: toip, service endpoints]] bound to the DID. The syntax for a specific type of DID and the process for creating, reading, updating, or deactivating the associated DID document is defined by a [[xref: toip, DID method]]. 
 
 However, as figure 9 illustrates, there are also SCIDs and XVIDs that are not DIDs. An example of the former is an [[xref: toip, autonomic identifier]] (AID) as defined by the [[xref: toip, KERI]] specifications. An example of the latter is the authority portion of an HTTPS URL. An HTTPS URL relies on two types of [[xref: toip, supporting systems]]: 1) a CA for issuance of an X.509 digital certificate (to provide the cryptographic binding with a public key), and 2) a DNS registry (for resolution of the domain name).
 
@@ -380,7 +381,7 @@ Many applications may require more complex trust-building functions than the min
 
 A Layer 3 [[xref: toip, trust task protocol]] MUST communicate either over the Layer 2 [[xref: toip, ToIP Trust Spanning Protocol]] or over another Layer 3 [[xref: toip, trust task protocol]] for all communications related to [[xref: toip, trust establishment]] between [[xref: toip, endpoint systems]]. [REQ L3.1] This is directly analogous to how TCP and UDP communicate over IP, and how HTTP communicates over TCP. A Layer 3 [[xref: toip, trust task]] MAY use other protocols, but only for other purposes (since short-circuiting Layer 2 when establishing trust with other [[xref: toip, endpoint systems]] would undermine the trust guarantees of the ToIP stack). [REQ L3.2]
 
-Note that because [[xref: toip, confidentiality]] and privacy are optional for the Layer 2 [[xref: toip, ToIP Trust Spanning Protocol]], the following requirement applies: A Layer 3 [[xref: toip, trust task protocol]] intended to communicate private data SHOULD support confidentiality and privacy. [REQ L3.3]
+Note that because [[xref: toip, confidentiality]] and metadata privacy are optional for the Layer 2 [[xref: toip, ToIP Trust Spanning Protocol]], the following requirement applies: A Layer 3 [[xref: toip, trust task protocol]] intended to communicate private data SHOULD support confidentiality and MAY also support additional notions of privacy. [REQ L3.3]
 
 There can be as many [[xref: toip, trust task protocol]] as are needed by Layer 4 [[xref: toip, trust applications]]. Some examples of [[xref: toip, trust tasks]] include:
 
@@ -415,8 +416,6 @@ This section describes the [[xref: toip, ToIP Trust Spanning Protocol]] required
 
 **Figure 11: Overview of the ToIP Trust Spanning Protocol**
 
-TODO-WENJING-FIX THIS FIGURE TO USE "VID" INSTEAD OF "AID/DID"
-
 The main function of this protocol is to enable universal end-to-end communication among all [[xref: toip, endpoint systems]] using trusted messages. This architectural choice is based on the following considerations:
 
   - Existing Internet, local network, and mesh network infrastructure already supports universal end-to-end communication through various types of transport mechanisms.
@@ -475,16 +474,15 @@ Different considerations apply when a VID needs to be provably bound to a digita
 
 Messages are the lingua franca of the [[xref: toip, ToIP Trust Spanning Protocol]]. To achieve the design goals in [Section 6.1](#61-design-goals), the following requirements must be met:
 
-The [[xref: toip, ToIP Trust Spanning Protocol]] specification MUST define how to construct and format messages that are [[xref: toip, cryptographically verifiable]] to have the following four properties:
+The [[xref: toip, ToIP Trust Spanning Protocol]] specification MUST define how to construct and format messages that are [[xref: toip, cryptographically verifiable]] to have the following three properties:
 
-  - Authenticity: the message was sent from a sender who has control over the VID.
-  - Integrity: the contents of the message transmitted by the sender are received by the recipient without modification.
+  - Authenticity: the message was sent from a sender who has control over the source VID and the contents of the message transmitted by the sender are received by the recipient who has control over the destination VID without modification.
   - Confidentiality: the contents of the message are only accessible by authorized [[xref: toip, parties]].
-  - Privacy: the contents of the message are bound to conditions of usage agreed to by the [[xref: toip, parties]]. [REC L2.9]
+  - Metadata Privacy: the metadata related to the message and its transport and delivery is not exposed to unauthorized parties which may use it for tracking or unwanted correlation with other identifying data. [REC L2.9]
 
-In a ToIP [[xref: toip, endpoint system]], an implementation of the [[xref: toip, ToIP Trust Spanning Protocol]] MUST support [[xref: toip, authenticity]] and [[xref: toip, integrity]]. [REQ L2.10]
+In a ToIP [[xref: toip, endpoint system]], an implementation of the [[xref: toip, ToIP Trust Spanning Protocol]] MUST support [[xref: toip, authenticity]]. [REQ L2.10]
 
-In a ToIP [[xref: toip, endpoint system]], an implementation of the [[xref: toip, ToIP Trust Spanning Protocol]] MAY support [[xref: toip, confidentiality]] and privacy. [REQ L2.11]
+In a ToIP [[xref: toip, endpoint system]], an implementation of the [[xref: toip, ToIP Trust Spanning Protocol]] MAY support [[xref: toip, confidentiality]] and metadata privacy. [REQ L2.11]
 
 The [[xref: toip, ToIP Trust Spanning Protocol]] MUST enable the composition of higher-level [[xref: toip, trust tasks]]. [REQ 2.12] Examples of such features include discovery, threading, timeouts, ACKs, and attachments. However this requirement must be balanced with the requirement to only add additional functions to this protocol if they are universally beneficial.
 
@@ -537,8 +535,6 @@ Examples of useful [[xref: toip, intermediary systems]] include:
 
 **Figure 13: The role of intermediary systems**
 
-TODO-WENJING-UPDATE "DID" TO "VID" IN FIGURE 13
-
 In Figure 13, end-to-end communication between [[xref: toip, endpoint systems]] A and B are routed through [[xref: toip, intermediary systems]] X and Y. In this case, all systems implement the Layer 2 protocol as described in [Section 8](#8-the-toip-trust-spanning-protocol). Routing uses “nested envelopes” as follows:
 
   1. [[xref: toip, Endpoint system]] A prepares a message for [[xref: toip, endpoint system]] B and puts it in an inner message envelope addressed to [[xref: toip, endpoint system]] B.
@@ -599,8 +595,6 @@ Figure 16 illustrates a generalization of the pattern in which [[xref: toip, end
 
 **Figure 16: A generalization of how endpoint systems and supporting systems interact**
 
-TODO-WENJING-UPDATE "DID" TO "VID" IN FIGURE 16
-
 ## Endpoint System Interoperability
 
 ### Interoperability between Endpoint Systems Using Decentralized Identifiers
@@ -683,9 +677,9 @@ For ease of reference, the following table consolidates all normative requiremen
 |L2.6|A [[xref: toip, VID]] SHOULD support rotation of the associated [[xref: toip, cryptographic keys]] for the lifetime of the identifier.|[8.2](#82-identifiers)|
 |L2.7|A [[xref: toip, VID]] MAY also support rotation to an entirely different VID that can be cryptographically verified to be a synonym of the original VID.|[8.2](#82-identifiers)|
 |L2.8|A [[xref: toip, VID]] SHOULD support the ability to: a) associate the VID with the network address of one or more [[xref: toip, ToIP systems]] that can deliver to one or more [[xref: toip, endpoint systems]] under the locus of control of the [[xref: toip, VID controller]], and, b) if desired by the controller, enable that association to be discoverable.|[8.2](#82-identifiers)|
-|L2.9|The [[xref: toip, ToIP Trust Spanning Protocol]] specification MUST define how to construct and format messages that are [[xref: toip, cryptographically verifiable]] to have the following four properties: (1) [[xref: toip, Authenticity]]: the message was sent from a sender who has control over the VID. (2) [[xref: toip, Integrity]]: the contents of the message transmitted by the sender are received by the recipient without modification. (3) [[xref: toip, Confidentiality]]: the contents of the message are only accessible by authorized [[xref: toip, parties]]. (4) Privacy: the contents of the message are bound to conditions of usage agreed to by the [[xref: toip, parties]].|[8.3](#83-messages)|
-|L2.10|In a ToIP [[xref: toip, endpoint system]], an implementation of the [[xref: toip, ToIP Trust Spanning Protocol]] MUST support [[xref: toip, authenticity]] and [[xref: toip, integrity]].|[8.3](#83-messages)|
-|L2.11|In a ToIP [[xref: toip, endpoint system]], an implementation of the [[xref: toip, ToIP Trust Spanning Protocol]] MAY support [[xref: toip, confidentiality]] and privacy.|[8.3](#83-messages)|
+|L2.9|The [[xref: toip, ToIP Trust Spanning Protocol]] specification MUST define how to construct and format messages that are [[xref: toip, cryptographically verifiable]] to have the following three properties: (1) [[xref: toip, Authenticity]]: the message was sent from a sender who has control over the source VID and the contents of the message transmitted by the sender are received by the intended recipient who has control over the destination VID without modification. (2) [[xref: toip, Confidentiality]]: the contents of the message are only accessible by authorized [[xref: toip, parties]]. (3) Metadata Privacy: the metadata related to the message and its transport and delivery is not exposed to unauthorized parties which may use it for tracking or unwanted correlation with other identifying data.|[8.3](#83-messages)|
+|L2.10|In a ToIP [[xref: toip, endpoint system]], an implementation of the [[xref: toip, ToIP Trust Spanning Protocol]] MUST support [[xref: toip, authenticity]].|[8.3](#83-messages)|
+|L2.11|In a ToIP [[xref: toip, endpoint system]], an implementation of the [[xref: toip, ToIP Trust Spanning Protocol]] MAY support [[xref: toip, confidentiality]] and metadata privacy.|[8.3](#83-messages)|
 |L2.12|The [[xref: toip, ToIP Trust Spanning Protocol]] MUST enable the composition of higher-level [[xref: toip, trust task protocols]].|[8.3](#83-messages)|
 |L2.13|The [[xref: toip, ToIP Trust Spanning Protocol]] MUST support extensible message schema.|[8.3](#83-messages)|
 |L2.14|The [[xref: toip, ToIP Trust Spanning Protocol]] MUST support resolution of VIDs to: a) the network addresses of receiving [[xref: toip, endpoint systems]], and b) any required [[xref: toip, cryptographic keys]].|[8.4](#84-routing)|
@@ -696,7 +690,7 @@ For ease of reference, the following table consolidates all normative requiremen
 | |**ToIP Layer 3 Requirements**| |
 |L3.1|A Layer 3 [[xref: toip, trust task protocol]] MUST communicate either over the Layer 2 [[xref: toip, ToIP Trust Spanning Protocol]] or over another Layer 3 Trust Task Protocol for all communications related to trust establishment between [[xref: toip, endpoint systems]].|[7.4](#74-layer-3-trust-tasks)|
 |L3.2|A Layer 3 [[xref: toip, trust task]] MAY use other protocols, but only for other purposes (since short-circuiting Layer 2 when establishing trust with other [[xref: toip, endpoint systems]] would undermine the trust guarantees of the ToIP stack).|[7.4](#74-layer-3-trust-tasks)|
-|L3.3|A Layer 3 [[xref: toip, trust task protocol]] intended to communicate private data SHOULD support [[xref: toip, confidentiality]] and privacy.|[7.4](#74-layer-3-trust-tasks)|
+|L3.3|A Layer 3 [[xref: toip, trust task protocol]] intended to communicate private data SHOULD support [[xref: toip, confidentiality]] and MAY also support additional notions of privacy.|[7.4](#74-layer-3-trust-tasks)|
 | |**ToIP Layer 4 Requirements**| |
 |L4.1|Layer 4 [[xref: toip, trust applications]] MAY use any number of Layer 3 [[xref: toip, trust task protocols]].|[7.5](#75-layer-4-trust-applications)|
 |L4.2|If a Layer 4 [[xref: toip, trust application]] does not use a Layer 3 [[xref: toip, trust task protocol]], it MUST communicate with other [[xref: toip, endpoint systems]] using the Layer 2 [[xref: toip, ToIP Trust Spanning Protocol]].|[7.5](#75-layer-4-trust-applications)|