jiebi/TextFlow huggingface dataset:
Original text:
then the relaying entity should not expect to have access to the Evidence. <del> 12.3. </del>  Epoch IDs, described in epochfreshness, can be tampered with, replayed, dropped, delayed, and reordered by an attacker. provides the ability to detect reordering and drop.  However, the delay attack described above can't be thwarted in this manner. <del> 12.4. </del>  As noted in trustmodel, Verifiers and Relying Parties have trust anchor stores that must be secured.  RFC6024 contains more discussion

Reviewer comments:
insert text suggested by Roman about how deep down the security properties
[github said: URL] ==[ snip ]== We need to acknowledge that there is a deep hole (not infinitely deep, but not trivial) where we need to look at integrity of all of the different platforms. The way that the compositions are composed is a bit tricky, and the results are sometimes different than other people would naively assume. Are there references here to other papers that we should include? ==[ snip ]== I completely agree, that's why I mentioned it. Composition is hard and can alter the security assumptions of the individual components and introduce emergent risk. I don't think it can be solved generically. However, we do need cautionary text here. Perhaps: NEW (roughly) The RATS architecture allows for an entity to function in multiple roles (Section 6) and for composite devices (Section 3.3). Implementers need to evaluate their designs to ensure that the assumed security properties of the individual components and roles still holds despite the lack of separation, and that emergent risk is not introduced. The specifics of this evaluation will depend on the implementation and use case is out of scope for this document.

Revised text:
then the relaying entity should not expect to have access to the Evidence.  <ins> The RATS architecture allows for an entity to function in multiple roles (rolesentities) and for composite devices (compositedevice). Implementers need to evaluate their designs to ensure that the assumed security properties of the individual components and roles still hold despite the lack of separation, and that emergent risk is not introduced.  The specifics of this evaluation will depend on the implementation and the use case and hence is out of scope for this document.  Isolation mechanisms in software or hardware that separate Attesting Environments and Target Environments twotypes can support an implementer's evaluation and resulting design decisions.  ## Epoch ID-based Attestation {#epochids-sec} </ins> Epoch IDs, described in epochfreshness, can be tampered with, replayed, dropped, delayed, and reordered by an attacker. provides the ability to detect reordering and drop.  However, the delay attack described above can't be thwarted in this manner.  <ins> 12.3. </ins> As noted in trustmodel, Verifiers and Relying Parties have trust anchor stores that must be secured.  RFC6024 contains more discussion
Original text:
Verifier by the Verifier Owner, or might be programmed into the Verifier, or might be obtained via some other mechanism. <del> The Relying Party role is assigned to entities that uses Attestation </del>  Results by applying its own appraisal policy to make application- specific decisions, such as authorization decisions.  This procedure is called the appraisal of Attestation Results.

Reviewer comments:
The Relying Party role is assigned to entities that uses Attestation Results by applying its own appraisal policy to make application-specific decisions, such as authorization decisions. should be >The Relying Party role is assigned to entities that use Attestation Results by applying their own appraisal policies to make application-specific decisions, such as authorization decisions. or >The Relying Party role is assigned to an entity that uses Attestation Results by applying its own appraisal policy to make application-specific decisions, such as authorization decisions.
I'm in favor of the second option: The Relying Party role is assigned to an entity that uses Attestation Results by applying its own appraisal policy to make application-specific decisions, such as authorization decisions.
I am okay with second option.

Revised text:
Verifier by the Verifier Owner, or might be programmed into the Verifier, or might be obtained via some other mechanism.  <ins> The Relying Party role is assigned to an entity that uses Attestation </ins> Results by applying its own appraisal policy to make application- specific decisions, such as authorization decisions.  This procedure is called the appraisal of Attestation Results.
Original text:
Thus, trusting a Verifier might be expressed by having the Relying Party store the Verifier's key or certificate in its trust anchor store, or might be expressed by storing the public key or certificate <del> of an entity (e.g., a Certificate Authority) that is in the </del>  Verifier's certificate path.  For example, the Relying Party can verify that the Verifier is an expected one by out-of-band establishment of key material, combined with a protocol like TLS to

Reviewer comments:
You want to say "Certification Authority" not "Certificate Authority"
yeah. thanks for catching that!

