jiebi/TextFlow huggingface dataset:
Original text:
Custom policies may use additional information present in the ledger outside of claims.  For instance, issuers may have to register on the TS before claims can be accepted; a custom policy may be used to <del> enforce access control to the transparency service.  Similarly, policies may be used </del>  tbl-initial-named-policies defines an initial set of named policies that TS may decide to enforce.  This may be evolved in future drafts.

Reviewer comments:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Revised text:
Custom policies may use additional information present in the ledger outside of claims.  For instance, issuers may have to register on the TS before claims can be accepted; a custom policy may be used to  <ins> enforce access control to the transparency service.  Verifying the signature of the issuer is also a form of registration policy, but it is globally enforced in order to separate authentication and authorization, with policy only considering authentic inputs. </ins> tbl-initial-named-policies defines an initial set of named policies that TS may decide to enforce.  This may be evolved in future drafts.
Original text:
6. This section details the interoperability requirements for <del> implementers of claim issuance and validation libraries, and </del>  transparency services. 6.1.

Reviewer comments:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Revised text:
6. This section details the interoperability requirements for  <ins> implementers of claim issuance and validation libraries, and of </ins> transparency services. 6.1.
Original text:
serialization), ease of processing and availability of implementations. <del> At a high-level, a claim is a COSE single-signed object (i.e. "COSE_Sign1") that contains the correct set of protected headers. Although issuers and relays may attach unprotected headers to claims, transparency services and verifiers MUST NOT rely on the presence or value of unrpotected headers in claims during registration and validation. </del>  All claims MUST include the following protected headers: <del> algorithm (label: "1"): Asymmetric signature algorithm as integer, for example "-35" for ECDSA with SHA-384, see COSE Algorithms registry [2] </del>  issuer (label: "TBD", to be registered): DID (Decentralized <del> Identifier, see W3C Candidate Recommendation [3]) of the signer as string, for example "did:web:example.com" </del>  <del> feed (label: "TBD"): the issuer's name for the artifact </del>  <del> payload type (label: "3"): Media type of payload as string, for </del>  example "application/spdx+json" registration policy info (label: "TBD"): a map of additional <del> attributes to help enforce registration policies </del>  DID key selection hint (label: "TBD"): a DID method-specific <del> selector for the signing key </del>  Additionally, claims MAY carry the following unprotected headers:

Reviewer comments:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Revised text:
serialization), ease of processing and availability of implementations.  <ins> At a high-level that is the context of this architecture, a Claim is a COSE single-signed object (i.e.  "COSE_Sign1") that contains the correct set of protected headers.  Although issuers and relays may attach unprotected headers to claims, transparency services and verifiers MUST NOT rely on the presence or value of additional unprotected headers in claims during registration and validation. </ins> All claims MUST include the following protected headers:  <ins> algorithm (label: "1"): Asymmetric signature algorithm used by the claim issuer, as an integer, for example "-35" for ECDSA with SHA- 384, see COSE Algorithms registry [2]; </ins> issuer (label: "TBD", to be registered): DID (Decentralized  <ins> Identifier, see W3C Candidate Recommendation [3]) of the signer, as a string, for example "did:web:example.com"; </ins>  <ins> feed (label: "TBD"): the issuer's name for the artifact, as a string; </ins>  <ins> payload type (label: "3"): Media type of payload as a string, for </ins> example "application/spdx+json" registration policy info (label: "TBD"): a map of additional  <ins> attributes to help enforce registration policies; </ins> DID key selection hint (label: "TBD"): a DID method-specific  <ins> selector for the signing key, as a bytestring. </ins> Additionally, claims MAY carry the following unprotected headers:
Original text:
6.2. There are many types of statements (such as SBOMs, malware scans, <del> audit reports, policy definitions) that issuers may want to turn into claims.  The issuer must first decide on a suitable format to </del>  serialize the statement, such as: - JSON-SPDX - CBOR-SPDX - SWID - CoSWID - CycloneDX - in-toto - SLSA

