fixes #325 by updating references to The Notary Project

Signed-off-by: Zach Rhoads <[email protected]>

content/en/docs/concepts/_index.md

@@ -1,6 +1,6 @@
 ---
 title: Concepts
-description: The collection of requirements and scenarios that define v2 of the Notary project
+description: The collection of requirements and scenarios that define the Notary Project
 weight: 6
 ---
 

content/en/docs/faq.md

@@ -1,13 +1,13 @@
 ---
 title: "Frequently asked questions"
-description: "Frequently asked questions about Notary"
+description: "Frequently asked questions about the Notary Project"
 type: docs
 weight: 8
 ---
 
-## What registries are compatible with Notary?
+## What registries are compatible with the Notary Project?
 
-The following registries are compatible with Notary for artifact signing and verification:
+The following registries are compatible with the Notary Project Notation CLI for artifact signing and verification:
 
 - [Azure Container Registry](https://learn.microsoft.com/azure/container-registry/?wt.mc_id=azurelearn_inproduct_oss_notaryproject)
 - [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)
@@ -24,7 +24,7 @@ The following registries are compatible with Notary for artifact signing and ver
 
 **Q: Why JWT `exp` and `iat` claims are not used?**
 
-**A:** Unlike JWT which always contains a JSON payload, Notary envelope can support payloads other than JSON, like binary. Reusing the JWT payload structure and claims, limits the Notary JWS envelope to only support JSON payload, which is undesirable. Also, reusing JWT claims requires following same claim semantics as defined in JWT specifications. The [`exp`](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4) claim requires that verifier MUST reject the signature if current time equals or is greater than `exp`, where as Notary allows verification policy to define how expiry is handled.
+**A:** Unlike JWT which always contains a JSON payload, [Notary Project OCI Signature Specification](https://github.com/notaryproject/notaryproject/blob/main/specs/signature-specification.md) envelope can support payloads other than JSON, like binary. Reusing the JWT payload structure and claims, limits the signature envelope to only support JSON payload, which is not extendable. Also, reusing JWT claims requires following same claim semantics as defined in JWT specifications. The [`exp`](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4) claim requires that verifier MUST reject the signature if current time equals or is greater than `exp`, where as the Notary Project's [trust store and trust policy](https://github.com/notaryproject/notaryproject/blob/main/specs/trust-store-trust-policy.md) allows verification policy to define how expiry is handled.
 
 ## Signature specification
 
@@ -56,14 +56,14 @@ This has implication such as an end user with CA issued certificate can masquera
 
 ## Trust store and trust policy
 
-**Q: Does Notary supports `n` out of `m` signatures verification requirement?**
+**Q: Does the Notary Project trust policy support `n` out of `m` signatures verification requirement?**
 
-**A:** Notary doesn't support n out m signature requirement verification scheme.
+**A:** The Notary Project doesn't support n out m signature requirement verification scheme.
 Signature verification workflow succeeds if verification succeeds for at least one signature.
 
-**Q: Does Notary support overriding of revocation endpoints to support signature verification in disconnected environments?**
+**Q: Does the Notary Project support overriding of revocation endpoints to support signature verification in disconnected environments?**
 
-**A:** TODO: Update after verification extensibility spec is ready.
+**A:** Update after verification extensibility spec is ready.
 Not natively supported but a user can configure `revocationValidations` to `skip` and then use extended validations to check for revocation.
 
 **Q: Why user needs to include a complete certificate chain (leading to root) in the signature?**

content/en/docs/how-to/_index.md

@@ -1,6 +1,6 @@
 ---
 title: How-to guides
-description: The collection of guides for configuring and using Notary
+description: The collection of guides for configuring and using the Notary Project Notation CLI
 weight: 5
 ---
 

content/en/docs/installation/_index.md

@@ -1,6 +1,6 @@
 ---
 title: Installation guides
-description: The collection of guides for installing and using Notary
+description: The collection of guides for installing and using Notation
 weight: 3
 ---
 

content/en/docs/overview.md

@@ -1,29 +1,28 @@
 ---
 title: "Project overview"
-description: "An overview of the Notary project"
+description: "An overview of the Notary Project"
 type: docs
 weight: 1
 ---
 
 {{% alert title="Important" color="info" %}}
-This article as well as the rest of this documentation describes the latest status of Notary Project and refers to it as The Notary Project. For documentation of older versions and implementations, please refer to the [previous Notary documentation](https://github.com/notaryproject/notary/tree/master/docs).
+This article as well as the rest of this documentation describes the latest status of the Notary Project and refers to it as the Notary Project. For documentation of older versions and implementations, please refer to the [previous documentation](https://github.com/notaryproject/notary/tree/master/docs).
 {{% /alert %}}
 
 ## Project Status
 
-The Notary project is in early development and design documents should not be considered final.
-Please refer to the [milestones](https://github.com/notaryproject/notaryproject/milestones) or [attend]({{< ref "/community" >}}) the weekly meetings for details on the roadmap.
+The Notary Project is under active development. The Notary Project maintainers intend to make a best-effort to maintain backwards-compatibility with updates to the Notary Project specifications and its reference implementation, the Notation CLI. For updates for Notary Project sub-project and milestones, see [milestones](https://github.com/notaryproject/notaryproject/milestones) or [attend]({{< ref "/community" >}}) the weekly meetings for details on the roadmap.
 
-## Notary Overview
+## Notary Project Overview
 
-![Notary scenarios](/docs/notary-e2e-scenarios.svg)
+![Notary Project scenarios](/docs/notary-e2e-scenarios.svg)
 
-Notary provides for multiple signatures of an [OCI Artifact][oci-artifacts] (including container images) to be persisted in an [OCI conformant][oci-distribution-conformance] registry.
+The Notary Project provides for multiple signatures of an OCI Artifact (including container images) to be persisted in an [OCI distribution v1.1 compliant][oci-distribution-conformance] registry.
 Artifacts are signed (`notation sign`) with private keys, and validated with public keys (`notation verify`).
 To support user deployment flows, signing an OCI Artifact will not change the `@digest` or `artifact:tag` reference.
 To support content movement across multiple certification boundaries, artifacts and their signatures will be easily copied within and across [OCI conformant][oci-distribution-conformance] registries.
 
-To deliver on the Notary goals of cross registry movement of artifacts with their signatures, changes to several projects are anticipated, including [OCI distribution-spec][oci-distribution-spec], [CNCF Distribution][cncf-distribution], [OCI Artifacts][oci-artifacts], [ORAS][oras] with further consumption from projects including [containerd][containerd], [OPA][opa], [Gatekeeper][gatekeeper] and the [docker client][docker-client].
+To deliver on the Notary Project goals of cross registry movement of artifacts with their signatures, changes to several projects are anticipated, including [OCI distribution-spec][oci-distribution-spec], [CNCF Distribution][cncf-distribution], and [ORAS][oras] with further consumption from projects including [containerd][containerd], [OPA][opa], [Gatekeeper][gatekeeper] and the [docker client][docker-client].
 
 Notary aims to solve the intra and cross registry signing & validating scenarios through the following prototypical experiences:
 
@@ -32,18 +31,18 @@ Notary aims to solve the intra and cross registry signing & validating scenarios
 - Copy a container image to a private registry, verifying the source then adding a verification signature
 - run one or more verification processes, then sign with the ACME Rockets key
 
-## The Notary Journey
+## The Notary Project Journey
 
-Notary [kicked off in December of 2019][notaryv2-kickoff] with a [broad range of attendees][kickoff-attendees].
+The Notary Project[kicked off in December of 2019][notary-project-kickoff] with a [broad range of attendees][kickoff-attendees].
 The effort defined success goals, including adoption by all major vendors & projects, enabling content to be signed and flow within and across [OCI distribution-spec conformant][oci-distribution-conformance] registries.
-Throughout 2020, the group agreed upon a set of [Notary requirements](https://github.com/notaryproject/notaryproject/blob/main/requirements/requirements.md) and [scenarios][nv2-scenarios] enabling spec and design conversations to be grounded in a set of [goals](https://github.com/notaryproject/notaryproject/blob/main/requirements/requirements.md) and [non-goals][non-requirements].
+Throughout 2020, the group agreed upon a set of [Notary requirements](https://github.com/notaryproject/notaryproject/blob/main/requirements/requirements.md) and [scenarios][notary-project-scenarios] enabling spec and design conversations to be grounded in a set of [goals](https://github.com/notaryproject/notaryproject/blob/main/requirements/requirements.md) and [non-goals][non-requirements].
 Prototypes, based on the requirements have started, focusing on the primary areas on innovations.
 
 ## Top Areas of Focus
 
-To complete Notary, three key areas of focus were identified.
+To complete the Notary Project, three key areas of focus were identified.
 
-### Definition of a Notary Signature
+### Definition of a Notary Project Signature
 
 A Notary signature would attest to the digest of an artifact, associating it with a signing key.
 
@@ -52,7 +51,7 @@ A Notary signature would attest to the digest of an artifact, associating it wit
 An artifact must be capable of being pushed to a registry, with a signature being added independently from the artifact.
 This enables the originating author of the content to sign the artifact, and subsequent entities to add additional signatures, attesting to its validity as they determine.
 
-The Notary workflow ([outlined in Scenario #0](https://github.com/notaryproject/notaryproject/blob/main/requirements/scenarios.md#scenario-0-build-publish-consume-enforce-policy-deploy)
+The Notary Project workflow ([outlined in Scenario #0](https://github.com/notaryproject/notaryproject/blob/main/requirements/scenarios.md#scenario-0-build-publish-consume-enforce-policy-deploy)
 Docker Hub may endorse Wabbit Networks software, providing an aggregator certification by adding a Docker Hub signature.
 This would allow customers like ACME Rockets to not necessarily know of small vendors like Wabbit Networks, but allow the ACME Rockets engineering team to pull Docker Certified content.
 As ACME Rockets imports the content, scans and validates it meets their requirements, they add an additional ACME Rockets signature, which must exist for any production usage within the ACME Rockets environment.
@@ -65,26 +64,26 @@ No additional changes are known at this time.
 #### Registry Discovery
 
 Registry discovery of linked artifacts enables finding a signature, based on the target artifact.
-In the Notary example, the ACME Rockets production servers must be capable of efficiently finding the ACME Rockets signature for the `net-monitor:v1` image.
-Once the signature is identified, through a content addressable digest, the Notary client may validate the signature.
+In the Notary Project example, the ACME Rockets production servers must be capable of efficiently finding the ACME Rockets signature for the `net-monitor:v1` image.
+Once the signature is identified, through a content addressable digest, the Notary Project client, such as the Notation CLI, may validate the signature.
 
-### Key Management
+### Key and Certificate Management
 
 Key Management involves the following key scenarios:
 
 - Signing with private keys
 - Publishing and discovery of public keys for consumers to validate signatures
 - Key revocation, including support for air-gapped environments
 
-Private key management is beyond the scope of the Notary effort, as companies have well defined practices that are internal to their software development.
+Private key management is beyond the scope of the Notary Project effort, as companies have well defined practices that are internal to their software development.
 
-Publishing and discovery of public keys should be easy for consumers to acquire, however, Notary will not implicitly support a **T**rust **o**n **F**irst **U**se (TOFU) model.
+Publishing and discovery of public keys should be easy for consumers to acquire, however, the Notary Project will not implicitly support a **T**rust **o**n **F**irst **U**se (TOFU) model.
 
 Key revocation must support air-gap environments, enabling users to validate keys when resources inside a network isolated environment are unable to reach public endpoints.
 
 ## Stages of Development
 
-To deliver Notary, we recognized the need of experts from multiple backgrounds, experiences and skill sets.
+To deliver the Notary Project, we recognized the need of experts from multiple backgrounds, experiences and skill sets.
 The various perspectives were needed to assure we learned from past efforts and learned from subject matter experts.
 
 As subject matter experts converged, we found it difficult for the various SMEs to understand other components of the end to end workflow.
@@ -96,18 +95,18 @@ To facilitate better communications across the skill sets, respecting everyone's
 We followed the design patterns of other large, complex projects like Antoni Gaudí's design of [The Sagrada Familia](https://simple.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia).
 The [sketch, prototype, build approach](https://stevelasker.blog/2020/07/31/sketch-prototype-build/) would enable the various experts to focus on their component, while understanding where they plug-into other components of the design.
 
-As a result, we identified the following stages of the Notary effort:
+As a result, we identified the following stages of the Notary Project effort:
 
 1. Define Requirements
-1. Build Prototypes
+1. Build Prototypes using Notation
 1. Validate prototypes - learning, refining requirements, iterating prototypes
-1. Author a Notary Spec
+1. Author a Notary Project specification
 
-See the [Notary project on GitHub](https://github.com/notaryproject/notaryproject/tree/main/status-updates) for updates to the stages of development and areas of focus. 
+See milestones of respective Notary Project sub-projects for updates to development and areas of focus. 
 
 ## Contributing & Conversations
 
-Regular conversations for Notary occur on the [Cloud Native Computing Slack](https://app.slack.com/client/T08PSQ7BQ/CQUH8U287?) channel.
+Regular conversations for the Notary Project occur on the [Cloud Native Computing Slack](https://app.slack.com/client/T08PSQ7BQ/CQUH8U287?) channel.
 
 Weekly meetings occur each Monday.
 Please see the [CNCF Calendar](https://www.cncf.io/community/calendar/) for details.
@@ -120,17 +119,9 @@ Meeting notes are captured on [hackmd.io](https://hackmd.io/_vrqBGAOSUC_VWvFzWru
 [gatekeeper]:                   https://github.com/open-policy-agent/gatekeeper
 [kickoff-attendees]:            https://github.com/notaryproject/meeting-notes/blob/main/meeting-notes-2019.md#attendees
 [moby]:                         https://github.com/moby
-[notaryv2-kickoff]:             https://github.com/notaryproject/meeting-notes/blob/main/meeting-notes-2019.md#notary-v2-kickoff-meeting
+[notary-project-kickoff]:             https://github.com/notaryproject/meeting-notes/blob/main/meeting-notes-2019.md#notary-v2-kickoff-meeting
 [non-requirements]:             https://github.com/notaryproject/notaryproject/blob/main/requirements/requirements.md#non-goals
-[nv2-notes]:                    https://hackmd.io/_vrqBGAOSUC_VWvFzWruZw
-[nv2-scenarios]:                https://github.com/notaryproject/notaryproject/blob/main/requirements/scenarios.md
-[nv2-signature-spec]:           https://github.com/notaryproject/nv2/tree/prototype-1/docs/signature
-[nv2-threat-model]:             https://github.com/notaryproject/notaryproject/blob/main/threatmodel.md
-[nv2-key-management]:           https://github.com/notaryproject/requirements/pull/38/
-[nv2-distribution-spec]:        https://github.com/opencontainers/artifacts/pull/29
-[nv2-definitions]:              https://github.com/notaryproject/notaryproject/blob/main/requirements/definitions-terms.md
-[oci-artifacts]:                https://github.com/opencontainers/artifacts
-[oci-artifact-manifest]:        https://github.com/opencontainers/artifacts/pull/29
+[notary-project-scenarios]:     https://github.com/notaryproject/notaryproject/blob/main/requirements/scenarios.md
 [oci-distribution-spec]:        https://github.com/opencontainers/distribution-spec
 [oci-distribution-conformance]: https://github.com/opencontainers/oci-conformance
 [opa]:                          https://github.com/open-policy-agent

content/en/docs/tutorials/_index.md

@@ -1,6 +1,6 @@
 ---
 title: Tutorials
-description: A set of guides that walks you through using the different capabilities and features of Notary
+description: A set of guides that walks you through using the different capabilities and features of the Notary Project
 weight: 4
 ---
 

content/en/docs/tutorials/trust-policy.md

@@ -5,7 +5,7 @@ type: docs
 weight: 1
 ---
 
-As part of the process to verify a container image with notary, you need to configure the trust policy to specify trusted identities that sign the artifacts, and the level of signature verification to use. For more details, see [trust policy spec](https://github.com/notaryproject/notaryproject/blob/main/specs/trust-store-trust-policy.md#trust-store).
+As part of the process to verify a container image with Notation, you need to configure the trust policy to specify trusted identities that sign the artifacts, and the level of signature verification to use. For more details, see [trust policy spec](https://github.com/notaryproject/notaryproject/blob/main/specs/trust-store-trust-policy.md#trust-store).
 
 This tutorial shows you how to create a trust policy with different trusted identities and levels of signature verification.