Revised text:
Thus, trusting a Verifier might be expressed by having the Relying Party store the Verifier's key or certificate in its trust anchor store, or might be expressed by storing the public key or certificate  <ins> of an entity (e.g., a Certification Authority) that is in the </ins> Verifier's certificate path.  For example, the Relying Party can verify that the Verifier is an expected one by out-of-band establishment of key material, combined with a protocol like TLS to
Original text:
11.  12. This document does not require any actions by IANA.

Reviewer comments:
Incorporates both text from birkholz arch draft and thaler arch draft. Avoids using normative language per IETF 106 discussion. Signed-off-by: Dave Thaler
The Birkholz draft had the idea of roles to describe higher level concepts (independent of transport layer security considerations). It also defined "Actors" that focused on trust model relationships (and their fungibility). Also a higher-layer concept from transport layer security considerations. Each section in the arch spec addresses security considerations appropriate for the level of abstraction. Maybe this security considerations is aimed at transport level security considerations?

Revised text:
11. <ins> Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, or Endorsements, or Appraisal Policy, needs to support end- to-end integrity protection and replay attack prevention, and often also needs to support additional security protections.  For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection are needed in many use cases. To evaluate the security provided by a particular Appraisal Policy, it is important to understand the strength of the Root of Trust, e.g., whether it is mutable software, or firmware that is read-only after boot, or immutable hardware/ROM. It is also important that the Appraisal Policy was itself obtained securely.  As such, if Appraisal Policy in a Relying Party or Verifier can be configured via a network protocol, the ability to attest to the health of the client providing the Appraisal Policy needs to be considered. </ins> 12. This document does not require any actions by IANA.
Original text:
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 <del> might have multiple Attesting and Target Environments.  One example is a set of components in a boot sequence (e.g., ROM, firmware, OS, and application) where a Target Environment is the Attesting Environment for the next environment in the boot sequence. Another example is that of a Composite Devices: Composite Devices are defined below, and are inherently composed of multiple nested environments. </del>  Claims are collected from Target Environments.  That is, Attesting Environments collect the raw values and the information to be <del> represented in claims.  Attesting Environments then format them appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence. Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). </del>  4.2.

Reviewer comments:
Provide forward references Use "measure" in English text Signed-off-by: Dave Thaler
(I had to do this right away before I forgot what I was suggesting during the meeting :)

Revised text:
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  <ins> might have multiple Attesting and Target Environments, such as in the examples described in more detail in layered-attestation and compositeattester.  Other examples may exist, and the examples discussed could even be combined into even more complex implementations. </ins> Claims are collected from Target Environments.  That is, Attesting Environments collect the raw values and the information to be  <ins> represented in claims, such as by doing some measurement of a Target Environment's code, memory, and/or registers.  Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). </ins> 4.2.
Original text:
5. <del> There are multiple possible models for communication between an Attester, a Verifier, and a Relying Party.  This section includes some reference models, but this is not intended to be a restrictive list, and other variations may exist. </del>  5.1.

Reviewer comments:
describe the basic Topological Model without complicating the draft
I am uncertain about the state of this PR. NAME were your comments addressed?
~ In both the passport and background-check models, the Attester communicates directly with the Relying Party to access some resources. But in some cases, the Attester doesn't need to access resources from the Relying Party. Assume that the Attester is a network device (router, switch, etc.), and the Relying Party is the network management system (NMS) of the network operator. In such a case, the NMS monitors the health of the device by retrieving the Attestation Result of the device from a Verifier. If the device fails the attestation process, the NMS can take countermeasures like quarantining it. So the figure above depicts this situation.
Is this topological model covered by the passport model or background-check model?
The above flow is always the information flow. The passport model and background-check are models for how the conveyance works.
Also, we had that diagram in the architecture documents, and we have the above diagram as figure 1 already.
This is also a way in which the conveyance can work. I add two sentences to describe this basic one without duplicating the diagram.
We conclude that there is not a need for this additional topological flow.

Revised text:
5.  <ins> dataflow shows a basic model for communication between an Attester, a Verifier, and a Relying Party.  The Attester sends its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Results from the Verifier.  There are multiple other possible models.  This section includes some reference models, but this is not intended to be a restrictive list, and other variations may exist. </ins> 5.1.
Original text:
discussed could even be combined into even more complex implementations. <del> Claims are collected from Target Environments.  That is, Attesting Environments collect the raw values and the information to be represented in claims, such as by doing some measurement of a Target Environment's code, memory, and/or registers.  Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). </del>  4.2.

