jiebi/TextFlow huggingface dataset:
Original text:
5.2.2.  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

Reviewer comments:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Revised text:
5.2.2. <ins> 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 5.2.3. </ins> 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
Original text:
specification leaves the implementation of the Registration Policy to the provider of the Transparency Services and its users.  As a minimum, a Transparency Service MUST authenticate the Issuer of the Signed Statement, which requires some form of trust anchor.  As defined in RFC6024, "A trust anchor represents an authoritative

Reviewer comments:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Revised text:
specification leaves the implementation of the Registration Policy to the provider of the Transparency Services and its users. <ins> 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. </ins> As a minimum, a Transparency Service MUST authenticate the Issuer of the Signed Statement, which requires some form of trust anchor.  As defined in RFC6024, "A trust anchor represents an authoritative
Original text:
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>  There are many different candidate verifiable data structures that may be used to implement an Append-only Log, such as chronological

Reviewer comments:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Revised text:
key or other structure, as appropriate.  It can be a non-root certificate when it is a certificate.  <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
Original text:
parallel but the Transparency Service is then responsible for proving their mutual consistency. <del> 5.2.3.1. </del>  A Transparency Service is append-only.  Once a Signed Statement is registered and becomes a Transparent Statement, it cannot be

Reviewer comments:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Revised text:
parallel but the Transparency Service is then responsible for proving their mutual consistency.  <ins> 5.2.4.1. </ins> A Transparency Service is append-only.  Once a Signed Statement is registered and becomes a Transparent Statement, it cannot be
Original text:
Append-only Log becomes immutable, and the Receipt provides universally-verifiable evidence of this property. <del> 5.2.3.2. </del>  There is no fork in the Append-only Log.  Everyone with access to its contents sees the same sequence of entries, and can check its

Reviewer comments:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Revised text:
Append-only Log becomes immutable, and the Receipt provides universally-verifiable evidence of this property.  <ins> 5.2.4.2. </ins> There is no fork in the Append-only Log.  Everyone with access to its contents sees the same sequence of entries, and can check its
Original text:
state of the Append-only Log, encoded in an old Receipt, is consistent with the current Append-only Log state. <del> 5.2.3.3. </del>  Everyone with access to the Transparency Service can check the correctness of its contents.  In particular:

Reviewer comments:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Revised text:
state of the Append-only Log, encoded in an old Receipt, is consistent with the current Append-only Log state.  <ins> 5.2.4.3. </ins> Everyone with access to the Transparency Service can check the correctness of its contents.  In particular:
Original text:
a Transparency Service MAY additionally support verifiability of client authentication and access control <del> 5.2.3.4. </del>  Transparency Services MAY document their governance rules and procedures for operating the Transparency Service and updating its

Reviewer comments:
Extending the architecture with Transparent Statements recording the Transparency Service configuration, notably its registration policy. The syntax of the configuration (notably its supported registration policies) are still TBC.

Revised text:
a Transparency Service MAY additionally support verifiability of client authentication and access control  <ins> 5.2.4.4. </ins> Transparency Services MAY document their governance rules and procedures for operating the Transparency Service and updating its
Original text:
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>  The version of the key from the DID Document used to sign the Signed Statement is written in the "4 kid" protected header.

Reviewer comments:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Revised text:
issued with those keys. The Issuer's DID is required and appears in the "1 iss" claim of the  <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.
Original text:
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>  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>  Some Verifiers may systematically resolve Issuer DIDs to fetch the latest corresponding DID documents.  This behavior strictly enforces

Reviewer comments:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Revised text:
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,  <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  <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
Original text:
<del> (label: "13" pending CWT_CLAIM_COSE): A CWT representing the </del>  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

Reviewer comments:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Revised text:
 <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
Original text:
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>  and "sub" claims. Issuers MUST ensure that the Statement payloads in their Signed

Reviewer comments:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Revised text:
will be available to support them. An Issuer that knows of a changed state of quality for an Artifact,  <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
Original text:
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>  application specific, and out of scope of the SCITT Architecture. Verifiers and Auditors need not be trusted by other actors.  In