Reviewer comments:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Revised text:
6.2. There are many types of statements (such as SBOMs, malware scans,  <ins> audit reports, policy definitions) that Issuers may want to turn into Claims.  The Issuer must first decide on a suitable format to </ins> serialize the statement, such as: - JSON-SPDX - CBOR-SPDX - SWID - CoSWID - CycloneDX - in-toto - SLSA
Original text:
The same claim may be independently registered in multiple TS.  To register a claim, the service performs the following steps: <del> Client authentication. </del>  <del> So far, implementation-specific, and unrelated to the issuer identity.  Claims may be registered by a different party than their issuer. Issuer identification.  The service must check that the ledger records a recent DID document for the "issuer" protected header of the envelope.  This MAY require that the service resolve the issuer DID and record the resulting document.  (See issuer identity above.) </del>  Envelope signature verification, as described in COSE signature, using the signature algorithm and verification key of the issuer

Reviewer comments:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Revised text:
The same claim may be independently registered in multiple TS.  To register a claim, the service performs the following steps:  <ins> Client authentication.  This is implementation-specific, and MAY be unrelated to the issuer identity.  Claims may be registered by a different party than their issuer. </ins>  <ins> Issuer identification.  The TS MUST store evidence of the DID resolution for the "issuer" protected header of the envelope and the resolved key manifest at the time of registration for auditing.  This MAY require that the service resolve the issuer DID and record the resulting document, or rely on a cache of recent resolutions. </ins> Envelope signature verification, as described in COSE signature, using the signature algorithm and verification key of the issuer
Original text:
6.4. <del> Trusted input for receipt verification: the identity and the public signature-verification key of the transparency service. These may be included in the verifier's trusted configuration, or determined by a trusted policy. Verification steps: Verify receipt (see I-D.birkholz-scitt-receipts). Verify issuer signature. Freshness/revocation? Validate format of the envelope contents. Once verified, the claims together with their authenticated issuer and transparent ledger identities can be used as input to an authorization policy. </del>  7.

Reviewer comments:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Revised text:
6.4.  <ins> This section provides additional implementation considerations, the high-level validation algorithm is described in validation, with the ledger-specific details of checking receipts are covered in I- D.birkholz-scitt-receipts. Before checking a claim, the verifier must be configured with one or more identities of trusted transparency services.  If more than one service is configured, the verifier MUST return which service the claim is registered on. In some scenarios, the verifier already expects a specific issuer and feed for the claim, while in other cases they are not known in advance and can be an output of validation.  Verifiers SHOULD offer a configuration to decide if the issuer's signature should be locally verified (which may require a DID resolution, and may fail if the manifest is not available or if the key is revoked), or if it should trust the validation done by the TS during registration. Some verifiers MAY decide to locally re-apply some or all of the registration policies if they have limited trust in the TS.  In addition, verifiers MAY apply arbitrary validation policies after the signature and receipt have been checked.  Such policies may use as input all information in the envelope, the receipt, and the payload, as well as any local state. Verifiers SHOULD offer options to store or share receipts in case they are needed to audit the TS in case of a dispute. </ins> 7.
Original text:
8.  8.1. 8.1.1.

Reviewer comments:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Revised text:
8. <ins> Editor's Note: this may be moved to appendix. </ins> 8.1. 8.1.1.
Original text:
9. <del> Privacy Considerations </del>  10. <del> Security Considerations </del>  11.

Reviewer comments:
NAME added security considerations and architecture picture
Thanks for the diagram, the sec-sec and all the other additional polish! I thought about tinkering with the diagram, but am in doubt that I'll improve it significantly. LGTM!

Revised text:
9.  <ins> Unless advertised by the TS, every issuer should treat its claims as public.  In particular, their envelope and statement should not carry any private information in plaintext. </ins> 10.  <ins> On its own, verifying a transparent claim does not guarantee that its envelope or contents are trustworthy--just that they have been signed by the apparent issuer and counter-signed by the TS.  If the verifier trusts the issuer, it can infer that the claim was issued with this envelope and contents, which may be interpreted as the issuer saying the artifact is fit for its intended purpose.  If the verifier trusts the TS, it can independently infer that the claim passed the TS registration policy and that has been persisted in the ledger. Unless advertised in the TS registration policu, the verifier should not assume that the ordering of transparent claims in the ledger matches the ordering of their issuance. Similarly, the fact that an issuer can be held accountable for its transparent claims does not on its own provide any mitigation or remediation mechanism in case one of these claims turned out to be misleading or malicious--just that signed evidence will be available to support them. Issuers SHOULD ensure that the statements in their claims are correct and unambiguous, for example by avoiding ill-defined or ambiguous formats that may cause verifiers to interpret the claim as valid for some other purpose. Issuers and Transparency Services SHOULD carefully protect their private signing keys and avoid these keys for any purpose not described in this architecture.  In case key re-use is unavoidable, they MUST NOT sign any other message that may be verified as an envelope. </ins> 11.
Original text:
There are many types of Statements (such as SBOMs, malware scans, audit reports, policy definitions) that Issuers may want to turn into Claims.  The Issuer must first decide on a suitable format to <del> serialize the Statement, such as: - JSON-SPDX - CBOR-SPDX - SWID - CoSWID - CycloneDX - in-toto - SLSA </del>  Once the Statement is serialized with the correct content type, the Issuer should fill in the attributes for the Registration policy