Reviewer comments:
Signed-off-by: Dave Thaler
I don't understand the text Ned added. Suggest moving it to a separate PR.
The existing text listed HSM and TEE as examples of Attesting Environments. However, an HSM that only provides crypto acceleration and key storage wasn’t designed for claims collection. Therefore, it isn’t an Attesting Environment (necessarily). The text I added explains that the Attesting Environment is designed in such a way that it is capable of claims collection. For example, if the HSM was designed to have exposed a shared memory region that is shared with the Target Environment’s executable code pages.
Will fix broken kramdown after pull.
Approve of the changes. But also have an additional comment suggested change.

Revised text:
discussed could even be combined into even more complex implementations.  <ins> Claims are collected from Target Environments, as shown in twotypes- env.  That is, Attesting Environments collect the raw values and the information to be represented in claims, such as by doing some measurement of a Target Environment's code, memory, and/or registers. Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  Places that Attesting Environments can exist include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), and BIOS firmware.  An execution environment may not, by default, be capable of claims collection for a given Target Environment.  Attesting Environments are designed specifically with claims collection in mind. </ins> 4.2.
Original text:
deciding whether the entity is authorized to perform some operation  A secure statement that some entity (typically a manufacturer) vouches for the integrity of an Attester's signing capability

Reviewer comments:
I think we must define claim in the terminology section. The term claim originates from JWT, but JWT doesn't really define it.
The fact that "claim" is used throughout both RFC 7519 (JWT) and RFC 8392 (CWT) without any formal definition, means that it's clearly ok to have an RFC that does not define claim in its terminology section or anywhere else. I would favor following those precedents and not trying to retroactively invent some definition we have to agree on.
URL defines Claim as: Claim A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value.
If the term is defined elsewhere, is that definition used consistently with ours? Claim A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value. URL Claim: : A piece of information asserted about a subject. (consistently with {{RFC7519}}) A claim is usually represented by as a name/value pair.

Revised text:
deciding whether the entity is authorized to perform some operation <ins> A piece of asserted information, often in the form of a name/value pair.  (Compare /claim/ in RFC7519) </ins> A secure statement that some entity (typically a manufacturer) vouches for the integrity of an Attester's signing capability
Original text:
tampering.  The component that is implicitly trusted is often referred to as a Root of Trust.  In some scenarios, Evidence might contain sensitive information such as Personally Identifiable Information.  Thus, an Attester must trust entities to which it conveys Evidence, to not reveal sensitive data when appraising it at time(RA) by checking "time(RA) - time(RG) < Threshold", where the Relying Party's threshold is large enough to account for the maximum permitted clock skew between the Relying <del> Party and the Verifier. The result might then be used for some time (e.g., throughout the lifetime of a connection established at time(RA)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP)) as long as "time(OP) - time(RG) < Threshold".  However, if the Attestation Result contains an expiry time time(RX) then it could explicitly check "time(OP) < time(RX)". </del>  14.2.

Reviewer comments:
replace pull request with one we can edit. This attempts to establish the architectural basis for implicit trust as a result of links.
new text from requires some new Security Considerations text.

Revised text:
tampering.  The component that is implicitly trusted is often referred to as a Root of Trust. <ins> A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the following properties exists: The key material used to authenticate and integrity protect the conveyance channel is trusted by the Verifier to speak for the Attesting Environment(s) that collected claims about the Target Environment(s). All unprotected Evidence that is conveyed is supplied exclusively by the Attesting Environment that has the key material that protects the conveyance channel The Root of Trust protects both the conveyance channel key material and the Attesting Environment with equivalent strength protections. </ins> In some scenarios, Evidence might contain sensitive information such as Personally Identifiable Information.  Thus, an Attester must trust entities to which it conveys Evidence, to not reveal sensitive data when appraising it at time(RA) by checking "time(RA) - time(RG) < Threshold", where the Relying Party's threshold is large enough to account for the maximum permitted clock skew between the Relying  <ins> Party and the Verifier.  The result might then be used for some time (e.g., throughout the lifetime of a connection established at time(RA)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP)) as long as "time(OP) - time(RG) < Threshold".  However, if the Attestation Result contains an expiry time time(RX) then it could explicitly check "time(OP) < time(RX)". </ins> 14.2.
Original text:
Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade, <del> Wei Pan, Paul Rowe, Hannes Tschofenig, Frank Xia, and David Wooten. </del>  15.

Reviewer comments:
Wei Pan was added to the author list but wasn't removed from the Acknowledgements section at the time so now appears in both places. This PR corrects that. Signed-off-by: Dave Thaler
Yeah. I think this is yet another artifact and Dave is absolutely right here. Wei is already an "acknowledged editor" and therefore obviously does not has to be included in a potential ack section, apparently.
Thanks for your careful observation.

Revised text:
Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade,  <ins> Paul Rowe, Hannes Tschofenig, Frank Xia, and David Wooten. </ins> 15.
Original text:
"issuer_name" is a string containing the name of the issuer.  This is a hostname that is used to identify the issuer that is allowed <del> to issue tokens that can be redeemed by this origin. </del>  "redemption_context" is an optional field.  If present, it allows the origin to require that clients fetch tokens bound to a generated by the origin.  This value can be a unique per-request nonce, or represent some state such as properties of the client session or current time window.  Valid lengths for this field are <del> either 0 or 32 bytes.  Challenges with redemption_context values </del>  of invalid lengths MUST be ignored. "origin_name" is an optional string containing the name of the <del> origin.  This allows a token to be scoped to a specific origin. If empty, any non-origin specific token can be redeemed. </del>  When used in an authentication challenge, the "PrivateToken" scheme uses the following attributes:

Reviewer comments:
For anyone unfamiliar with TLS struct notation, spell out the length fields in the text.

Revised text:
"issuer_name" is a string containing the name of the issuer.  This is a hostname that is used to identify the issuer that is allowed  <ins> to issue tokens that can be redeemed by this origin.  The string is prefixed with a 2-octet integer indicating the length, in network byte order. </ins> "redemption_context" is an optional field.  If present, it allows the origin to require that clients fetch tokens bound to a generated by the origin.  This value can be a unique per-request nonce, or represent some state such as properties of the client session or current time window.  Valid lengths for this field are  <ins> either 0 or 32 bytes.  The field is prefixed with a single octet indicating the length.  Challenges with redemption_context values </ins> of invalid lengths MUST be ignored. "origin_name" is an optional string containing the name of the  <ins> origin, which allows a token to be scoped to a specific origin. The string is prefixed with a 2-octet integer indicating the length, in network byte order.  If empty, any non-origin-specific token can be redeemed. </ins> When used in an authentication challenge, the "PrivateToken" scheme uses the following attributes:
Original text:
1. Privacy Pass tokens are unlinkable authenticators that can be used to <del> anonymously authorize a client (see I-D.ietf-privacypass- architecture).  A client possessing such a token is able to prove that it was able to get a token issued by a token issuer - based on some check from a token issuer, such as authentication or solving a CAPTCHA - without allowing the relying party redeeming the client's token (the origin) to link it with issuance flow. </del>  Different types of authenticators, using different token issuance protocols, can be used as Privacy Pass tokens. in TLS notation from TLS13, Section 3. This document uses the terms "Client", "Origin", "Issuer", "Issuance <del> Protocol", and "Token" as defined in I-D.ietf-privacypass- architecture.  It additionally uses the following terms in more specific ways: </del>  Issuer key: Keying material that can be used with an issuance protocol to create a signed token.

Reviewer comments:
We could omit the authenticator value and just focus on how Token is constructed based on TokenChallenge, but it seems reasonable to include the authenticator so folks can also test that they're computing the token key ID correctly. Generated from .

Revised text:
1. Privacy Pass tokens are unlinkable authenticators that can be used to  <ins> anonymously authorize a client (see ARCHITECTURE).  A client possessing such a token is able to prove that it was able to get a token issued by a token issuer - based on some check from a token issuer, such as authentication or solving a CAPTCHA - without allowing the relying party redeeming the client's token (the origin) to link it with issuance flow. </ins> Different types of authenticators, using different token issuance protocols, can be used as Privacy Pass tokens. in TLS notation from TLS13, Section 3. This document uses the terms "Client", "Origin", "Issuer", "Issuance  <ins> Protocol", and "Token" as defined in ARCHITECTURE.  It additionally uses the following terms in more specific ways: </ins> Issuer key: Keying material that can be used with an issuance protocol to create a signed token.