jiebi/CodeConvo huggingface dataset:
key or other structure, as appropriate.  It can be a non-root certificate when it is a certificate. <del> A provider of a Transparency Service is, however, expected to indicate what Registration Policy is used in a given deployment and inform its users about changes to the Registration Policy. 5.2.3. </del> <ins> 5.2.4. </ins> There are many different candidate verifiable data structures that may be used to implement an Append-only Log, such as chronological
issued with those keys. The Issuer's DID is required and appears in the "1 iss" claim of the <del> "13 CWT_Claims" protected header of the Signed Statements' Envelope. </del> <ins> "15 CWT_Claims" protected header of the Signed Statements' Envelope. </ins> The version of the key from the DID Document used to sign the Signed Statement is written in the "4 kid" protected header.
Some Verifiers may systematically fetch all Transparent Statements using the CWT_Claims Subject and assess them alongside the Transparent Statement they are verifying to ensure freshness, <del> completeness of evidence, and the promise of non-equivocation. </del> <ins> completeness of evidence, and Non-equivocation. </ins> Some Verifiers may choose to subset the collection of Statements, filtering on the payload type (Protected Header "3"), the CWT <del> (Protected Header "13") Issuer claim, or other non-opaque properties. </del> <ins> (Protected Header "15") Issuer claim, or other non-opaque properties. </ins> Some Verifiers may systematically resolve Issuer DIDs to fetch the latest corresponding DID documents.  This behavior strictly enforces
<del> (label: "13" pending CWT_CLAIM_COSE): A CWT representing the </del> <ins> (label: "15" pending CWT_CLAIM_COSE): A CWT representing the </ins> Issuer ("iss") making the statement, and the Subject ("sub") to correlate a collection of statements about an Artifact. Additional CWT_CLAIMS MAY be used, while "iss" and "sub" MUST be
will be available to support them. An Issuer that knows of a changed state of quality for an Artifact, <del> SHOULD Register a new Signed Statement, using the same "13" CWT "iss" </del> <ins> SHOULD Register a new Signed Statement, using the same "15" CWT "iss" </ins> and "sub" claims. Issuers MUST ensure that the Statement payloads in their Signed
In both cases, the SCITT Architecture provides generic, universally- verifiable cryptographic proof to individually blame Issuers or the Transparency Service.  On one hand, this enables valid actors to <del> detect and disambiguate malicious actors who issue contradictory Signed Statements to different entities (Verifiers, Auditors, Issuers), otherwise known as 'equivocation'.  On the other hand, their liability and the resulting damage to their reputation are </del> <ins> detect and disambiguate malicious actors who employ Equivocation with Signed Statements to different entities.  On the other hand, their liability and the resulting damage to their reputation are </ins> application specific, and out of scope of the SCITT Architecture. Verifiers and Auditors need not be trusted by other actors.  In
to notify Transparency Services of credential revocation to stop Verifiers from accepting Signed Statements signed with compromised credentials.  Issuers SHOULD register new Signed Statements <del> indicating the revocation, using the same "13" CWT "iss" and "sub" </del> <ins> indicating the revocation, using the same "15" CWT "iss" and "sub" </ins> claims. The confidentiality of any identity lookup during Signed Statement
<del> (label: "15" pending CWT_CLAIM_COSE): A CWT representing the </del> <ins> (label: "15" pending CWT_CLAIMS_COSE): A CWT representing the </ins> Issuer ("iss") making the statement, and the Subject ("sub") to correlate a collection of statements about an Artifact. Additional CWT_CLAIMS MAY be used, while "iss" and "sub" MUST be
8. <del> Unless advertised by a Transparency Service, every Issuer must treat Signed Statements it registered (rendering them as Transparent Statements) as public.  In particular, a Signed Statement Envelope and Statement payload MUST NOT carry any private information in </del> <ins> Transparency Services are often publicly accessible.  Issuers should treat Signed Statements (rendering them as Transparent Statements) as publicly accessible.  In particular, a Signed Statement Envelope and Statement payload should not carry any private information in </ins> plaintext. <ins> Transparency Services can have an authorization policy controlling who can access the Append-only Log.  While this can be used to limit who can read the Log, it may also limit the usefulness of the system. Some jurisdictions have a Right to be Forgotten.  However, once a Signed Statement is inserted into the Append-only Log maintained by a Transparency Service, it cannot be removed from the Log. </ins> 9. On its own, verifying a Transparent Statement does not guarantee that
enforcing a Registration Policy.  It also maintains a service key, which is used to endorse the state of the Append-only Log in Receipts.  All Transparency Services MUST expose standard endpoints <del> for Registration of Signed Statements and Receipt issuance, which is described in TODO: scrapi.  Each Transparency Service also defines its own Registration Policies, which MUST apply to all entries in the Append-only Log. </del> <ins> for Registration of Signed Statements and Receipt issuance.  Each Transparency Service also defines its own Registration Policies, which MUST apply to all entries in the Append-only Log. </ins> The combination of Identity, Registration Policy evaluation, and the Transparency Service endpoint constitute the trusted part of the
5.1.3. <ins> An Issuer can make multiple Statements about the same Artifact.  For example, an Issuer can make amended Statements about the same Artifact as their view changes over time. Multiple Issuers can make different, even conflicting Statements, about the same Artifact.  Verifiers can choose which Issuers they trust. Multiple Issuers can make the same Statement about a single Artifact, affirming multiple Issuers agree. 5.1.4. </ins> SCITT payloads are opaque to Transparency Services.  For interoperability, Registration Policy decisions should be based on interpretation of the mandatory metadata in the protected header of a
CT logs produce Signed Certificate Timestamps (Transparent Statements) <del> SCTs are checked by browsers (Verifiers) </del> <ins> Signed Certificate Timestamps are checked by Verifiers. </ins> <del> The Append-only Log can be checked by Auditors Note that just like CT logs are independent and their contents need not be consistent, Transparency Services are similarly independent of each other. </del> <ins> The Append-only Log can be checked by Verifiers and Auditors </ins> 3.
Anyone with access to the Transparency Service can independently verify its consistency and review the complete list of Transparent <del> Statements registered by each Issuer.  However, the Registrations of </del> <ins> Statements registered by each Issuer.  However, the Registrations on </ins> separate Transparency Services are generally disjoint, though it is <del> possible to take a Transparent Statement from one Transparency Service and register it again on another (if its policy allows), so the authorization of the Issuer and of the Transparency Service by the Verifier of the Receipt are generally independent. </del> <ins> possible to take a Transparent Statement, a Signed Statement with a Receipt from the first Transparency Service in its unprotected header, and register it on another Transparency Service, where the second receipt will be over the first Receipt in the unprotected header. </ins> Reputable Issuers are thus incentivized to carefully review their Statements before signing them to produce Signed Statements.
Receipts for the software and configuration of the service, as measured in its attestation report. <del> 5.2.2. The Transparency Service records its configuration in the Append-Only Log using Transparent Statements with distinguished media type "application/scitt-configuration". The registration policy for statements with the media type suffix ("+<format>" is implementation-specific.  The implementation SHOULD document them, for example defining the Issuers authorized to register configuration Signed Statements. The Transparency Service is configured by the last Transparent Statement of this type.  The Transparency Service MUST register a Signed Statement that defines its initial configuration before registering any other Signed Statement.  The Transparency Service MAY register an additional Signed Statement that updates its configuration. The Transparency Service provides an endpoint that returns the Transparent Statement that describes its current configuration. The configuration "reg_info" SHOULD include a secure version number and a timestamp. The sample configuration payload uses the CDDL </del> 5.2.3. <del> Authorization is needed prior to registration of Signed Statements to ensure completeness of an audit.  A Transparency Service that registers valid Signed Statement offered by anonymous Issuers would provide limited to no value to Verifiers.  More advanced use case will rely on the Transparency Service performing additional domain- specific checks before a Signed Statement is accepted.  For example, some Transparency Services may validate the non-opaque content (payload) of Signed Statements. </del> Registration Policies refers to the checks that are performed before <del> a Signed Statement is registered given a set of input values.  This specification leaves the implementation of the Registration Policy to the provider of the Transparency Services and its users. A provider of a Transparency Service indicates what Registration Policy is used in a given deployment and inform its users about changes to the Registration Policy by issuing and registering configuration statements. </del> <ins> a Signed Statement is added to an append only log, and a corrosponding receipt becomes available. </ins> As a minimum, a Transparency Service MUST authenticate the Issuer of the Signed Statement, which requires some form of trust anchor.  As
use is unavoidable, keys MUST NOT sign any other message that may be verified as an Envelope as part of a Signed Statement. <ins> Each of these functions MUST be carefully protected against both external attacks and internal misbehavior by some or all of the operators of the Transparency Service. For instance, the code for the Registration Policy evaluation and endorsement may be protected by running in a Trusted Execution Environment (TEE). The Transparency Service may be replicated with a consensus algorithm, such as Practical Byzantine Fault Tolerance (pBFT PBFT) and may be used to protect against malicious or vulnerable replicas. Threshold signatures may be use to protect the service key, etc. </ins> 9.1. SCITT provides the following security guarantees:
11.1.  URIs <del> [1] https://www.iana.org/assignments/cwt/cwt.xhtml#claims-registry [2] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ </del> <ins> [1] https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/ </ins> issues/79
5. <del> This topic is still under discussion, see issue 79 [1] </del> <ins> Transparency Services MAY have Registration Policies that require Receipts from other Transparency Services to be included in the Unprotected Header of Signed Statements at the time of Registration. </ins> <del> Multiple, independently-operated Transparency Services can help secure distributed supply chains, without the need for a single, centralized service trusted by all parties.  For example, multiple Transparency Service instances may be governed and operated by different organizations that are either unaware of the other or do not trust one another. </del> <ins> Transparency Services MUST reject Signed Statements that are invalid according to their Registration Policy, which can include requirements associated with the unprotected bytes comprising the cose-sign1 unprotected header. </ins> <del> This may involve registering the same Signed Statements at different Transparency Services, each with their own purpose and Registration Policy. </del> <ins> A Receipt for a Transparent Statement, proves that a Transparent Statement is included in an Append-only Log. </ins> <del> This may also involve attaching multiple Receipts to the same Signed Statements. </del> <ins> Receipts for Transparent Statements, are a special case of Receipts for Signed Statements. Verifying Receipts for Transparent Statements can be difficult. Transparency Services SHOULD copy the unprotected header they observed at the time of registration into the Protected Header of their Receipt. This ensures that the exact bytes which they have included in their append only log, can be reconstructed, even though some of those bytes lacked integrited protection, due to being located in the unprotected header of a Signed Statement. </ins> <del> For example, a software producer of a supply chain artifact might rely on multiple independent software producers operating transparency services for their upstream artifacts.  Downstream producers benefit from upstream producers providing higher transparency regarding their artifacts. </del> <ins> Depending on the complexity of the unprotected header, additional cannonicalization operations MAY be required in order to recover the exact bytes that were included in the Append-only Log of a specific Transparency Service. Implementers are cautioned that maintaining the order of Receipts in the unprotected header is essential for uniquely identifying a Signed Statement with a specific series of Receipts in its unprotected header. </ins> 6.
4.2.1. <del> The same Signed Statement may be independently registered in multiple Transparency Services.  To register a Signed Statement, the Transparency Service performs the following steps: </del> <ins> To register a Signed Statement, the Transparency Service performs the following steps: </ins> <del> This is implementation-specific and MAY be unrelated to the Issuer identity.  Signed Statements may be registered by a different party than their Issuer. </del> <ins> A Client authenticates with the Transparency Service, to Register Signed Statements.  Authentication and authorization is implementation-specific, and out of scope of the SCITT Architecture. </ins> The Transparency Service MUST perform resolution of the Issuer's <del> identity.  This step may require that the service retrieves the Issuer ID in real-time, or rely on a cache of recent resolutions. For auditing, during Registration, the Transparency Service MUST store evidence of the lookup, including if it was resolved from a cache. </del> <ins> identity, which may be different than the Client identity.  This step may require that the service retrieves the Issuer ID in real- time, or rely on a cache of recent resolutions.  For auditing, during Registration, the Transparency Service MUST store evidence of the lookup, including if it was resolved from a cache. </ins>
4.1. <del> An important function of a Transparency Service is to maintain Registration Policies for the Append-only Log.  The Append-only Log is the verifiable data structure which registers Signed Statements and supports the production of Receipts. </del> <ins> Transparency Services MUST feature an Append-only Log.  The Append- only Log is the verifiable data structure that registers Signed Statements and supports the production of Receipts. </ins> All Transparency Services MUST expose APIs for the registration of Signed Statements and issuance of Receipts.
discovered out of band and Registration Policies are not assured on the presence of these optional fields.  A Registration Policy that requires an optional field to be present MUST reject any Signed <del> Statements or Receipts that an invalid according to the policy. </del> <ins> Statements or Receipts that are invalid according to the policy. </ins> fig-signed-statement-edn illustrates a payload that is detached. This is to support very large supply chain artifacts, and to ensure
4.1.1.1. Transparency Services MUST, at a minimum, perform the following <del> checks before registering a Signed Statement: * Authenticate the Issuer of the Signed Statement </del> <ins> checks before registering a Signed Statement: Authenticate the Issuer of the Signed Statement </ins> The Transparency Service MUST authenticate the Issuer of Signed Statements by validating the COSE signature and checking the identity
any Signed Statements, a means is required to configure the first Registration Policy that is not the standard issuance of a Signed Statement.  Transparency Services MUST support at least one of these <del> methods: * A built-in default Registration Policy * Acceptance of a first Signed Statement whose payload is a valid Registration Policy, without performing registration checks * An out-of-band authenticated management interface </del> <ins> methods: A built-in default Registration Policy Acceptance of a first Signed Statement whose payload is a valid Registration Policy, without performing registration checks An out-of-band authenticated management interface </ins> 4.1.3.
Signed Statements presented for Registration.  Some Transparency Services may publish every Signed Statement in their logs, to facilitate their dissemination and auditing.  Others may just return <del> Receipts to clients that present Singed Statements for Registration, </del> <ins> Receipts to clients that present Signed Statements for Registration, </ins> and disclose the Append-only Log only to Auditors trusted with the confidentiality of its contents.
SCITT architecture.  Its goal is to enhance auditability and accountability across supply chains. <del> In supply chains, artifacts travel down the chain until they are eventually consumed by someone.  Consumers like to have information about the artifacts that they consume.  There are many parties who publish information about artifacts: For example, the original manufacturer may provide information about the state of the artifact when it left the factory.  The shipping company may add information about the transport environment of the artifact.  Compliance auditors may provide information about their compliance assessment of the </del> <ins> In supply chains, downstream artifacts are built upon upstream artifacts.  The complexity of traceability and quality control for these supply chains increases with the number of artifacts and parties contributing to them.  There are many parties who publish information about artifacts: For example, the original manufacturer may provide information about the state of the artifact when it left the factory.  The shipping company may add information about the transport environment of the artifact.  Compliance auditors may provide information about their compliance assessment of the </ins> artifact.  Security companies may publish vulnerability information <del> about an artifact.  Consumers may even publish the fact that they consume an artifact. </del> <ins> about an artifact.  Some of these parties may publish information about their analysis or use of an artifact. </ins> <del> SCITT provides a way for consumers to obtain this information in a way that is "transparent", that is, parties cannot lie about the </del> <ins> SCITT provides a way for Relying Parties to obtain this information in a way that is "transparent", that is, parties cannot lie about the </ins> information that they publish without it being detected.  SCITT achieves this by having producers publish information in a <del> Transparency Service, where consumers (also called Verifiers) can check the information. </del> <ins> Transparency Service, where Relying Parties can check the information. </ins> 1.1.
wrapper format for Receipts, which specifies the Transparency Service identity and the agility parameters for the Signed Inclusion Proofs. Most of the details of the Receipt's contents are specified in the <del> COSE Signed Merkle Tree Proof document I-D.draft-steele-cose-merkle- </del> <ins> COSE Signed Merkle Tree Proof document I-D.draft-ietf-cose-merkle- </ins> tree-proofs. This section describes at a high level, the three main roles and
A Receipt is a Signed Statement, (cose-sign1), with addition claims in its protected header related to verifying the inclusion proof in <del> its unprotected header.  See I-D.draft-steele-cose-merkle-tree- proofs. </del> <ins> its unprotected header.  See I-D.draft-ietf-cose-merkle-tree-proofs. </ins> fig-signed-statement-cddl illustrates a normative CDDL definition for of the protected header for Signed Statements and Receipts.
Statement a Transparent Statement is produced. Receipts are based on Signed Inclusion Proofs as described in COSE <del> Signed Merkle Tree Proofs (I-D.draft-steele-cose-merkle-tree-proofs). </del> <ins> Signed Merkle Tree Proofs (I-D.draft-ietf-cose-merkle-tree-proofs). </ins> The registration time is defined as the timestamp at which the Transparency Service has added this Signed Statement to its Append-
Verifiers MUST apply the verification process as described in Section 4.4 of RFC9052. <del> In order to verify the inclusion proof that is included in the Receipt, the verification process for the inclusion proof MUST be performed as described in the document that registers corresponding Verifiable Data Structure Parameters (see I-D.draft-steele-cose- merkle-tree-proofs). APIs exposing verification logic for Transparent Statements may wish to provide more details that a single boolean result, for example, indicating if the signature on the Receipt or Signed Statement is valid, if claims related to the validity period are valid, or if the inclusion proof in the Receipt is valid. </del> <ins> APIs exposing verification logic for Transparent Statements may provide more details than a single boolean result.  For example, an API may indicate if the signature on the Receipt or Signed Statement is valid, if claims related to the validity period are valid, or if the inclusion proof in the Receipt is valid. </ins> The algorithm-specific details of checking inclusion proofs are <del> covered in I-D.draft-steele-cose-merkle-tree-proofs.  The pseudo-code </del> <ins> covered in I-D.draft-ietf-cose-merkle-tree-proofs.  The pseudo-code </ins> for validation of a transparent statement is as follows: Before checking a Transparent Statement, the Verifier must be
registration. Registration Policies MUST be made transparent and available to all <del> clients of the Transparency Service by registering them as Signed Statements on the Append-only Log. </del> <ins> Relying Parties of the Transparency Service by registering them as Signed Statements on the Append-only Log, and distributing associated Receipts.  Distribution of Receipts is out of scope for this document.``` </ins> This specification leaves implementation, encoding and documentation of Registration Policies to the operator of the Transparency Service.
<del> A Client authenticates with the Transparency Service, to Register Signed Statements.  Authentication and authorization is implementation-specific, and out of scope of the SCITT Architecture. </del> <ins> A client application authenticates with the Transparency Service, to Register Signed Statements on behalf of one or more issuers. Authentication and authorization is implementation-specific, and out of scope of the SCITT Architecture. </ins> The Transparency Service MUST perform resolution of the Issuer's <del> identity, which may be different than the Client identity.  This step may require that the service retrieves the Issuer ID in real- time, or rely on a cache of recent resolutions.  For auditing, during Registration, the Transparency Service MUST store evidence of the lookup, including if it was resolved from a cache. </del> <ins> identity.  This step may require that the service retrieves the Issuer ID in real-time, or rely on a cache of recent resolutions. For auditing, during Registration, the Transparency Service MUST store evidence of the lookup, including if it was resolved from a cache. </ins>