Updates based on review feedback

Signed-off-by: Tracy Miranda <[email protected]>

sigstore-public-deployment-spec.md

@@ -1,7 +1,7 @@
 # Sigstore Public Deployment
 
 
-This document describes the technical and policy decisions for the public deployment of Sigstore, specifically focusing on the Fulcio and Rekor deployment for the public good instance. The [Spec: Fulcio](https://github.com/sigstore/architecture-docs/blob/main/fulcio-spec.md) and [Spec: Rekor](https://docs.google.com/document/u/0/d/1NQUBSL9R64_vPxUEgVKGb0p81_7BVZ7PQuI078WFn-g/edit) documents leave many implementation choices, such as authentication and log entry formats, to the discretion of implementers. This document outlidetails the specific implementation choices made for Sigstore's public deployment that go beyond the requirements in the specification. Additionally, this document details the use of TUF for distributing roots of trust, and includes links to deployment respositories and resources.
+This document describes the technical and policy decisions for the public deployment of Sigstore, specifically focusing on the Fulcio and Rekor deployment for the public good instance. The [Spec: Fulcio](https://github.com/sigstore/architecture-docs/blob/main/fulcio-spec.md) and [Spec: Rekor](https://docs.google.com/document/u/0/d/1NQUBSL9R64_vPxUEgVKGb0p81_7BVZ7PQuI078WFn-g/edit) documents leave many implementation choices, such as authentication and log entry formats, to the discretion of implementers. This document describes the specific implementation choices made for Sigstore's public deployment that go beyond the requirements in the specification. Additionally, this document details the use of TUF for distributing roots of trust, and includes links to deployment respositories and resources.
 
 ## 1. Introduction
 
@@ -29,28 +29,35 @@ Fulcio embeds information about the identity of a requester into the SubjectAlte
 
 These certificates have a validity period of 10 minutes, beginning at the time of issuance.
 
-* [Fulcio certification specification](https://github.com/sigstore/fulcio/blob/main/docs/certificate-specification.md)   
-* General OIDs 
+* [Fulcio certification specification](https://github.com/sigstore/fulcio/blob/main/docs/certificate-specification.md)
 
 ### 2.2 Authentication
 
 Fulcio issues [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280)\-compliant [X.509v3](https://www.itu.int/rec/T-REC-X.509) certificates encoding identity information. It must authenticate the identities which it encodes into these certificates. For additional information, see [OIDC Usage in Fulcio](https://github.com/sigstore/fulcio/blob/main/docs/oidc.md).
 
 #### 2.2.1 OpenID Connect
 
-[OpenID Connect](https://openid.net/connect/) (OIDC) is an extension of [OAuth 2.0](https://oauth.net/2/) to provide an identity layer. In Fulcio, clients may authenticate using OIDC. Subject-related claims from the OIDC token are extracted and included in issued certificates.
+[OpenID Connect](https://openid.net/connect/) (OIDC) is an open identity attestation and verification standard built on top of [OAuth 2.0](https://oauth.net/2/). Sigstore uses OIDC because it is a widely adopted, industry-standard protocol that simplifies authentication, supporting both human and machine identities. Many users already have accounts with existing OIDC providers. Additionally, OIDC makes it straightforward to implement infrastructure capable of generating OIDC-compliant tokens without requiring support for the entire authentication flow. This approach ensures a seamless and secure user experience while reducing operational overhead for implementers and users. 
 
-Learn more about certificates generated from OIDC providers at [https://github.com/sigstore/fulcio/blob/main/docs/oidc.md](https://github.com/sigstore/fulcio/blob/main/docs/oidc.md).
+In Fulcio, clients may authenticate using OIDC. Subject-related claims from the OIDC token are extracted and included in issued certificates.
+
+Learn more about certificates generated from OIDC providers at [OIDC Usage in Fulcio](https://github.com/sigstore/fulcio/blob/main/docs/oidc.md).
 
 ##### 2.2.1.1 Requirements on Identity Providers
 
-[https://github.com/sigstore/fulcio/blob/main/docs/new-idp-requirements.md](https://github.com/sigstore/fulcio/blob/main/docs/new-idp-requirements.md)
+Adding a new Identity Provider (IDP) option to Fulcio helps drive adoption of Sigstore. Because identity is a critical component of the system, it is that new IDPs meet the minimum set of requirements to ensure the security and reliability of the ecosystem and users. IDPs are categorized into two types:
+
+* Email-based OIDC Providers: These utilize the user's email or machine identity for service accounts as the certificate's subject.
+
+* Workflow-based OIDC Providers: Designed for systems like CI/CD pipelines (e.g., GitHub Actions, GitLab CI), these require more extensive onboarding.
+
+This document describes the minimum requirements for integrating new IDPs for either of these types: [New IDP Requirements](https://github.com/sigstore/fulcio/blob/main/docs/new-idp-requirements.md)
 
 ##### 2.2.1.2 Current Identity Providers
 
-Sigstore runs a federated OIDC identity provider, [Dex](https://dexidp.io/). Users authenticate to their preferred identity provider and Dex creates an OIDC token with claims from the original OIDC token. Fulcio also supports OIDC tokens from additional configured issuers.
+Sigstore runs a federated OIDC identity provider, [Dex](https://dexidp.io/). Sigstore uses Dex as an identity broker to streamline authentication across diverse identity providers, protect against and incompatibilities, and ensure a consistent experience. Additionally, Dex provides the ability to control the lifetime of tokens, ensuring tokens expire within appropriate timeframes, reducing risks associated with long-lived credentials. Users authenticate to their preferred identity provider and Dex creates an OIDC token with claims from the original OIDC token. Fulcio also supports OIDC tokens from additional configured issuers.
 
-The Fulcio implementation allows deployers to configure which OIDC IdPs to accept. The public good instance accepts the following:
+The Fulcio implementation allows deployers to configure which OIDC IDPs to accept. The public good instance accepts the following:
 
 **User Authentication**
 
@@ -62,9 +69,10 @@ Dex:
 
 **Workflow Authentication**
 
-* GitHub  
-* GitLab  
+* GitHub Actions  
+* GitLab CI  
 * BuildKite
+* CodeFresh
 
 See the [Fulcio OIDC documentation](https://github.com/sigstore/fulcio/blob/main/docs/oidc.md) for additional details.
 
@@ -78,9 +86,9 @@ Rekor implements a transparency service. There is a public good deployment of Re
 
 ### 3.1 Pluggable Types
 
-The transparency service has what is termed a ‘pluggable type’ system. A pluggable type, is a custom schema for entries stored in the transparency log. Schemas can be in multiple formats (json|yaml|xml).
+The transparency service has what is termed a ‘pluggable type’ system. A pluggable type is a custom schema for entries stored in the transparency log. Schemas can be in multiple formats (json|yaml|xml).
 
-The current list of supported types can be found in the [Rekor project](https://github.com/sigstore/rekor/tree/main/pkg/types). Information about adding new pluggable types can be found in the [Rekor documentation.](https://docs.sigstore.dev/docs/logging/pluggable-types/)
+The current list of supported types can be found in the [Rekor project](https://github.com/sigstore/rekor/tree/main/pkg/types). Information about adding new pluggable types can be found in the [Rekor documentation.](https://docs.sigstore.dev/logging/pluggable-types/)
 
 See the transparency service ([Spec: Rekor](https://docs.google.com/document/u/0/d/1NQUBSL9R64_vPxUEgVKGb0p81_7BVZ7PQuI078WFn-g/edit)) document for additional information.
 
@@ -93,10 +101,7 @@ Rekor is backed by a transparency log, inspired by the one in Certificate Transp
 * Signature Algorithm:  ECDSA (NIST P-256).  
 * Public Key: change over time  
 * Log ID: need an OID  
-* Maximum Merge Delay: Rekor only returns after the merge is complete  
-* Maximum Chain Length: 10  
-* STH Frequency Count: N/A  
-* Final STH: N/A
+* Maximum Merge Delay: Rekor only returns after the merge is complete
 
 ### 3.3 Sharding