jiebi/TextFlow huggingface dataset:
Original text:
in read-only memory, (B) a bootloader, and (C) an operating system kernel. <del> The first Attesting Environment, the read-only BIOS in this example, has to ensure the integrity of the bootloader (the first Target </del>  Environment).  There are potentially multiple kernels to boot, and the decision is up to the bootloader.  Only a bootloader with intact integrity will make an appropriate decision.  Therefore, the Claims

Reviewer comments:
Changes "read-only BIOS" to "ROM" to align with the diagram
I think the text “the read-only BIOS in this example, has to ensure the integrity of the bootloader” is wrong since the example no longer has a “read-only BIOS” component. It should say “ROM” to be consistent. If ROM is determined to be ambiguous as a Root of Trust and we decide to changed it to "RoT" then this sentence would be updated accordingly.
NAME do you want to fix this still?
I'll add it to my list.

Revised text:
in read-only memory, (B) a bootloader, and (C) an operating system kernel.  <ins> The first Attesting Environment, the ROM in this example, has to ensure the integrity of the bootloader (the first Target </ins> Environment).  There are potentially multiple kernels to boot, and the decision is up to the bootloader.  Only a bootloader with intact integrity will make an appropriate decision.  Therefore, the Claims
Original text:
whether in the same conveyance protocol as part of the Evidence or not.  4. RFC4949 has defined a number of terms that are also used in this

Reviewer comments:
attempt to provide forward reference as requested on Monday
This looks good to me, although I wonder whether the sentence would make more sense at the end of the "Implementation Considerations" section (a couple lines earlier in the document). I am ok either way.
Works for me. That would put that into section 1.
"artifacts are defined by which roles produce them or consume them" - This sentence structure seems awkward. Is "artifacts are defined by the roles that produce or consume them" better?LGTM

Revised text:
whether in the same conveyance protocol as part of the Evidence or not. <ins> As explained in overview, artifacts are defined by which roles produce them or consume them.  In some protocol instantiations, other roles may cache and forward artifacts as opaque data, to one or more entities implementing the consuming role. </ins> 4. RFC4949 has defined a number of terms that are also used in this
Original text:
obtained via some other mechanism such as being configured in the Verifier by an administrator. <del> For example, for some claims the Verifier might check the values of claims in the Evidence against constraints specified in the Appraisal Policy for Evidence.  Such constraints might involve a comparison for equality against reference values, or a check for being in a range bounded by reference values, or membership in a set of reference values, or a check against values in other claims, or any other test. Such reference values might be specified as part of the Appraisal Policy for Evidence itself, or might be obtained from a separate source, such as an Endorsement, and then used by the Appraisal Policy for Evidence.  The actual data format and semantics of a known-good value are specific to claims and implementations.  There is no general purpose format for them or general means for comparison defined in this architecture document.  Similarly, for some claims the Verifier might check the values of claims in the Evidence for membership in a set, or against a range of values, or against known- bad values such as an expiration time.  These reference values may be conveyed to the Verifier as part of an Endorsement or as part of Appraisal Policy or both as these are the two input paths to the Verifier. </del> The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Attestation Result Appraisal Policy

Reviewer comments:
Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, so generalizing the text. This also removes a redundant sentence where older text and newly merged text from this morning said the same thing. And the diffs look larger than they really are, since some text was just moved around to be in a different order. Signed-off-by: Dave Thaler

Revised text:
obtained via some other mechanism such as being configured in the Verifier by an administrator.  The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Attestation Result Appraisal Policy
Original text:
4.1.  An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations

Reviewer comments:
Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, so generalizing the text. This also removes a redundant sentence where older text and newly merged text from this morning said the same thing. And the diffs look larger than they really are, since some text was just moved around to be in a different order. Signed-off-by: Dave Thaler

Revised text:
4.1. <ins> The Verifier, when appraising Evidence, or the Relying Party, when appraising Attestation Results, checks the values of some claims against constraints specified in its Appraisal Policy.  Such constraints might involve a comparison for equality against a reference value, or a check for being in a range bounded by reference values, or membership in a set of reference values, or a check against values in other claims, or any other test. Such reference values might be specified as part of the Appraisal Policy itself, or might be obtained from a separate source, such as an Endorsement, and then used by the Appraisal Policy. The actual data format and semantics of any reference values are specific to claims and implementations.  This architecture document does not define any general purpose format for them or general means for comparison. 4.2. </ins> An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations
Original text:
Environments are designed specifically with claims collection in mind. <del> 4.2. </del>  By definition, the Attester role takes on the duty to create Evidence.  The fact that an Attester role is composed of several

Reviewer comments:
Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, so generalizing the text. This also removes a redundant sentence where older text and newly merged text from this morning said the same thing. And the diffs look larger than they really are, since some text was just moved around to be in a different order. Signed-off-by: Dave Thaler

