jiebi/CodeConvo huggingface dataset:
Change:
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.

Discussion:
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 <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> <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.
Change:
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.

Discussion:
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> <ins> Paul Rowe, Hannes Tschofenig, Frank Xia, and David Wooten. </ins> 15.
Change:
For anyone unfamiliar with TLS struct notation, spell out the length fields in the text.

Discussion:
"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> <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 <del> either 0 or 32 bytes.  Challenges with redemption_context values </del> <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 <del> origin.  This allows a token to be scoped to a specific origin. If empty, any non-origin specific token can be redeemed. </del> <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:
Change:
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 .

Discussion:
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> <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 <del> Protocol", and "Token" as defined in I-D.ietf-privacypass- architecture.  It additionally uses the following terms in more specific ways: </del> <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.
Change:
This is a breaking change since it updates the value of the code points. Starting as a draft until I'm able to produce matching test vectors.
Hm, I was thinking we'd just fully specify the types 1 and 2 right now, rather than trying to define a bunch of different combinations up front. Is there a benefit to listing all of the combinations out? Since for interop we want convergence on types, why not just have a very standard 1 and 2?
Convergence seems orthogonal to the values here, no? Implementations could just pick a common type, as we've done for ECH, HPKE, etc. It seems important to offer flexibility here for applications that might need it.
For the common web cases, where we have websites that want to work with the wide range of clients, I'd prefer to see a very clear option of what to use by default — with one for privately verifiable, and one for publicly verifiable. If people have use cases that can't use these algorithms (like we've seen for IOT use cases, etc, for other protocols), I'd rather see those defined when there's a profile that has a driving use case. For example, we could end up defining a full matrix of different SHA lengths and key sizes (they're all 4096 right now for RSA, but we could have others) and that seems unnecessary.
Well, we can RECOMMEND issuance protocols for common use cases, as we've done for ECH.
Reverted type2 change!
NAME this is good to go now -- please have a look!
The SPKI format is currently unspecified, and as there are multiple ways to encode an RSA public key (and hash algorithm), this makes interop somewhat difficult. Moreover, the SPKI can encode any number of RSA public key sizes, in contrast to elliptic curves wherein the "suite" typically defines the key size. In the name of simplicity, I'd propose that we have the identifier fully specify everything one needs to use the algorithm, including key size, hash algorithm, and encoding format.
Clarified that this would mean that each token type fully specifies the algorithms and sizes it uses. I support this.
Right, specifically, I think each type would specify: Hash algorithm Public key (and signature) size Public key encoding There's a large number of permutations here, e.g., SHA-256, 4096-bit key, RSASSA-PSS OID SPKI SHA-256, 2048-bit key, RSASSA-PSS OID SPKI ...

Discussion:
Issuers are configured with Private and Public Key pairs, each denoted skI and pkI, respectively, used to produce tokens.  Each key <del> pair MUST be generated as as a valid 4096-bit RSA private key according to [TODO].  The key identifier for a keypair (skI, pkI), denoted "key_id", is computed as SHA256(encoded_key), where encoded_key is a DER-encoded SubjectPublicKeyInfo object carrying pkI. </del> <ins> pair SHALL be generated as as specified in FIPS 186-4 DSS. The key identifier for a keypair (skI, pkI), denoted "key_id", is computed as SHA256(encoded_key), where encoded_key is a DER-encoded SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object MUST use the RSASSA-PSS OID RFC5756, which specifies the hash algorithm and salt size.  The salt size MUST match the output size of the hash function associated with the public key and token type. </ins> 7.
Change:
Is this the most exact way to put this? For byte arrays like a hash, I generally don't think of it as being network- or host- byte order. Do we have other docs that refer to stuff like this that we can crib from?
Nothing comes to mind right now, but I'm happy to look at alternatives.
Works for me =)
We should be explicit about what this means: This means that the byte is the last/rightmost byte of the hash, in order. Misinterpretation of this caused some confusion in interop.
Here's an attempt at saying this in other words to be extra clear?

Discussion:
"token_type" is a 2-octet integer, which matches the type in the challenge. <del> "token_key_id" is the least significant byte of the "key_id". </del> <ins> "token_key_id" is the least significant byte of the "key_id" in network byte order (in other words, the last 8 bits of "key_id"). </ins> "blinded_msg" is the Ne-octet blinded message defined above, computed as "SerializeElement(blinded_element)".  Ne is as defined

"token_type" is a 2-octet integer, which matches the type in the challenge. <del> "token_key_id" is the least significant byte of the "key_id". </del> <ins> "token_key_id" is the least significant byte of the "key_id" in network byte order (in other words, the last 8 bits of "key_id"). </ins> "blinded_msg" is the Nk-octet request defined above.
Change:
Updated to use random values
NAME please take a look!
Origins can issue challenges for greased token types, etc, to ensure client can handle new types in the future.
One type of greasing might be adding random authentication credentials to the header, e.g., .
We should recommend servers to send greased token types + parameters, as well as clients to send greased credentials.

Discussion:
Reference: Where this algorithm is defined <ins> This document defines several Reserved values, which can be used by clients and servers to send "greased" values in token challenges and responses to ensure that implementations remain able to handle unknown token types gracefully (this technique is inspired by RFC8701).  Implemenations SHOULD select reserved values at random when including them in greased messages.  Servers can include these in TokenChallenge structures, either as the only challenge when no real token type is desired, or as one challenge in a list of challenges that include real values.  Clients can include these in Token structures when they are not able to present a real token response.  The contents of the Token structure SHOULD be filled with random bytes when using greased values. </ins> The initial contents for this registry are defined in the table below.
Change:
This is both a convenience for origins, as well as a way to support key rotation.
Thanks for this. IIUC the key rotation interval for non-rate-limited token issuance may be ambiguous. Since there is not necessarily a policy window defined in that case. Is that right? This would be manageable be convention; and trivial when a single entity controls both the issuer and origin.
Correct. The rotation window is currently not specified. Omitting that seems reasonable for this case. Origins can simply check in with issuers at some regular cadence as they deem fit.
The security considerations of the auth scheme should mention 0-RTT specifically in its discussion of token replay.

Discussion:
3. <del> Issuers MUST provide one parameter for configuration: </del> <ins> Issuers MUST provide two parameters for configuration: </ins> Issuer Request URI: a token request URL for generating access tokens.  For example, an Issuer URL might be https://issuer.example.net/example-token-request.  This parameter uses resource media type "text/plain". <ins> Issuer Public Key values: an Issuer Public Key for an issuance protocol. </ins> The Issuer parameters can be obtained from an Issuer via a directory <del> object, which is a JSON object whose field names and values are raw values and URLs for the parameters. </del> <ins> object, which is a JSON object whose values are other JSON objects and URLs for the parameters. Each "token-keys" JSON object contains the following fields and corresponding raw values. Issuers MAY advertise multiple token-keys for the same token-type to support key rotation.  In this case, Issuers indicate preference for which token key to use based on the order of keys in the list, with preference given to keys earlier in the list. </ins> <del> As an example, the Issuer's JSON directory could look like: </del> <ins> Altogether, the Issuer's JSON directory could look like: </ins> Issuer directory resources have the media type "application/json" and are located at the well-known location /.well-known/token-issuer-
Change:
cc NAME
draft-ietf-privacypass-architecture says in section 3.2: Is that correct? Isn't the 'token-key' in draft-ietf-privacypass-auth-scheme providing the pub key? Or do I misunderstand something here?
Oops, yep, good catch! We'll fix this.

Discussion:
privacy impacts of the protocol, why these impacts are justified, and guidelines on changes to the parametrization in parametrization. <del> The mechanism by which clients obtain the Issuer public key is not specified.  Clients may be configured with this key or they may discover it via some other form.  See CONSISTENCY. </del> <ins> Clients obtain the Issuer public key directly from the Origin using the process described in HTTP-Authentication.  Clients MAY apply some form of key consistency check to determine if this public key is consistency and correct for the specified Issuer.  See CONSISTENCY for example mechanisms.  Depending on the deployment, the Attester may be able to assist the Client in applying these consistency checks across clients. </ins> Depending on the use case, issuance may require some form of Client anonymization service similar to an IP-hiding proxy so that Issuers

For certain types of issuance protocols, this model separates attestation and redemption contexts.  However, Issuance protocols that require the Issuer to learn information about the Origin, such <del> as that which is described in [rate-limited], are not appropriate since they could link attestation and redemption contexts through the </del> <ins> as that which is described in RATE-LIMITED, are not appropriate since they could link attestation and redemption contexts through the </ins> Origin name. 4.3.

This is the most general deployment model, and is necessary for some types of issuance protocols where the Attester plays a role in token <del> issuance; see [rate-limited] for one such type of issuance protocol. </del> <ins> issuance; see RATE-LIMITED for one such type of issuance protocol. </ins> In this model, the Attester, Issuer, and Origin have a separate view of the Client: the Attester sees potentially sensitive Client identifying information, such as account identifiers or IP addresses,
Change:
We current state this as the requirement: This could be misread in that we do allow forgeries when interacting with the Issuer directly. Clearly that's not the intent, so let's fix this.

