jiebi/CodeConvo huggingface dataset:
Change:
Line had the closing "}" in the wrong place in the diagram. While touching this text, added phrase about disadvantage of the nonce approach, to provide more balanced discussion of timestamps vs nonces vs handles. Signed-off-by: Dave Thaler

Discussion:
16.2. The following example illustrates a hypothetical Passport Model <del> solution that uses nonces and thus does not require that any clocks are synchronized. As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps. Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver. </del> <ins> solution that uses nonces instead of timestamps.  Compared to the timestamp-based example, it requires an extra round trip to retrieve a nonce, and requires that the Verifier and Relying Party track state to remember the nonce for some period of time. The advantage is that it does not require that any clocks are synchronized.  As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps.  Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver. </ins> In this example solution, the Verifier can check whether the Evidence is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) <
Change:
Signed-off-by: Dave Thaler
` What’s the difference between claim and evidence? Maybe you start with a Claim, then sign it and that makes it into Evidence? Is Evidence a ‘set of claims’? [and what’s the difference between a ‘set of information’ and ‘information’?]
Maybe "A signed set of Claims about an Attester..."? (Want to make sure it's not "just" a set of claims, since the signing is important too.)

Discussion:
An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence <del> A set of information about an Attester that is to be appraised by a Verifier.  Evidence may include configuration data, measurements, telemetry, or inferences. </del> <ins> A set of Claims generated by an Attester to be appraised by a Verifier.  Evidence may include configuration data, measurements, telemetry, or inferences. </ins> An entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence to determine if acceptable known
Change:
Signed-off-by: Dave Thaler
` Huh? I thought a Reference Value came from a Reference Value Provider

Discussion:
4.2. <del> Reference Values used in appraisal 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. </del> <ins> Reference Values used in appraisal come from a Reference Value Provider and are then used by the appraisal policy.  They might be conveyed in any number of ways, including: * as part of the appraisal policy itself, if the Verifier Owner either: acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; * as part of an Endorsement, if the Endorser either acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; or * via separate communication. </ins> The actual data format and semantics of any Reference Values are specific to claims and implementations.  This architecture document
Change:
The last sentence of the abstract is: but "such" remote attestation procedures are not defined earlier.
This abstract literally reads more self-consistent. +1

Discussion:
Abstract <del> In network protocol exchanges, it is often the case that one entity (a Relying Party) requires evidence about a remote peer to assess the peer's trustworthiness, and a way to appraise such evidence.  The evidence is typically a set of claims about its software and hardware platform.  This document describes an architecture for such remote attestation procedures (RATS). </del> <ins> In network protocol exchanges it is often the case that one entity requires believable evidence about the operational state of a remote peer.  Such evidence is typically conveyed as claims about the peer's software and hardware platform, and is subsequently appraised in order to assess the peer's trustworthiness.  The process of generating and appraising this kind of evidence is known as remote attestation.  This document describes an architecture for remote attestation procedures that generate, convey, and appraise evidence about a peer's operational state. </ins> 1.
Change:
Clarify that recentness of Evidence depends primarily on the appraisal policy and that clock skew is only secondary.
Section "16.1. Example 1", third para: I find the reference to clock skew slightly confusing. The Threshold value here is more likely to depend on a verification policy that defines what is an acceptable "age" of the sampled claim rather than on considerations about clocks drifting.