Reviewer comments:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Revised text:
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  <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
Original text:
Append-only Log, some Transparency Services may provide limited support for historical queries on the Signed Statements they have registered, and accept the risk of being blamed for inconsistent <del> Registration or Issuer equivocation. </del>  Verifiers and Auditors may also witness (1, 4) but may not be able to collect verifiable evidence for it.

Reviewer comments:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Revised text:
Append-only Log, some Transparency Services may provide limited support for historical queries on the Signed Statements they have registered, and accept the risk of being blamed for inconsistent  <ins> Registration or Issuer Equivocation. </ins> Verifiers and Auditors may also witness (1, 4) but may not be able to collect verifiable evidence for it.
Original text:
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>  claims. The confidentiality of any identity lookup during Signed Statement

Reviewer comments:
Define equivocation and non-equivocation and cite the article that coined the term in analyzing Lamport. Closes ietf-wg-scitt/draft-ietf-scitt-architecture.
I think this reference from the CT rfc is useful. URL "and (2) by violating its append-only property by presenting two different, conflicting views of the Merkle Tree at different times and/or to different parties." this is equivocation. If we replace "Merkle Tree" with "collection of statements". And that reference is also careful to cast things interms of detectability rather than prevention
This is very useful, thanks. I will adjust with this and your other feedback, most appreciated!
Who reads papers anyway? Jokes aside, thanks for the contributions and making me think about how to communicate clearly on this one.
Define the term non-equivocation formally as it relates to this architecture document, per URL
I like those changes. Reads clean to me thanksLGTM Thanks, NAME for the iterations. This was a tricky one to summarize an entire paper in a few sentences

Revised text:
to notify Transparency Services of credential revocation to stop Verifiers from accepting Signed Statements signed with compromised credentials.  Issuers SHOULD register new Signed Statements  <ins> indicating the revocation, using the same "15" CWT "iss" and "sub" </ins> claims. The confidentiality of any identity lookup during Signed Statement
Original text:
<del> (label: "15" pending CWT_CLAIM_COSE): A CWT representing the </del>  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

Reviewer comments:
simplified a few references & added a WG, some reordering
Thanks, NAME
A small fix and then it will be ready to it.LGTM!LGTM

Revised text:
 <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
Original text:
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>  plaintext.  9. On its own, verifying a Transparent Statement does not guarantee that

Reviewer comments:
This PR elaborates on the privacy analysis a bit. Describe why it is important (because we cannot delete items from the log) Remove the BCP 14 keyword (MUST NOT). Both the Privacy and Security Considerations sections should have the character of an analysis. They should be recommendations, or highlight gotchas to implementors. Anything binding should be in the main body of the RFC. Yes, this would need to be fixed in the Security Considerations, too. Expand the "Unless advertised by a Transparency Service" phrase into a paragraph about access control. This way it's more actionable. (Why would you advertise it? When would it be okay to advertise?)
Authors: (NAME NAME NAME NAME NAME I'm inclined to merge this as is. Any disagreements, or additional changes? We can iterate afterward, but seems like a good baseline to add
Yes. this looks pretty stable and uncontroversial. Thanks a ton, NAME

Revised text:
8.  <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
Original text:
10.1. This section requests registration of the following media types <del> [@RFC2046] in the "Media Types" registry [@IANA.MediaTypes] in the manner described in [@RFC6838]. </del>  To indicate that the content is an scitt configuration represented as JSON:

Reviewer comments:
This PR addresses: URL Related issues: URL
Some additional details on the construction and use can be found here: URL I'm not including these in the PR, because I don't understand the security properties required by "SCITT Identifiers", but if the code I wrote covers the security properties, I am happy to do a follow up PR, after this one is merged.
LGTM for the consistency of CBOR structures

Revised text:
10.1. This section requests registration of the following media types  <ins> RFC2046 in the "Media Types" registry IANA.media-types in the manner described in RFC6838. </ins> To indicate that the content is an scitt configuration represented as JSON: