Add a definition doc and refer to it in the README

README.md

@@ -5,6 +5,7 @@
 
 The Transparent Release project builds on the idea of binary transparency and extends it in a few
 directions, as described below.
+See [Transparent Release defitions](https://github.com/project-oak/oak/blob/main/docs/definitions.md) for the generalised definitions for the terms and the process.
 
 ## Release Transparency
 

docs/definitions.md

@@ -0,0 +1,51 @@
+# Transparent Release Definitions
+This document outlines the concept of transparent release, rather than what _Oak_ transparent release is. It provides [clear definitions for the components](#building-blocks) of Transparent Release and outlines a [general-purpose transparent release process](#generic-transparent-release).
+
+## Building Blocks
+
+### Trusted builder
+
+A trusted builder serves as a dependable tool for users seeking to ensure the accurate transformation of source code into binary output. Establishing user trust with a builder involves multiple steps, including using an open-source build toolchain (e.g. SLSA build stack). However, open-sourcing the toolchain used for building the binaries is not enough; the toolchain must also be running on trusted infrastructure/platform. To achieve this, the code owner can opt to run the builder on a platform controlled by an actor in whom users have a high degree of confidence, especially one where collusion between the code owner and platform owner is highly unlikely. For instance, Oak (Google) uses SLSA build stack (open-source toolchain) on GitHub (Microsoft). To further increase the level of assurance, one can run multiple instances of the build toolchain, each one operating on a different platform controlled by a different actor. For example, Oak runs an additional builder instance on Google Cloud.
+
+### Transparency log 
+A transparency log is an append-only, independent third-party hosted, publicly-available log.
+
+### Provenance statement
+
+A Provenance statement is a signed statement generated by the trusted builder. It contains information about:
+
+1. From which source code the binary was built 
+1. How the binary was built. Particularly, what toolchain and what command/configuration/flags were used
+
+***Unsigned provenance statement***
+
+Depending on the use case and trust model, the provenance statement does not have to be signed. In that case, the users need to take on the responsibility of building the binary themselves and comparing the relevant metadata from their self-built binary with the information included in the provenance statement. This choice presents a crucial tradeoff: one between (a) a signed provenance statement where users need to trust the builder and only need to verify the signature, and (b) an unsigned provenance statement where users must compile the binary themselves and verify the validity of the build-related information included in the provenance statement. 
+
+In the unsigned provenance scenario, users are relieved from having to place trust in the signer, i.e. the trusted builder. However, this convenience comes at the expense of the time and effort required to build the binary, which can become substantial, particularly in the case of large code bases. Conversely, in the signed provenance scenario, the situation is reversed. 
+
+Therefore, in essence, the act of signing the provenance statement introduces the concept of a trusted builder into the trusted release process. A trusted builder becomes superfluous if the provenance statement remains unsigned or if the client/user prefers to avoid placing trust in the builder and chooses to compile the binary independently.
+
+### Endorsement statement
+
+An endorsement statement is a signed statement that is generated by the owner of the code. It includes the hash of the endorsed binary to be able to uniquely identify it, the time of issuance, the time range for its validity, as well as the digest and URI of the provenance statement. This statement is used for verifying that the code owner has validated the provenance statement for a particular binary. 
+
+Consequently, by issuing an endorsement statement for a specific binary, the code owner confirms that the binary was generated from the precise source code, using the correct toolchain and build commands/configurations/flags  (the guarantees about the building process are dependent on the provenance statement being signed, as explained above). The endorsement statement also implicitly confirms that the code owner "endorses" the binary to be used in production for the specified validity range. This means that they have done additional controls that are not explicitly captured in the endorsement statement.
+
+***Provenance\-less endorsement statement***
+
+There is also the option of having a provenance-less endorsement, which can be used in setups where the source code is closed-source. The assurances offered by this type of endorsement differ from those provided by an endorsement featuring a provenance statement. Most significantly, a provenance-less endorsement does not assert the binary's origin from a specific source code or its construction by a trusted builder (which an endorsement that includes a signed provenance statement would). Moreover, a provenance-less endorsement cannot be used for providing assurance about the security of a supply chain. 
+
+Instead, a provenance-less endorsement establishes the code owner’s accountability for the binaries that it has released, ensuring that they cannot disown a particular binary’s release. Furthermore, it allows the users to verify that the binary they have running on a device is the same one that everyone else has. This way, the users can ensure that they are not a subject of a targeted attack. Lastly, a provenance-less endorsement ensures that any attacks on the released binary does not go unnoticed—as a new transparency log entry for a specific release or the lack thereof will be detectable.
+
+## Generic Transparent Release
+
+1. The code owner writes a piece of software, and ensures that it is reproducibly buildable (which is optional if the builder is fully-trusted and the provenance is signed).
+
+1. The code owner triggers a build of the code in the trusted builder. The trusted builder builds the code into a binary and generates a signed provenance statement about the binary and the build process. The trusted builder returns the binary to the code owner, and puts the provenance statement on a transparency log. If there are multiple trusted builders as explained in the definitions, then all builders do the same.
+
+1. Once the code owner receives the binary and the provenance statement, she (1) verifies the signature of the provenance statement, and (2) confirms that the information it contains about the build process is correct. If there are multiple trusted builders, the code owner does these checks for each build. In that case, all binaries and their hashes must be identical.
+
+1. If these checks are successful, the code owner generates an endorsement statement about the binary. She then releases the binary (e.g. puts them on a website, deploys them on server or client devices, etc.), and puts the endorsement statement on a transparency log. The code owner can re-release endorsement statements for the same binary whenever needed, e.g. if the existing one’s validity has expired.
+
+1. When a client wants to verify the trustworthiness of a specific binary, she gets the endorsement statement for that particular binary version from the transparency log. She then checks that (1) the signature on the endorsement is valid, and (2) the hash in the endorsement statement matches the hash of the binary. 
+