Discussion:
value generated at that time, and the Verifier decides that it can trust the time(VG_a) value, the Verifier can also determine whether the claim value is recent by checking "time(RG_v) - time(VG_a) < <del> Threshold", again where the threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </del> <ins> Threshold". The threshold is decided by the Appraisal Policy for Evidence, and again needs to take into account the maximum permitted clock skew between the Verifier and the Attester. </ins> The Relying Party can check whether the Attestation Result is fresh when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v)
Change:
Signed-off-by: Dave Thaler
"It is assumed that the Attester is located in an isolated environment of a device like a process, a dedicated chip a TEE or such that collects the Claims, formats them and signs them with an Attestation Key." The grammar seems off to me. Should be: "It is assumed that the Attester is located in an isolated environment of a device such as; a process, a dedicated chip, a TEE, a virtual machine, a secure mode of operation or other forms of domain isolation that allows collection of Claims from the target environment where the target environment cannot lie or interfere with the claims collection function. Additionally, the Attester formats collected Claims and integrity protects them with an Attestation Key that also is domain isolated such that the target environment or some other entity other than the Attester is not able to undermine the Attester's protections"

Discussion:
Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning <del> the Attestation key material.  When either of these are compromised, </del> <ins> the Attestation key material.  If either of these are compromised, </ins> the remote attestation becomes worthless because the attacker can forge Evidence.