Discussion:
One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens <del> without interacting with the Issuer directly. </del> <ins> offline or otherwise without interacting with the Issuer directly. </ins> Concurrent security.  The issuance protocol MUST be safe to run concurrently with arbitrarily many Clients.
Change:
From IETF 114 discussion: For the general captcha use cases, we don't want websites to rely on privacy pass always working, to preventing locking out other clients. We should likely have discussion in the architecture document to suggest approaches to make sure servers can't rely on this for generic clients (like browsers). Randomly not responding with tokens, other client-side heuristics.
I would put this in the auth-scheme document, where we already discuss user experience things. I'll propose some text that we can wordsmith.

Discussion:
to a different issuer or a different token type, to allow clients to choose a preferred issuer or type. <ins> An origin MUST NOT assume that token challenges will always yield a valid token.  Clients might experience issues running the issuance protocol, e.g., because the attester or issuer is unavailable, or clients might simply not support the requested token type.  Origins SHOULD account for such operational or interoperability failures by offering clients an alternative type of challenge such as CAPTCHA for accessing a resource. To mitigate the risk of deployments becoming dependent on tokens, clients and servers SHOULD grease their behavior unless explicitly configured not to.  In particular, clients SHOULD ignore token challenges with some non-zero probability.  Likewise, origins SHOULD randomly choose to not challenge clients for tokens with some non- zero probability.  Moreover, origins SHOULD include random token types in token challenges with some non-zero probability. </ins> 4. The security properties of token challenges vary depending on whether
Change:
cc NAME
Over a long enough timeline, attestations will be broken - through willful post-boot compromise, malware, or other means. Services that depend on attestations (consumers of access tokens) will observe clients that appear to pass attestation, but engage in behavior that indicates that the device is compromised (e.g. trigger thousands of interactions per second). As it stands, the service consuming access tokens is not able to provide feedback that these attestations appear to be false negatives, and should be re-examined by the attester. Even if this feedback were to be provided out of band, it will be challenging for the attester to identify which devices are compromised and diagnose the nature of the compromise. I do not anticipate that this will become a pressing issue until the initial attestations are compromised, but it may be helpful to plan ahead for this scenario.
Thanks, NAME This seems like something we ought to discuss in the architecture document.

Discussion:
past day.  Attesters should not admit attestation types that result in small anonymity sets. <ins> The trustworthiness of attesters depends on their ability to correctly and reliably perform attestation during the issuance protocol.  However, in practice, certain types of attestation can vary in value over time, e.g., if the attestation process is compromised or maliciously automated.  These are considered exceptional events and require configuration changes to address the underlying cause.  For example, if attestation is compromised because of a zero-day exploit 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 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. </ins> 3.2.2. Issuers MUST be uniquely identifiable by all Clients with a
Change:
cc NAME
LGTM!
Is unconditional input secrecy meant to mean similar to unconditionally hiding? If so, this probably deserves more explanation and justification in the architecture document as a requirement; otherwise, a different term should probably be used.
To my knowledge unconditional input secrecy is the standard term here. What do you think should be added to resolve this issue?
I guess my main question is why is unconditional secrecy a requirement here?
Because we don't want the server to learn anything about the client's private input regardless of its computational power. Take blind RSA as an example, which has this property. While a PQ adversary could break RSA, it could not learn the client's private input from a protocol trace.
I think this should be spelled out explicitly; i.e., say explicitly that the client's private input should remain private even if some of the cryptographic hardness assumptions underlying the protocol become falsified. I wonder if this would be a good place to use a SHOULD vs a MUST. I can see how unconditional secrecy is a desirable property, but, e.g., TLS doesn't have it for obvious reasons.
I sent a PR for (1). I don't think we should relax (2). Future versions of the architecture can update this requirement to relax as desired.

Discussion:
Unconditional input secrecy.  The issuance protocol MUST NOT reveal anything about the Client's private input, including the <del> challenge and nonce, to the Attester or Issuer.  The issuance protocol can reveal the Issuer public key for the purposes of determining which private key to use in producing the token.  A result of this property is that the redemption flow is unlinkable from the issuance flow. </del> <ins> challenge and nonce, to the Attester or Issuer, regardless of the hardness assumptions of the underlying cryptographic protocol(s). The issuance protocol can reveal the Issuer public key for the purposes of determining which private key to use in producing the token.  A result of this property is that the redemption flow is unlinkable from the issuance flow. </ins> One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens
Change:
cc NAME
E.g., consider a protocol where the Issuer signs a commitment to the token challenge. This fails as an unlinkable anonymous credentials because the signature is not randomized, but is has input secrecy because of the commitment.
In this hypothetical example, is the commitment not revealed during redemption? If so, I think we could address this by saying that input secrecy is necessary but insufficient for unlinkability. Thoughts?

Discussion:
hardness assumptions of the underlying cryptographic protocol(s). The issuance protocol can reveal the Issuer public key for the purposes of determining which private key to use in producing the <del> token.  A result of this property is that the redemption flow is unlinkable from the issuance flow. </del> <ins> token. </ins> One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens