jiebi/CodeConvo huggingface dataset:
Code change:
** Section 12.1.2.1. Would it be more precise to say: OLD The degree of protection afforded to this key material can vary by device, based upon considerations as to a cost/benefit evaluation of the intended function of the device. NEW The degree of protection afforded to this key material can vary by the intended function of the device and the specific practices of the device manufacturer or integrator.

Related discussion:
text: measures appropriate for its value. The degree of protection afforded to this key material can vary by <del> device, based upon considerations as to a cost/benefit evaluation of the intended function of the device.  The confidentiality protection is fundamentally based upon some amount of physical protection: while </del> <ins> the intended function of the device and the specific practices of the device manufacturer or integrator.  The confidentiality protection is fundamentally based upon some amount of physical protection: while </ins> encryption is often used to provide confidentiality when a key is conveyed across a factory, where the attestation key is created or applied, it must be available in an unencrypted form.  The physical
Code change:
Throughout the document the term "trust anchor" is meant in the to be a public key and associated (meta)data. This definition does not cover attestation schemes based on symmetric crypto, e.g., , and Arm PSA, and should be extended to also cover such cases.
Was there specific text that you believe needs to be changed?
yes, we identified at least two places: §7.1 and §12.4.
Reads great to me. Any other opinions?

Related discussion:
text: constrain the types of information for which the trust anchor is authoritative."  The trust anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its <del> public key algorithm and parameters. </del> <ins> public key algorithm and parameters.  In the context of this document, a trust anchor may also be a symmetric key, as in TCG-DICE- SIBDA or the symmetric mode described in I-D.tschofenig-rats-psa- token. </ins> Thus, trusting a Verifier might be expressed by having the Relying <del> Party store the Verifier's public key or certificate in its trust anchor store, or might be expressed by storing the public key or certificate of an entity (e.g., a Certificate Authority) that is in the Verifier's certificate path.  For example, the Relying Party can </del> <ins> Party store the Verifier's key or certificate in its trust anchor store, or might be expressed by storing the public key or certificate of an entity (e.g., a Certificate Authority) that is in the Verifier's certificate path.  For example, the Relying Party can </ins> verify that the Verifier is an expected one by out of band establishment of key material, combined with a protocol like TLS to communicate.  There is an assumption that between the establishment
Code change:
Throughout the document the term "trust anchor" is meant in the to be a public key and associated (meta)data. This definition does not cover attestation schemes based on symmetric crypto, e.g., , and Arm PSA, and should be extended to also cover such cases.
Was there specific text that you believe needs to be changed?
yes, we identified at least two places: §7.1 and §12.4.
Reads great to me. Any other opinions?

Related discussion:
text: As noted in trustmodel, Verifiers and Relying Parties have trust anchor stores that must be secured.  RFC6024 contains more discussion <del> of trust anchor store requirements.  Specifically, a trust anchor store must resist modification against unauthorized insertion, deletion, and modification. </del> <ins> of trust anchor store requirements for protecting public keys. Section 6 of NIST-800-57-p1 contains a comprehensive treatment of the topic, including the protection of symmetric key material. Specifically, a trust anchor store must resist modification against unauthorized insertion, deletion, and modification.  Additionally, if the trust anchor is a symmetric key, the trust anchor store must not allow unauthorized read. </ins> If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate
Code change:
Add in text from Birkholz draft, with some wordsmithing and grammatical fixes from Dave Thaler

Related discussion:
text: 9. <ins> The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a device.  In many cases, the whole point of the Attestation process is to provide reliable information about the type of the device and the firmware/software that the device is running.  This information is particularly interesting to many attackers.  For example, knowing that a device is running a weak version of firmware provides a way to aim attacks better. Protocols that convey Evidence or Attestation Results are responsible for detailing what kinds of information are disclosed, and to whom they are exposed. </ins> 10. 11.
Code change:
Here's a first attempt to combine terminology sections, and trust model. Includes new terms Endorser and Appraisal Policy per recent discussion. Signed-off-by: Dave Thaler
Done
Done. (But if you have feedback on a sentence like this in the future, please attach the comment directly to the code line under the "Files changed" tab, to make it easy to find which phrase you're referring to.)
Done
Updated. How about now?
I would like to discuss the possibility of combining the terms "Endorsement" and "Attestation Result". Just like we have an Appraisal Policy for a verifier and an Appraisal Policy for a relying party, some might view an Attestation Result as an Endorsement for use by the relying party. I'm ok either way, but wanted to discuss this in our next call to see if others think it would help or confuse things.
I still believe my original definition of Attestation is good, I haven't seen any comments here about what the problem was. For comparison, URL says it's "The process of validating the integrity of a computing device such as a server needed for trusted computing.". I'm also ok with that definition.
I’m OK with that wording for introducing the concept. It may break down if the terminology for ‘device’ and ‘trusted computing’ become overly specified / specific.
The word 'health' is generally being used where other words such as 'trustworthiness', or 'state' could be used. I'm concerned that 'health' might not easily be synonymous with 'trust'. It also seems to bias the architecture toward NEA (RFC5209) which IMO does not define attestation.

Related discussion:
text: for detailing what kinds of information are disclosed, and to whom they are exposed. <del> 10. </del> 11. <ins> 12. </ins> This document does not require any actions by IANA. <del> 12. </del> <ins> 13. </ins> Special thanks go to David Wooten, Joerg Borchert, Hannes Tschofenig, Laurence Lundblade, Diego Lopez, Jessica Fitzgerald-McKay, Frank Xia,
Code change:
Generated from . cc NAME NAME NAME
These test vectors should cover the whole flow of the protocol, starting with the input and producing a output.

Related discussion:
text: Issuer completes the issuance flow by computing a blinded response as follows: <ins> This is encoded and transmitted to the client in the following TokenResponse structure: </ins> The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  The Issuer generates an HTTP response with status <del> code 200 whose body consists of "blind_sig", with the content type </del> <ins> code 200 whose body consists of TokenResponse, with the content type </ins> set as "message/token-response". 6.3.
Code change:
Spell out origin steps more clearly Split token caching into its own section I tried having an overall "origin" and "client" section, but it didn't flow as well.

Related discussion:
text: TokenChallenge message, along with information about what keys to use when requesting a token from the issuer. <ins> Origins that support this authentication scheme need to handle the following tasks: Select which issuer to use, and configure the issuer name and token-key to include in WWW-Authenticate challenges. Determine a redemption context construction to include in the TokenChallenge, as discussed in context-construction. Select the origin information to include in the TokenChallenge. This can be empty to allow fully cross-origin tokens, a single origin name that matches the origin itself, or a list of origin names containing the origin. </ins> The TokenChallenge message has the following structure: The structure fields are defined as follows:
Code change:
Spell out origin steps more clearly Split token caching into its own section I tried having an overall "origin" and "client" section, but it didn't flow as well.

Related discussion:
text: names for which current connection is not authoritative (according to the TLS certificate). <del> Note that it is possible for the WWW-Authenticate header to include multiple challenges, in order to allow the client to fetch a batch of multiple tokens for future use. For example, the WWW-Authenticate header could look like this: </del> <ins> Caching and pre-fetching of tokens is discussed in caching. </ins> <del> If a client fetches a batch of multiple tokens for future use that are bound to a specific redemption context (the redemption_context in the TokenChallenge was not empty), clients SHOULD discard these tokens upon flushing state such as HTTP cookies COOKIES, or changing networks.  Using these tokens in a context that otherwise would not be linkable to the original context could allow the origin to recognize a client. </del> <ins> Note that it is possible for the WWW-Authenticate header to include multiple challenges.  This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts.  For example, the WWW-Authenticate header could look like this: </ins> 2.1.1.
Code change:
Spell out origin steps more clearly Split token caching into its own section I tried having an overall "origin" and "client" section, but it didn't flow as well.

Related discussion:
text: address prefix). An empty redemption context is not bound to any property of the <del> client session. </del> <ins> client session.  Preventing double spending on tokens requires the origin to keep state associated with the redemption context.  The size of this state varies based on the size of the redemption context.  For example, double spend state for unique, per-request redemption contexts does only needs to exist within the scope of the request connection or session.  In contrast, double spend state for empty redemption contexts must be stored and shared across all requests until token-key expiration or rotation. 2.1.2. Clients can generate multiple tokens from a single TokenChallenge, and cache them for future use.  This improves privacy by separating the time of token issuance from the time of token redemption, and also allows clients to avoid any overhead of receiving new tokens via the issuance protocol. Cached tokens can only be redeemed when they match all of the fields in the TokenChallenge: token_type, issuer_name, redemption_context, and origin_info.  Clients ought to store cached tokens based on all of these fields, to avoid trying to redeem a token that does not match.  Note that each token has a unique client nonce, which is sent in token redemption (redemption). If a client fetches a batch of multiple tokens for future use that are bound to a specific redemption context (the redemption_context in the TokenChallenge was not empty), clients SHOULD discard these tokens upon flushing state such as HTTP cookies COOKIES, or changing networks.  Using these tokens in a context that otherwise would not be linkable to the original context could allow the origin to recognize a client. </ins> 2.2.
Code change:
The section references seem to be breaking the build, so I'll fix that later before we land this.
Origins currently choose whether their challenges are per-origin or cross-origin. For cross-origin, double-spend prevention is only as good as the coordination between origins and the Issuer. Per-origin allows double-spend prevention to be isolated to a single origin; also prevents the cache of tokens being take up by some other origin.
Write this as "any origins that share a redemption context must also share double spend state for that context."

Related discussion:
text: empty redemption contexts must be stored and shared across all requests until token-key expiration or rotation. <ins> Origins that share redemption contexts, i.e., by using the same redemption context, choosing the same issuer, and providing the same origin_info field in the TokenChallenge, must necessarily share state required to enforce double spend prevention.  Origins should consider the operational complexity of this shared state before choosing to share redemption contexts.  Failure to successfully synchronize this state and use it for double spend prevention can allow Clients to redeem tokens to one Origin that were issued after an interaction with another Origin that shares the context. </ins> 2.1.2. Clients can generate multiple tokens from a single TokenChallenge,
Code change:
The section references seem to be breaking the build, so I'll fix that later before we land this.
Origins currently choose whether their challenges are per-origin or cross-origin. For cross-origin, double-spend prevention is only as good as the coordination between origins and the Issuer. Per-origin allows double-spend prevention to be isolated to a single origin; also prevents the cache of tokens being take up by some other origin.
Write this as "any origins that share a redemption context must also share double spend state for that context."

Related discussion:
text: Issuer identity.  Tokens identify which issuers are trusted for a given issuance protocol. <del> Interactive or non-interactive.  Tokens can either be interactive or not.  An interactive token is one which requires a freshly issued token based on the challenge, whereas a non-interactive token can be issued proactively and cached for future use. </del> <ins> Redemption context.  Tokens can be bound to a given redemption context, which influences a client's ability to pre-fetch and cache tokens.  For example, an empty redemption context always allows tokens to be issued and redeemed non-interactively, whereas a fresh and random redemption context means that the redeemed token must be issued only after the client receives the challenge. See Section 2.1.1 of HTTP-Authentication for more details. </ins> Per-origin or cross-origin.  Tokens can be constrained to the Origin for which the challenge originated, or can be used across Origins. Depending on the use case, Origins may need to maintain state to <del> track redeemed tokens.  For example, Origins that accept non- interactive, cross-origin tokens SHOULD track which tokens have been redeemed already, since these tokens can be issued and then spent multiple times in response to any such challenge.  See double-spend for discussion. </del> <ins> track redeemed tokens.  For example, Origins that accept cross-origin across shared redemption contexts tokens SHOULD track which tokens have been redeemed already in those redemption contexts, since these tokens can be issued and then spent multiple times in response to any such challenge.  See Section 2.1.1 of HTTP-Authentication for discussion. </ins> Origins that admit cross-origin tokens bear some risk of allowing tokens issued for one Origin to be spent in an interaction with
Code change:
The section references seem to be breaking the build, so I'll fix that later before we land this.
Origins currently choose whether their challenges are per-origin or cross-origin. For cross-origin, double-spend prevention is only as good as the coordination between origins and the Issuer. Per-origin allows double-spend prevention to be isolated to a single origin; also prevents the cache of tokens being take up by some other origin.
Write this as "any origins that share a redemption context must also share double spend state for that context."

Related discussion:
text: reconstruct a Client's browsing history. Attestation and redemption context unlinkability requires that these <del> events be separated over time, e.g., through the use of non- interactive tokens that can be issued without a fresh Origin challenge, or over space, e.g., through the use of an anonymizing proxy when connecting to the Origin. </del> <ins> events be separated over time, e.g., through the use of tokens with an empty redemption context, or over space, e.g., through the use of an anonymizing proxy when connecting to the Origin. </ins> 4.2.
Code change:
The section references seem to be breaking the build, so I'll fix that later before we land this.
Origins currently choose whether their challenges are per-origin or cross-origin. For cross-origin, double-spend prevention is only as good as the coordination between origins and the Issuer. Per-origin allows double-spend prevention to be isolated to a single origin; also prevents the cache of tokens being take up by some other origin.
Write this as "any origins that share a redemption context must also share double spend state for that context."