Revised text:
Environments are designed specifically with claims collection in mind.  <ins> 4.3. </ins> By definition, the Attester role takes on the duty to create Evidence.  The fact that an Attester role is composed of several
Original text:
Therefore, creating a layered boot sequence and correspondingly enabling Layered Attestation. <del> 4.3. </del>  A Composite Device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal

Reviewer comments:
Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, so generalizing the text. This also removes a redundant sentence where older text and newly merged text from this morning said the same thing. And the diffs look larger than they really are, since some text was just moved around to be in a different order. Signed-off-by: Dave Thaler

Revised text:
Therefore, creating a layered boot sequence and correspondingly enabling Layered Attestation.  <ins> 4.4. </ins> A Composite Device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal
Original text:
Universal Time, or might be defined relative to some other timestamp or timeticks counter. <del> We now walk through a number of hypothetical examples of how a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. </del>  15.1.

Reviewer comments:
only the most essential items: added three more timestamp types based on TUDA, trying to generalize it a bit added a few periods to text that seems to express sentences

Revised text:
Universal Time, or might be defined relative to some other timestamp or timeticks counter.  <ins> Using the table above, a number of hypothetical examples of how a solution might be built are illustrated below.  a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. </ins> 15.1.
Original text:
15.3. The following example illustrates a hypothetical Background-Check <del> Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party. The time considerations in this example are equivalent to those discussed under Example 1 above. </del>  15.4.

Reviewer comments:
only the most essential items: added three more timestamp types based on TUDA, trying to generalize it a bit added a few periods to text that seems to express sentences

Revised text:
15.3. The following example illustrates a hypothetical Background-Check  <ins> Model solution that uses centrally generated identifiers for explicit time-keeping (referred to as "handle" in this example).  Handles can be qualifying data, such as nonces or signed timestamps.  In this example, centrally generated signed timestamps and - and synchronized clocks between all entities - are distributed in periodic intervals as handles.  If the Attester lacks a source of time based on an absolute timescale, a relative source of time, such as a tick counter can be used, alternatively.  In this example, evidence generation is not triggered at value generation, but at events at which the Attesting Environment becomes of changes to the Target Environment. In comparison with example 1, the time considerations in this example go into more detail with respect to the life-cycle of Claims and Evidence.  While the goal is to create up-to-date and recent Evidence as soon as possible, typically there is a latency between value generation and Attester awareness. At time(AA) the Attesting Environment is able to trigger an event (e.g. based on an Event-Condition-Action model) to create attestation Evidence that is as recent as possible.  In essence, at time(AA) the Attesting Environment is aware of new values that where generated at time(VG) and corresponding Claim values are collected immediately. Consecutively, Evidence based on relevant "old" Claims and the just collected "new" Claims is generated at time(EG).  In essence, the Claims used to generate the Evidence are generated at various time(VG) before time(AA). In order to create attestation Evidence at at time(AA), the Attester requires a fresh (i.e. not expired) centrally generated handle that has been distributed to all involved entities. In general, The duration a handle remains fresh depends on the content-type of the handle.  If it is a (relative or absolute) timestamp, clocks synchronized with a shared and trustworthy source of time are required.  If another value type is used as a handle, the reception time of the handle time(HD) provides an epoch (relative time of zero) for measuring the duration of validity (similar to a heart-beat timeout).  From the point of view of a Verifier, validity of Evidence is only given if the handle used in Evidence satisfies delta(time(HD),time(EG))distribution-interval. In this usage scenario, time(VG), time(AA), and time(EG) are tightly coupled.  Also, the absolute point in time at which a handle is received by all three entities is assumed to be close to identical. </ins> 15.4.
Original text:
attempted against.  An empty redemption is returned when the limit has been hit:  6. We present a number of security considerations that prevent malicious

Reviewer comments:
cc NAME
There should be documentation that addresses the risks of the centralization in the current Privacy Pass architecture with potential solutions. This was raised in the previous WG meeting: URL This documentation should either be incorporated into the architecture document as a section when discussing the shape of the ecosystem, and/or security considerations. There is also the option of declaring a separate document for addressing this.
A draft has been put forward for this by Mark McFadden: URL, and will be discussed at IETF 110. Will leave this open for now, until this draft (or some form of it) is accepted.

Revised text:
attempted against.  An empty redemption is returned when the limit has been hit: <ins> 5.4. A consequence of limiting the number of participants (Attesters or Issuers) in Privacy Pass deployments for meaningful privacy is that it forces concentrated centralization amongst those participants. CENTRALIZATION discusses several ways in which this might be mitigated.  For example, a multi-stakeholder governance model could be established to determine what participants are fit to operate as participants in a Privacy Pass deployment.  This is precisely the model used to control the Web's trust model. Alternatively, Privacy Pass deployments might mitigate this problem through implementation.  For example, rather than centralize the role of attestation in one or few entities, attestation could be a distributed function performed by a quorum of many parties, provided that neither Issuers nor Origins learn which attester implementations were chosen.  As a result, clients could have more opportunities to switch between attestation participants. </ins> 6. We present a number of security considerations that prevent malicious
Original text:
that attest to this information. The most basic Privacy Pass protocol provides a set of cross-origin <del> authorization tokens that protect the client's anonymity during </del>  interactions with a server.  This allows clients to communicate an attestation of a previously authenticated server action without having to reauthenticate manually.  The tokens retain anonymity in