12.1.1. <del> It is assumed that the Attester is located in an isolated environment of a device like a process, a dedicated chip a TEE or such that collects the Claims, formats them and signs them with an Attestation Key. The Attester must be protected from unauthorized modification to ensure it behaves correctly.  There must also be confidentiality so that the signing key is not captured and used elsewhere to forge evidence. </del> <ins> It is assumed that an Attesting Environment is sufficiently isolated from the Target Environment it collects Claims for and signs them with an Attestation Key, so that the Target Environment cannot forge Evidence about itself.  Such an isolated environment might be provided by a process, a dedicated chip, a TEE, a virtual machine, or another secure mode of operation.  The Attesting Environment must be protected from unauthorized modification to ensure it behaves correctly.  There must also be confidentiality so that the signing key is not captured and used elsewhere to forge Evidence. </ins> In many cases the user or owner of the device must not be able to modify or exfiltrate keys from the Attesting Environment of the
Change:
Signed-off-by: Dave Thaler
` I think what you mean is that “some flexibility on the requirement for freshness is a key component…”, i.e., it’s the willingness to accept a result that’s been around for a while enables caching.
agree.

Discussion:
Attester, and the appraisal policies might change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow their recentness to something the Verifier (for Evidence) <del> or Relying Party (for Attestation Result) is willing to accept. Freshness is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </del> <ins> or Relying Party (for Attestation Result) is willing to accept.  Some flexibility on the freshness requirement, however, is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </ins> There are two common approaches for determining the epoch of an Evidence or Attestation Result.
Change:
We say: I'm not sure it "is up to the RP"_. Maybe better saying it "depends on the RP application" (or similar) because it's typically not a choice of the RP but of the use case / protocol flow in which the RP operates...
+1
Proposal: "Individual applications, use cases or protocol flows interacting with the same Attester can use different models."

Discussion:
functions together.  In this case, there is no need for a protocol between the two. <del> It is also worth pointing out that the choice of model is generally up to the Relying Party.  The same device may need to create Evidence for different Relying Parties and/or different use cases.  For instance, it would use one model to provide Evidence to a network infrastructure device to gain access to the network, and the other model to provide Evidence to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </del> <ins> It is also worth pointing out that the choice of model depends on the use case, and that different Relying Parties may use different topological patterns. The same device may need to create Evidence for different Relying Parties and/or different use cases.  For instance, it would use one model to provide Evidence to a network infrastructure device to gain access to the network, and the other model to provide Evidence to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </ins> combination shows another example of a combination where Relying Party 1 uses the passport model, whereas Relying Party 2 uses an
Change:
The three sentences "There are multiple [...]", "This section includes [...]" and "This is not intended [...]" are slightly vague. It doesn't seem to me that their information content is enough to justify them being independent sentences. They should probably be combined.
OLD: NEW:
(slight refinement) "Figure 1 shows an abstract model for communication between an Attester, a Verifier, and a Relying Party. The Attester conveys its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Result from the Verifier. This section refines it by describing two reference interaction schemes (topological models), as well as one possible compositions thereof. The discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns."
Reads good to me. Any other comments? (starting a virtual going once...)

Discussion:
5. <del> dataflow shows a basic model for communication between an Attester, a Verifier, and a Relying Party.  The Attester conveys its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Result from the Verifier.  There are multiple other possible models.  This section includes some reference models.  This is not intended to be a restrictive list, and other variations may exist. </del> <ins> dataflow shows a data-flow diagram for communication between an Attester, a Verifier, and a Relying Party.  The Attester conveys its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Result from the Verifier.  This section refines it by describing two reference models, as well as one example composition thereof.  The discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns. </ins> 5.1.
Change:
There seems to be some confusion: initially it is said that the "Relying Party is the watchdog timer in the TPM." Subsequently, the Relying Party is defined as "A remote server that will securely grant the Attester [...]". So, what is it?
For context, this is now: https://ietf-rats-URL This is plainly wrong (probably due being left over as an artifact after revising the text). How about: "Relying Party: The watchdog capable to trigger a procedure that resets a device into a remediatable operational state."
WFM, except I am not sure "remediatable" is a word. You want to use "known, good" instead?
Sry for my native language habit of concatenating and mangling existing terms. "Known, good" reads very appropriate. Thanks!
The sentence above says that the replying party is inside the TPM?? I think this sentence, relying party is a remote server, is more likely what you mean. In the above paragraph, it says that the Relying Party is inside the TPM. I think this is the correct description. The Relying Party isn't remote in this use case because it has the essential capability to force the device to reboot.
This issue is the same as

Discussion:
The device that should be protected from being held hostage for a long period of time <del> A remote server that will securely grant the Attester permission to continue operating (i.e., not reboot) for a period of time </del> <ins> A watchdog capable of triggering a procedure that resets a device into a known, good operational state. </ins> 2.7.
Change:
Signed-off-by: Dave Thaler
The paragraph: seems to reshuffle the content of the preceding one. The two can be combined / streamlined.
Maybe: "However, like in the Passport model, an Attestation Result is still consumed by the Relying Party and so the ability to convey it in the same serialization format as the Evidence allows minimizing the code footprint and attack surface area, which is especially important if the Relying Party is a constrained node."
Personally, I like the new content here that elaborates on motivation and intent. Anyone else like to chime in here to have in impact on that expositional text?
The meaning of is wrong, i.e., format same as the Evidence. Instead the meaning is format same as the resource access protocol natively uses.

Discussion:
protocol between the Attester and Relying Party. However, like in the Passport model, an Attestation Result is still <del> consumed by the Relying Party and so the serialization format of the Attestation Result is still important.  If the Relying Party is a constrained node whose purpose is to serve a given type resource using a standard resource access protocol, it already needs the parser(s) required by that existing protocol.  Hence, the ability to let the Relying Party obtain an Attestation Result in the same serialization format allows minimizing the code footprint and attack surface area of the Relying Party, especially if the Relying Party is a constrained node. </del> <ins> consumed by the Relying Party.  Code footprint and attack surface area can be minimized by using a serialization format for which the Relying Party already needs a parser to support the protocol between the Attester and Relying Party, which may be an existing standard or widely deployed resource access protocol.  Such minimization is especially important if the Relying Party is a constrained node. </ins> 5.3.
Change:
Why not? What’s the message you want to convey here? What would disqualify an execution environment from being capable of claims collection? How would you know if an Execution Environment is an Attesting Environment?
What does it mean to be capable of claims collection? If this example had a TPM, then this function would be entirely inside the TPM, no?
subsequent line now reads: ` Should this explicitely say, "TPM" as well, or is that implied?