Related discussion:
text: 6.1. <del> When applicable for non-interactive tokens, all Origins SHOULD implement a robust storage-query mechanism for checking that tokens sent by clients have not been spent before.  Such tokens only need to be checked for each Origin individually.  But all Origins must perform global double-spend checks to avoid clients from exploiting the possibility of spending tokens more than once against distributed token checking systems.  For the same reason, the global data storage must have quick update times.  While an update is occurring it may be possible for a malicious client to spend a token more than once. 6.2. </del> When a Client holds tokens for an Issuer, it is possible for any verifier to invoke that client to redeem tokens for that Issuer. This can lead to an attack where a malicious verifier can force a
Code change:
The publicly verifiable basic token issuance protocol doesn't include an origin name that the issuer can see, so it does allow origins to be able to use that issuer (as long as the know the key) without explicit coordination or permission from the issuer. This isn't necessarily a problem, but we should likely mention it.

Related discussion:
text: previous variant in two important ways: The output tokens are publicly verifiable by anyone with the <del> Issuer public key; and </del> <ins> Issuer public key. </ins> The issuance protocol does not admit public or private metadata to bind additional context to tokens. <del> Otherwise, this variant is nearly identical.  In particular, Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol.  See public-issuer- configuration for how this key pair is generated. </del> <ins> The first property means that any Origin can select a given Issuer to produce tokens, as long as the Origin has the Issuer public key, without explicit coordination or permission from the Issuer.  This is because the Issuer does not learn the Origin that requested the token during the issuance protocol. Beyond these differences, the publicly verifiable issuance protocol variant is nearly identical to the privately verifiable issuance protocol variant.  In particular, Issuers provide a Private and Public Key, denoted skI and pkI, respectively, used to produce tokens as input to the protocol.  See public-issuer-configuration for how this key pair is generated. </ins> Clients provide the following as input to the issuance protocol:
Code change:
This doesn't go overboard and clarify non-collusion assumptions for all models. It simply states the requirement that entities with access to the attestation context and redemption context do not collude, and then generalizes somewhat for simplicity. cc NAME NAME
The architecture assumes that any two parties do not collude with each other. I think this is too strong an assumption. In particular, if the Origin does not collude with anyone else, what is the point of unlinkability of the issuance and redemption flows? Looking at the use cases, it seems that where the Attester and Issuer are distinct there is a needed non-collusion assumption between them to achieve desirable privacy, but I think the origin colluding with one of the Issuer or Attester should be fine and would be worth considering in scope. Also, in addition to the non-collusion assumption, are there any other assumptions made on the parties, such as honest-but-curious, or do we consider them to be potentially fully malicious? It would be nice to spell this out.
If the Origin colluded with the Issuer it would learn the client's identity (presumably), which would be bad. Ultimately, the desired property is that any sort of collusion that would allow the redemption context to be linked to the attestation context is prohibited. I'll try to clarify.

Related discussion:
text: Issuer portrayed in fig-overview can be instantiated and deployed in a number of ways.  This section covers some expected deployment models and their corresponding security and privacy considerations. <del> The discussion below assumes non-collusion between entities when operated by separate parties.  Mechanisms for enforcing non-collusion are out of scope for this architecture. </del> <ins> The discussion below assumes non-collusion between entities that have access to the attestation context and entities that have access to the redemption context, as collusion between such entities would enable linking of these contexts.  Generally, this means that entities operated by separate parties do not collude.  Mechanisms for enforcing non-collusion are out of scope for this architecture. </ins> 4.1.
Code change:
I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!

Related discussion:
text: used later as described in private-finalize.  The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request is <del> "message/token-request".  An example request is shown below. </del> <ins> "application/private-token-request".  An example request is shown below. </ins> Upon receipt of the request, the Issuer validates the following conditions:
Code change:
I also moved from the message namespace to the application namespace. The difference is helpfully summarized .
I see in the current draft that they register and . Since "token" is a very broad term, I'm wondering if something slightly more specific to Privacy Pass such as and might be reasonable?
If we make it more specific, it should be "private" instead of "privacy", to be "private-token" and align with the auth scheme. There's a fair amount of deployment on these types today, so this would be a relatively large change, or servers would need to tolerate both versions.
I'm in favor of making this change and having issuers support both for a little while.
Cool, that would work. NAME want to make the proposed update?
Will do!
NAME PR's up!
Looks good!

Related discussion:
text: where Ns is as defined in OPRF, Section 4. The Issuer generates an HTTP response with status code 200 whose body <del> consists of TokenResponse, with the content type set as "message/ token-response". </del> <ins> consists of TokenResponse, with the content type set as "application/ private-token-response". </ins> 5.3.