Reviewer comments:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Revised text:
that attest to this information. The most basic Privacy Pass protocol provides a set of cross-origin  <ins> authorization tokens that protect the Clients' anonymity during </ins> interactions with a server.  This allows clients to communicate an attestation of a previously authenticated server action without having to reauthenticate manually.  The tokens retain anonymity in
Original text:
properties include, though are not limited to: Capable of solving a CAPTCHA.  Clients that solve CAPTCHA <del> challenges can be attested to have this capability for the purposes of being ruled out as a bot or otherwise automated Client. </del>  Client state.  Clients can be associated with state and the attester can attest to this state.  Examples of state include the <del> number of issuance protocol invocations, the client's geographic </del>  region, and whether the client has a valid application-layer account. Trusted device.  Some Clients run on trusted hardware that are capable of producing device-level attestation statements. <del> Each of these attestation types have different security properties. </del>  For example, attesting to having a valid account is different from attesting to running on trusted hardware.  In general, Attesters should accept a limited form of attestation formats.

Reviewer comments:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Revised text:
properties include, though are not limited to: Capable of solving a CAPTCHA.  Clients that solve CAPTCHA  <ins> challenges can be attested to have this capability for the purpose of being ruled out as a bot or otherwise automated Client. </ins> Client state.  Clients can be associated with state and the attester can attest to this state.  Examples of state include the  <ins> number of issuance protocol invocations, the Client's geographic </ins> region, and whether the client has a valid application-layer account. Trusted device.  Some Clients run on trusted hardware that are capable of producing device-level attestation statements.  <ins> Each of these attestation types has different security properties. </ins> For example, attesting to having a valid account is different from attesting to running on trusted hardware.  In general, Attesters should accept a limited form of attestation formats.
Original text:
on compliant devices, then the corresponding attestation format should be untrusted until the exploit is patched.  Addressing changes in attestation quality is therefore a deployment-specific task.  In <del> Split Attester and Issuer deployments, Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched, without needing to modify Origin allow-lists. </del>  3.2.2.

Reviewer comments:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Revised text:
on compliant devices, then the corresponding attestation format should be untrusted until the exploit is patched.  Addressing changes in attestation quality is therefore a deployment-specific task.  In  <ins> Split Attester and Issuer deployments (see deploy-split), Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched, without needing to modify Origin allow- lists. </ins> 3.2.2.
Original text:
any given time.  The Issuer public key MUST be made available to all Clients in such a way that key rotations and other updates are publicly visible.  The key material and protocol configuration that <del> an Issuer uses to produce tokens corresponds to a number of different pieces of information. </del>  The issuance protocol in use; and

Reviewer comments:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Revised text:
any given time.  The Issuer public key MUST be made available to all Clients in such a way that key rotations and other updates are publicly visible.  The key material and protocol configuration that  <ins> an Issuer uses to produce tokens corresponds to two different pieces of information. </ins> The issuance protocol in use; and
Original text:
public metadata is metadata the client can see but cannot check for correctness.  As an example, the opaque public metadata might be a "fraud detection signal", computed on behalf of the Issuer, during <del> token issuance.  In normal circumstances, clients cannot determine if </del>  this value is correct or otherwise a tracking vector. <del> Private metadata is that which clients cannot observe as part of the </del>  token issuance flow.  Such instantiations may be built on the Private Metadata Bit construction from Kreuter et al.  KLOR20 or the attribute-based VOPRF from Huang et al.  HIJK21.

Reviewer comments:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Revised text:
public metadata is metadata the client can see but cannot check for correctness.  As an example, the opaque public metadata might be a "fraud detection signal", computed on behalf of the Issuer, during  <ins> token issuance.  In normal circumstances, Clients cannot determine if </ins> this value is correct or otherwise a tracking vector.  <ins> Private metadata is that which Clients cannot observe as part of the </ins> token issuance flow.  Such instantiations may be built on the Private Metadata Bit construction from Kreuter et al.  KLOR20 or the attribute-based VOPRF from Huang et al.  HIJK21.
Original text:
different forms.  For example, any Client can only remain private relative to the entire space of other Clients using the protocol. Moreover, by owning tokens for a given set of keys, the Client's <del> anonymity set shrinks to the total number of clients controlling </del>  tokens for the same keys. In the following, we consider the possible ways that Issuers can

Reviewer comments:
Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.

Revised text:
different forms.  For example, any Client can only remain private relative to the entire space of other Clients using the protocol. Moreover, by owning tokens for a given set of keys, the Client's  <ins> anonymity set shrinks to the total number of Clients controlling </ins> tokens for the same keys. In the following, we consider the possible ways that Issuers can