Discussion:
Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  There is no limit <del> to or requirement on the places that an Attesting Environment can exist, but they typically are in 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.  Execution environments that are designed to be capable of claims collection are referred to in this document as Attesting Environments. </del> <ins> to or requirement on the types of hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules (TPMs), or BIOS firmware.  An arbitrary execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed specifically to be capable of claims collection are referred to in this document as Attesting Environments. </ins> 3.4.
Change:
` It sounds like the Verifier “does” the authentication, and the relying party relies on the answer?
Besides, there's a slight imprecision here: the web site / mobile app backend service don't do biometric auth. Instead, the authenticator binds biometric info to crypto material so that the web site can deal with usual crypto auth.
For context, this is https://ietf-rats-URL How about:

Discussion:
Every FIDO Authenticator contains an Attester. <del> Any web site, mobile application back end or service that does biometric authentication. </del> <ins> Any web site, mobile application back-end, or service that relies on authentication data based on biometric information. </ins> 3.
Change:
Based on Henk's proposal and Dave's comments.
NAME : This is a complete re-write of the paragraph which needs to be read in its entirety. I'm not sure whether a line-by-line diff is of any help? That said, if you really want I could do that easily.
Thomas Fossati wrote: It helps with the next edit that comes along.
OK, done in f778919
I don't understand what this para is supposed to communicate: Also, pick one of "nested", "staged" or "chained" and drop the rest.
For context: this is now https://ietf-rats-URL "Layered Attestation Environments" How about this as a new starting point: Effectively, I removed the last sentence, as I had a hard time to understand what it intended to add to the content here. My proposal is intended as a rework of this paragraph that goes beyond editorial changes. The current last sentence still seems a bit out of place to me.
Looks very good as a starting point. Thanks!
All good so far. This sentence can be confusing, since I think it could include claims about itself in Evidence, as admitted in your point below ("Claims can be collected from or about each layer, including roots of trust.") Disagree with "must be endorsed". Either the verifier has to trust the root of trust itself (e.g., put the root of trust's public key into its trust anchor store directly) OR must be endorsed (e.g., put the endorser's public key into the verifier's trust anchor store). Fine.

Discussion:
3.4. <del> By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding complexity to the architectural structure.  The unifying component is the root of trust and the nested, staged, or chained attestation Evidence produced.  The nested or chained structure includes Claims, collected by the Attester to aid in the assurance or believability of the attestation Evidence. </del> <ins> By definition, the Attester role generates Evidence.  An Attester may consist of one or more nested environments (layers).  The root layer of an Attester includes at least one root of trust.  In order to appraise Evidence generated by an Attester, the Verifier needs to trust the Attester's root of trust.  Trust in the Attester's root of trust can be established either directly (e.g., the Verifier puts the root of trust's public key into its trust anchor store) or transitively via an Endorser (e.g., the Verifier puts the Endorser's public key into its trust anchor store).  In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be collected from or about each layer.  The corresponding claims can be structured in a nested fashion that reflects the nesting of the Attester's layers. </ins> The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an updatable bootloader, and (C) an operating system
Change:
` Is there a reason to enumerate the failure cases? How can it be argued that there are only three? What if the device fails part way through? What if the relying party fails? What if the relying party is unreachable? What if something happens that wasn’t anticipated in the appraisal policy? Put another way, what are we learning about RATS from this example?

Discussion:
Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy. <del> There are three ways in which the process may fail.  First, the Verifier may not issue a positive Attestation Result due to the Evidence not passing the Appraisal Policy for Evidence.  The second way in which the process may fail is when the Attestation Result is examined by the Relying Party, and based upon the Appraisal Policy for Attestation Results, the result does not pass the policy.  The third way is when the Verifier is unreachable or unavailable. </del> <ins> Three ways in which the process may fail include: First, the Verifier may not issue a positive Attestation Result due to the Evidence not passing the Appraisal Policy for Evidence. The second way in which the process may fail is when the Attestation Result is examined by the Relying Party, and based upon the Appraisal Policy for Attestation Results, the result does not pass the policy. The third way is when the Verifier is unreachable or unavailable. </ins> Since the resource access protocol between the Attester and Relying Party includes an Attestation Result, in this model the details of