Reviewer comments:
Cleaning up the Federation section, still TBD.
Also:
Linting errors need to be addressed. NAME if this blocks publishing / merging perhaps we can merge and then fix?
Yes, I can fix the lint after merging. If this would be a branch and not a fork, I could do it here more easily.
lgtm, any objections? still in early stage

Revised text:
There are many types of Statements (such as SBOMs, malware scans, audit reports, policy definitions) that Issuers may want to turn into Claims.  The Issuer must first decide on a suitable format to  <ins> serialize the Statement, such as: JSON-SPDX CBOR-SPDX SWID CoSWID CycloneDX in-toto SLSA </ins> Once the Statement is serialized with the correct content type, the Issuer should fill in the attributes for the Registration policy
Original text:
7. <del> We explain how multiple, independent Transparency Services can be composed to distribute supply chains without a single transparency authority trusted by all parties. Multiple SCITT instances, governed and operated by different organizations. For example, - a small, simple SCITT instance may keep track specifically of the software used for operating SCITT services.  - an air-gapped data center may operate its own SCITT Registry to retain full control and auditing of its software supplies. </del>  <del> How? - Policy-based.  Within an organization, local Verifiers contact an authoritative SCITT that records the latest policies associated with classes of Artifacts; these policies indicate which Issuers and Registries are trusted for verifying signed Transparent Claims for these Artifacts. </del>  <del> Other federation mechanisms? </del>  <del> We'd like to attach multiple Receipts to the same signed Claims, each Receipt endorsing the Issuer signature and a subset of prior Receipts.  This involves down-stream Registries verifying and recording these Receipts before issuing their own Receipts. </del>  8. <del> Editor's Note: this may be moved to appendix. </del>  8.1.

Reviewer comments:
Cleaning up the Federation section, still TBD.
Also:
Linting errors need to be addressed. NAME if this blocks publishing / merging perhaps we can merge and then fix?
Yes, I can fix the lint after merging. If this would be a branch and not a fork, I could do it here more easily.
lgtm, any objections? still in early stage

Revised text:
7.  <ins> Editor's note: This section needs work. </ins>  <ins> 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 SCITT instances may be governed and operated by different organizations that do not trust one another. </ins>  <ins> This may involve registering the same Claims at different transparency services, each with their own purpose and registration policy.  This may also involve attaching multiple Receipts to the same Claims, each Receipt endorsing the Issuer signature and a subset of prior Receipts, and each TS verifying prior Receipts as part of their registration policy. </ins>  <ins> For example, a supplier TS may provide a complete, authoritative Registry for some kind of Claims, whereas a consumer TS may collect different kinds of Claims to ensure complete auditing for a specific use case, and possibly require additional reviews before registering some of these claims. </ins> 8.  <ins> Editor's Note: This may be moved to appendix. </ins> 8.1.
Original text:
Claim Issuer, as an integer, for example "-35" for ECDSA with SHA- 384, see COSE Algorithms registry [2]; <del> Issuer (label: "TBD", to be registered): DID (Decentralized </del>  Identifier, see W3C Candidate Recommendation [3]) of the signer, as a string, for example "did:web:example.com"; <del> Feed (label: "TBD"): the Issuer's name for the Artifact, as a string; </del>  payload type (label: "3"): Media type of payload as a string, for example "application/spdx+json" <del> Registration policy info (label: "TBD"): a map of additional attributes to help enforce Registration policies; </del>  <del> DID key selection hint (label: "TBD"): a DID method-specific selector for the signing key, as a bytestring. </del>  Additionally, Claims MAY carry the following unprotected headers: <del> Receipts (label: "TBD", to be registered): Array of Receipts, </del>  defined in In CDDL RFC8610 notation, the Envelope is defined as follows:

Reviewer comments:
This adds temporary integer header parameter labels to have something to prototype against until the new fields are registered. I used 391 as starting offset as that's S+C+I+T+T.

Revised text:
Claim Issuer, as an integer, for example "-35" for ECDSA with SHA- 384, see COSE Algorithms registry [2];  <ins> Issuer (label: "TBD", temporary: "391"): DID (Decentralized </ins> Identifier, see W3C Candidate Recommendation [3]) of the signer, as a string, for example "did:web:example.com";  <ins> Feed (label: "TBD", temporary: "392"): the Issuer's name for the Artifact, as a string; </ins> payload type (label: "3"): Media type of payload as a string, for example "application/spdx+json"  <ins> Registration policy info (label: "TBD", temporary: "393"): a map of additional attributes to help enforce Registration policies; </ins>  <ins> Key ID (label: "4"): Key ID, as a bytestring. </ins> Additionally, Claims MAY carry the following unprotected headers:  <ins> Receipts (label: "TBD", temporary: "394"): Array of Receipts, </ins> defined in In CDDL RFC8610 notation, the Envelope is defined as follows:
Original text:
The Receipt structure is a CBOR array with two items, in order: <del> "service_id": The service identifier as tstr. </del>  "contents": The proof as a CBOR structure determined by the tree algorithm.

Reviewer comments:
Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.

Revised text:
The Receipt structure is a CBOR array with two items, in order:  <ins> "protected": The protected header of the countersigner. </ins> "contents": The proof as a CBOR structure determined by the tree algorithm.
Original text:
The following parameters MUST be included in the protected header of the countersigner (sign_protected in cose_sign1_countersign):  Issued At (label: TBD): The time at which the countersignature was issued as the number of seconds from 1970-01-01T00:00:00Z UTC, ignoring leap seconds.

Reviewer comments:
Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.

Revised text:
The following parameters MUST be included in the protected header of the countersigner (sign_protected in cose_sign1_countersign): <ins> Service ID (label: TBD): The Service identifier, as defined in the Transparency Service parameters. </ins> Issued At (label: TBD): The time at which the countersignature was issued as the number of seconds from 1970-01-01T00:00:00Z UTC, ignoring leap seconds.
Original text:
length "HASH_SIZE". "leaf_info": auxiliary inputs to recompute the leaf digest <del> included in the Merkle tree: the internal hash, the internal data, and the protected header of the countersigner. </del>  "internal_hash" MUST be a bytestring of length "HASH_SIZE";

Reviewer comments:
Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.

Revised text:
length "HASH_SIZE". "leaf_info": auxiliary inputs to recompute the leaf digest  <ins> included in the Merkle tree: the internal hash and the internal data. </ins> "internal_hash" MUST be a bytestring of length "HASH_SIZE";
Original text:
5.5. <del> Given the TS parameters, a signed envelope, and a Receipt for it, the following steps must be followed to verify this Receipt. </del>  Verify that the Receipt Content structure is well-formed, as described in ReceiptContents. Construct a "Countersign_structure" as described in <del> cose_sign1_countersign, using "sign_protected" from the "leaf_info" field of the receipt contents. </del>  Compute "LeafBytes" as the bytestring concatenation of the internal hash, the hash of internal data, and the hash of the

Reviewer comments:
Given that all tree algorithms must include a protected header of the countersigner, it makes sense to move that to the top as a common structure. This serves two purposes: inspecting the protected header without verifying the receipt (useful if verification happened elsewhere and a tree-algorithm-agnostic service wants to index general information about the receipt), and allowing for more flexible key discovery schemes in the future that would rely on information in the protected header. Note that this change is independent of the discussions in the mailing list around COSE countersignatures.

Revised text:
5.5.  <ins> Given a signed envelope and a Receipt for it, the following steps must be followed to verify this Receipt. Decode the protected header of the Receipt and look-up the TS parameters using the service_id field. </ins> Verify that the Receipt Content structure is well-formed, as described in ReceiptContents. Construct a "Countersign_structure" as described in  <ins> cose_sign1_countersign, using the protected header of the Receipt as "sign_protected". </ins> Compute "LeafBytes" as the bytestring concatenation of the internal hash, the hash of internal data, and the hash of the