4.3. By definition, the Attester role takes on the duty to create <del> Evidence.  The fact that an Attester role is composed of several types of environments that can be nested or staged adds complexity to the architectural layout of how an Attester - in itself - is composed and therefore has to conduct the Claims collection in order to create believable Attestation Evidence.  The following example is intended to illustrate this composition: A very common example is elaborated on to illustrate Layered Attestation. The very first Attesting Environment has to ensure the integrity of the (U)EFI / BIOS / Firmware that initially boots up a composite device (e.g., a cell phone). These Claims have to be measured securely.  At this stage of the boot-cycle of a composite device, the Claims collected typically cannot be composed into Evidence. The very first Attesting Environment in this example can be a hardware component that is a Static Code Root of Trust.  As in any other scenario, this hardware component is the first Attesting Environment.  It collects a rather concise number of Claims about the Target Environment.  The Target Environment in this example is the (U)EFI / BIOS / Firmware After the boot sequence started, the Target Environment conducts the most important and defining feature of Layered Attestation: The successfully measured environment that is the (U)EFI / BIOS / Firmware now becomes the Attesting Environment. Analogously, the Attesting Environment hands off its duty to one of its Target Environments.  This procedure in Layered Attestation is called Staging. Now, the duties have been transferred and Layered Attestation takes place.  The initial Attesting Environment relinquishes its duties to the Target Environment.  It is important to note that the new Attesting Environment cannot alter the content about its own measurements.  If the Attesting Environment would be able to do that, Layered Attestation would become unfeasible. In this example the duty of being the Attesting Environment is now taken over by the (U)EFI / BIOS / Firmware that was the Attested Environment before.  This transfer of duty is the essential part of Layered Attestation.  The (U)EFI / BIOS / Firmware now is the Attesting Environment.  The next Target Environment is, in this example, a bootloader.  There are potentially multiple kernels to boot, the decision is up to the bootloader.  Only a bootloader with intact integrity will make an appropriate decision.  Therefore, Claims about the integrity of a bootloader are now collected by the freshly appointed Attesting Environment that is the (U)EFI / BIOS / Firmware.  Collected Claims have to be stored by the current Attesting Environment in a similar shielded and secured manner, so that the next Attesting Environment is not capable of altering the collection of claims stored. Continuing with this example, the bootloader is now in charge of collecting Claims about the next execution environment.  The next execution environment in this example is the kernel to be booted up. Analogously, the next transfer of duties in this Layered Attestation example occurs: The duty of being an Attesting Environment is transferred to a successfully measured kernel.  In this sequence, the kernel is now collecting additional Claims and is storing them in a secure and shielded manner. The essence of this example is a cascade of staged boot environments. Each environment (after the initial one that is a root-of-trust) has the duty of measuring its next environment before it is started. Therefore, creating a layered boot sequence and correspondingly enabling Layered Attestation. </del>  4.4.

A proposal for addressing a FIXME as called out in issue Signed-off-by: Dave Thaler
Since people didn't like the previous version of this PR, I rewrote the layered attestation section to not need to define a term at all. Now it just uses one specific example to illustrate the concept, rather than trying to combine multiple variations in the same text.
Section 3.1 of the draft says: This fixme needs to be fixed somehow.
There are also still statements like these in section 4.3: and
Regarding "we are looking for a better term than UEFI/BIOS/Firmware", what do folks think about "first mutable environment"? Example in context: OLD: The very first Attesting Environment has to ensure the integrity of the (U)EFI / BIOS / Firmware that initially boots up a composite device (e.g., a cell phone). NEW: he very first Attesting Environment has to ensure the integrity of the first mutable environment that initially boots up a composite device (e.g., a cell phone).
We have a terminology convention for the thing being referred to as “UEFI/BIOS/FW/FMC etc.” called “Target Environment”. We should use our preferred abstract terminology then provide intuition in the form of examples NEW2: The very first Attesting Environment has to ensure the integrity of the Target Environment (e.g. the BIOS, firmware or first mutable environment that initially boots up a composite device). I don’t believe the example of a cell phone is helpful. Cell phones neither use BIOS (AFAIK) or commonly use the term ‘first mutable environment’.
No, those terms are not synonymous. In layered attestation, the UEFI/BIOS/firmware is also an "Attesting Environment", and software above it (or started later than it) are also Target Environments, so we cannot use the term Target Environment to mean UEFI/BIOS/firmware in general. See PR for proposed use in context.
I agree with the text in as it doesn’t use either Attesting Env or Target Env. The issue I have with NEW is the asymmetrical use of terms “Attesting Env” and other stuff not “Target Env”. If use of Target Env is wrong then so is use of Attesting Env. The section on “Two Environments” makes these terms clear and their applicationin a Layered Device attestation also clear (in terms of cascaded measurement, attestations and executions). Are you suggesting the resolution to is to substitute with text from ? Thx, Ned
I believe this can be closed now that is merged.

4.3. By definition, the Attester role takes on the duty to create  <ins> Evidence.  The fact that an Attester role is composed of environments that can be nested or staged adds complexity to the architectural layout of how an Attester can be composed and therefore has to conduct the Claims collection in order to create believable attestation Evidence. layered depicts an example of a device that includes (A) a BIOS stored in read-only memory in this example, (B) an updatable bootloader, and (C) an operating system kernel. Attesting Environment A, the read-only BIOS in this example, has to ensure the integrity of the bootloader (Target Environment B).  There are potentially multiple kernels to boot, and the decision is up to the bootloader.  Only a bootloader with intact integrity will make an appropriate decision.  Therefore, these Claims have to be measured securely.  At this stage of the boot-cycle of the device, the Claims collected typically cannot be composed into Evidence. After the boot sequence is started, the BIOS conducts the most important and defining feature of layered attestation, which is that the successfully measured Target Environment B now becomes (or contains) an Attesting Environment for the next layer.  This procedure in Layered Attestation is sometimes called "staging".  It is important that the new Attesting Environment B not be able to alter any Claims about its own Target Environment B.  This can be ensured having those Claims be either signed by Attesting Environment A or stored in an untamperable manner by Attesting Environment A. Continuing with this example, the bootloader's Attesting Environment B is now in charge of collecting Claims about Target Environment C, which in this example is the kernel to be booted.  The final Evidence thus contains two sets of Claims: one set about the bootloader as measured and signed by the BIOS, plus a set of Claims about the kernel as measured and signed by the bootloader. This example could be extended further by, say, making the kernel become another Attesting Environment for an application as another Target Environment, resulting in a third set of Claims in the Evidence pertaining to that application. The essence of this example is a cascade of staged environments. Each environment has the responsibility of measuring the next environment before the next environment is started.  In general, the number of layers may vary by device or implementation, and an Attesting Environment might even have multiple Target Environments that it measures, rather than only one as shown in layered. </ins> 4.4.


10. <del> It is important to prevent replay attacks where an attacker replays old Evidence or an old Attestation Result that is no longer correct. To do so, some mechanism of ensuring that the Evidence and Attestation Results are fresh, meaning that there is some degree of assurance that they still reflect the latest state of the Attester, and that any Attestation Results were generated using the latest Evidence and Appraisal Policy for Evidence.  There is, however, always a race condition possible in that the state of the Attester, and the Appraisal Policy for Evidence, might change immediately after the Evidence or Attestation Results were generated.  The goal is merely to narrow the time window to something the Verifier (for Evidence) or Relying Party (for an Attestation Result) is willing to accept. There are two common approaches to providing some assurance of freshness.  The first approach is that a nonce is generated by a remote entity (e.g., the Verifier for Evidence, or the Relying Party for an Attestation Result), and the nonce is then signed and included along with the claims in the Evidence or Attestation Result, so that the remote entity knows that the claims were signed after the nonce was generated. A second approach is to rely on synchronized clocks, and include a signed timestamp (e.g., using I-D.birkholz-rats-tuda) along with the claims in the Evidence or Attestation Result, so that the remote entity knows that the claims were signed at that time, as long as it has some assurance that the timestamp is correct.  This typically requires additional claims about the signer's time synchronization mechanism in order to provide such assurance. In either approach, it is important to note that the actual values in claims might have been generated long before the claims are signed. If so, it is the signer's responsibility to ensure that the values are still correct when they are signed.  For example, values might have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot. </del>  A more detailed discussion with examples appears in time- considerations.

This commit slightly changes the Freshness section to reflect the outcome of the discussion around PR . (Hopefully I've managed to capture the gist of Henk's thinking without disrupting too much the existing flow.) TL;DR The key change here is the removal of reply protection as a goal in itself. The section now states clearly that the overall goal is instead the identification of the point in time when attestation claims have been signed and/or generated so that a freshness policy can be applied. In this perspective, the fundamental property provided by a nonce-based scheme with regards to freshness is its ability to lock the requester's clock to the underlying protocol transaction, thus indirectly establishing the epoch of the attestation / verification event. By making the nonce unique and non-predictable, the timeline locking cannot be subverted, which provides anti-replay. However, that is a nice side-effect rather than the primary goal. This commit also adds some precision around the nonce and clock properties - unpredictability and trustworthiness respectively.
Added consolidated text based on Thomas initial version and review from MCR
So, if is dead, can you close it?
Done.

10.  <ins> A remote entity (Verifier or Relying Party) may need to learn the point in time (i.e., the "epoch") an Evidence or Attestation Result has been produced.  This is essential in deciding whether the included Claims and their values can be considered fresh, meaning they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. Freshness is assessed based on a policy defined by the consuming entity, Verifier or Relying Party, that compares the estimated epoch against an "expiry" threshold defined locally to that policy.  There is, however, always a race condition possible in that the state of the Attester, and the Appraisal Policy for Evidence, 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) 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). There are two common approaches for determining the epoch of an Evidence or Attestation Result. The first approach is to rely on synchronized and trustworthy clocks, and include a signed timestamp (see I-D.birkholz-rats-tuda) along with the Claims in the Evidence or Attestation Result.  Timestamps can be added on a per-Claim basis, to distinguish the time of creation of Evidence or Attestation Result from the time that a specific Claim was generated.  The clock's trustworthiness typically requires additional Claims about the signer's time synchronization mechanism. A second approach places the onus of timekeeping solely on the appraising entity, e.g., the Verifier (for Evidence), or the Relying Party (for Attestation Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time synchronisation is otherwise impaired.  In this approach, a non- predictable nonce is sent by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or Attestation Result.  After checking that the sent and received nonces are the same, the appraising entity knows that the Claims were signed after the nonce was generated.  This allows associating a "rough" epoch to the Evidence or Attestation Result.  In this case the epoch is said to be rough because: The epoch applies to the entire claim set instead of a more granular association, and The time between the creation of Claims and the collection of Claims is indistinguishable. Implicit and explicit timekeeping can be combined into hybrid mechanisms.  For example, if clocks exist and are considered trustworthy but are not synchronized, a nonce-based exchange may be used to determine the (relative) time offset between the involved peers, followed by any number of timestamp based exchanges.  In another setup where all Roles (Attesters, Verifiers and Relying Parties) share the same broadcast channel, the nonce-based approach may be used to anchor all parties to the same (relative) timeline, without requiring synchronized clocks, by having a central entity emit nonces at regular intervals and have the "current" nonce included in the produced Evidence or Attestation Result. It is important to note that the actual values in Claims might have been generated long before the Claims are signed.  If so, it is the signer's responsibility to ensure that the values are still correct when they are signed.  For example, values generated at boot time might have been saved to secure storage until network connectivity is established to the remote Verifier and a nonce is obtained. </ins> A more detailed discussion with examples appears in time- considerations.


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.

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.

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.


platforms involving multiple vendors and providers. Amongst other things, this document is about trust and <del> trustworthiness.  Trust is a decision being made.  Trustworthiness is a quality that is assessed via evidence created.  This is a subtle </del>  difference and being familiar with the difference is crucial for using this document.  Additionally, the concepts of freshness and trust relationships with respect to RATS are elaborated on to enable that collectively cover all the functionality required in the architecture. <del> Each use case includes a description, and a summary of what an Attester and a Relying Party refer to in the use case. </del>  3.1. <del> Network operators want a trustworthy report of identity and version of information of the hardware and software on the machines attached to their network, for purposes such as inventory, auditing, and/or logging.  The network operator may also want a policy by which full </del>  access is only granted to devices that meet some definition of health, and so wants to get claims about such information and verify their validity.  Remote attestation is desired to prevent vulnerable Typically, solutions start with a specific component (called a "Root of Trust") that provides device identity and protected storage for <del> measurements.  These components perform a series of measurements, and express this with Evidence as to the hardware and firmware/software that is running. </del>  A device desiring access to a network 3.2. <del> A device manufacturer wants to protect its intellectual property in terms of the ML model it developed and that runs in the devices that its customers purchased, and it wants to prevent attackers, potentially including the customer themselves, from seeing the details of the model. </del>  This typically works by having some protected environment in the device attest to some manufacturer service.  If remote attestation This is a generalization of the ML model use case above, where the data can be any highly confidential data, such as health data about customers, payroll data about employees, future business plans, etc. <del> Attestation is desired to prevent leaking data to compromised devices. </del>  An entity desiring to retrieve confidential data

based on: Based on URL used "integrity" instead of "hygine" for now used "evaluate" instead of "verify" for now
Kathleen's comment: Did you consider the more commonly used, "hygiene"? Greetings! I took some time to review the current version of the architecture document and have some comments and suggestions. The comments are from the editor's version. Please do post early and often updates to the IETF draft repository. Version numbers do not matter, it's okay to have a large number :-) These are meant to be helpful comments to improve the draft. Introduction: Could we change: From: Trust is a decision being made. To: To trust is a decision that spans beyond the technical assertions. I struggle a little with the following: "Trustworthiness is a quality that is assessed via evidence created." As when one determines trustworthiness, it may span beyond evidence that is "created". Perhaps drop the word created? I think it spans beyond that as well, but may be too nit picky to expand. The evidence could have to do with something other then the system and those who manage it for instance. Terminology: The following definition should be just for "appraisal policy" unless there are other types of appraisal policies in context for this body of work: Appraisal Policy for Attestation Result: A set of rules that direct how a Relying Party uses the Attestation Results regarding an Attester generated by the Verifiers. Compare /security policy/ in [RFC4949] I don't think direct is the right word. If this is so you can make judgments on relying party decisions, the policy is more of a statement on the decision process than how they are directed, which could be more subjective. The verifier here reads as if they generate the policy, but are verifying against a set policy. Proposed: A set of rules for a Relying Party to verify attestation results. The following 'definition' seems to get into role recommendations rather than being a definition: Attester: An entity whose attributes must be appraised in order to determine whether the entity is considered trustworthy, such as when deciding whether the entity is authorized to perform some operation Shouldn't this stick to what an attester is/does? Perhaps: attester - entity who puts forth data that may include configuration or static system information, evidence, or claims. The evidence may be digitally signed. For evidence, should this definition be more about what evidence is rather than about the roles involved? The attester may not be the same component or system that attests to the evidence as well. Evidence could be measurement data, telemetry (e.g. counters on a system interface - YANG or SNMP), results of a policy comparison to configuration data). Evidence: A set of information about an Attester that is to be appraised by a Verifier Perhaps: Evidence: Information about or originating from a system/firmware/software that may include configuration data, measurements, telemetry, or inferences. Is the following definition necessary? Verifier Owner: An entity, such as an administrator, that is authorized to configure Appraisal Policy for Evidence in a Verifier Section 3: Consider changing the following sentence: From: " Each use case includes a description, and a summary of what an Attester and a Relying Party refer to in the use case." To: " Each use case includes a description followed by a summary of the Attester and a Relying Party roles." Section 3.1: Sentence 1: Consider changing from: "Network operators want a trustworthy report of identity and version of information of the hardware and software on the machines attached to their network, for purposes such as inventory, auditing, and/or logging." To: "Network operators want a trustworthy report that includes identity and version of information of the hardware and software on the machines attached to their network, for purposes such as inventory, audit, anomaly detection, record maintenance and/or trending reports (logging)." In the following sentence, "health" is fine, but did you consider the more commonly used, "hygiene"? >From the editor's version: "Typically, solutions start with a specific component (called a "Root of Trust") that provides device identity and protected storage for measurements. These components perform a series of measurements, and express this with Evidence as to the hardware and firmware/software that is running." Perhaps better stated as: "Typically, solutions start with a specific component (called a "Root of Trust") that provides device identity and protected storage for measurements. The system components perform a series of measurements that may be signed by the Root of Trust, considered as Evidence of the hardware, firmware, BIOS, software, etc. that is running." "express this with" is confusing and possibly misleading. This proposed phrasing allows for evidence to be broader than the series of measurements as it might include system or configuration information. It's not the RoT that does the measurements, but they do attest to it. Would the attester in this example be the root of trust of the device rather than the full system? Section 3.2: Perhaps change the wording from: "A device manufacturer wants to protect its intellectual property in terms of the ML model it developed and that runs in the devices that its customers purchased, and it wants to prevent attackers, potentially including the customer themselves, from seeing the details of the model." To: "A device manufacturer wants to protect its intellectual property. This is primarily the ML model it developed and runs in the devices purchased by its customers. The goals for the protection include preventing attackers, potentially the customer themselves, from seeing the details of the model." I'm confused by the phrasing of the rest of the section and am wondering if it can be improved. Current: "This typically works by having some protected environment in the device attest to some manufacturer service. If remote attestation succeeds, then the manufacturer service releases either the model, or a key to decrypt a model the Attester already has in encrypted form, to the requester. Attester: A device desiring to run an ML model to do inferencing Relying Party: A server or service holding ML models it desires to protect" I think it would help to talk about inferences in the written description. For the attester, if it's the whole system as opposed to a component, then then definition makes sense. I'm wondering if it is crisper when narrowed. RoT captures inferences of the ML modeling used as evidence. Does the relying party hold the ML model or knowledge of expected inferences? I'm happy to propose alternative text once I have more information to more fully understand the use case. Section 3.3:This one took a couple of reads to understand. While it is understandable, it could be more explicit to make it easier to get on first read. How about changing the following From: Attestation is desired to prevent leaking data to compromised devices. To: "An assessment of system hygiene is made against a set of policies to verify the state of a system using attestations for the system requesting data. Attestation is desired to prevent leaking data to compromised devices." Section 3.6 Nit: From: "One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates to be applied. " To: "One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. Remote attestation aids in the verification process that may occur locally as well as it is less likely that the policy or verification processes have also been compromised if hosted on a separate system." The second sentence is suggested as this also occurs locally on systems today, but there is value in having this via remote attestation. I'll send the next batch when I get far enough through the document. I didn't want to hold up on these comments. Thank you for all your work on the document! Best regards, Kathleen

platforms involving multiple vendors and providers. Amongst other things, this document is about trust and  <ins> trustworthiness.  Trust is a choice one makes about another system. Trustworthiness is a quality about the other system that can be used in making one's decision to trust it or not.  This is subtle </ins> difference and being familiar with the difference is crucial for using this document.  Additionally, the concepts of freshness and trust relationships with respect to RATS are elaborated on to enable that collectively cover all the functionality required in the architecture.  <ins> Each use case includes a description followed by a summary of the Attester and a Relying Party roles. </ins> 3.1.  <ins> Network operators want a trustworthy report that includes identity and version of information of the hardware and software on the machines attached to their network, for purposes such as inventory, audit, anomaly detection, record maintenance and/or trending reports (logging).  The network operator may also want a policy by which full </ins> access is only granted to devices that meet some definition of health, and so wants to get claims about such information and verify their validity.  Remote attestation is desired to prevent vulnerable Typically, solutions start with a specific component (called a "Root of Trust") that provides device identity and protected storage for  <ins> measurements.  The system components perform a series of measurements that may be signed by the Root of Trust, considered as Evidence about the hardware, firmware, BIOS, software, etc. that is running. </ins> A device desiring access to a network 3.2.  <ins> A device manufacturer wants to protect its intellectual property. This is primarily the ML model it developed and runs in the devices purchased by its customers.  The goals for the protection include preventing attackers, potentially the customer themselves, from seeing the details of the model. </ins> This typically works by having some protected environment in the device attest to some manufacturer service.  If remote attestation This is a generalization of the ML model use case above, where the data can be any highly confidential data, such as health data about customers, payroll data about employees, future business plans, etc.  <ins> An assessment of system state is made against a set of policies to evaluate the state of a system using attestations for the system requesting data.  Attestation is desired to prevent leaking data to compromised devices. </ins> An entity desiring to retrieve confidential data


issuance protocol to actually fetch tokens to redeem. In addition to working with different token issuance protocols, this <del> scheme supports both interactive (online challenges) and non- interactive (pre-fetched) token redemption, as well as the ability to scope a token to a specific resource or origin.  Relying parties that request and redeem tokens can choose a specific kind of token, as appropriate for its use case.  For example, non-interactive token redemption that is not scoped to a specific origin can be used as a replacement for CAPTCHAs, as exemplified by the original Privacy Pass work DGSTV18. </del>  1.1. Unless otherwise specified, this document encodes protocol messages in TLS notation from TLS13, Section 3. <del> This document uses the following terms to refer to various roles and functions in the Privacy Pass architecture: Client: A client is a application or device, generally operated by a user, that can be issued tokens via an issuance protocol, and can redeem these tokens with an origin. Origin: An HTTP server that acts as the relying party and can redeem tokens presented by a client.  When used in a web context, this represents the origin the client is accessing. Token: A signed message that can be issued to a client and redeemed without allowing token redemption to be linked to issuance. Interactive / non-interactive token: An interactive token signs a nonce generated by an origin as part of a challenge for tokens. This means that the client needs to fetch a new token for this challenge in order to redeem it and cannot use a pre-fetched token.  A non-interactive token is one that can be pre-fetched. Issuance protocol: A protocol by which the client fetches tokens. Every issuance protocol includes two functions: validating or authenticating the client, and issuing a token to the client. Issuer: An entity that generates tokens for clients using one or more issuance protocols.  An Issuer is identified by an Issuer name. </del>  Issuer key: Keying material that can be used with an issuance protocol to create a signed token. Token challenge: A requirement for tokens sent from an origin to a <del> client, using the "WWW-Authenticate" HTTP header.  This may be a challenge for an interactive token or a non-interactive token.  A challenge defines the issuance protocol and issuer name to use for a token. </del>  Token redemption: An action by which a client presents a token to an origin, using the "Authorization" HTTP header. is a hostname that is used to identify the issuer that is allowed to issue tokens that can be redeemed by this origin. <del> "redemption_nonce" is an optional field.  If present, it indicates that a client needs to present an interactive token, generated specifically in response to this challenge.  If empty, the client can use a non-interactive token.  When present, this valid is a fresh 32-byte nonce generated by the origin for each challenge. Valid lengths for this field are either 0 or 32 bytes.  Challenges with redemption_nonce values of invalid lengths MUST be ignored. </del>  "origin_name" is an optional string containing the name of the origin.  This allows a token to be scoped to a specific origin. "nonce" is a 32-octet message containing a client-generated random nonce. <del> "context" is a 32-octet message containing the hash of the original TokenChallenge, SHA256(TokenChallenge). </del>  "token_key_id" is an Nid-octet identifier for the the token authentication key.  The value of this field is defined by the For token types that support public verifiability, origins verify the token authenticator using the public key of the issuer, and validate that the signed message matches the concatenation of the client nonce <del> and the hash of a valid TokenChallenge.  For interactive tokens, origins store the nonces of previous TokenChallenge structures in order to validate uniqueness.  A TokenChallenge MAY be bound to a specific HTTP session with client, but origins can also accept tokens for valid challenges in new sessions.  For non-interactive tokens, origins SHOULD implement some form of double spend prevention that prevents a token with the same nonce from being redeemed twice.  This prevents clients from "replaying" tokens for previous challenges. </del>  If a client is unable to fetch a token, it MUST react to the challenge as if it could not produce a valid Authorization response. Note that the issuance protocol may separately involve user interaction if the client needs to be newly validated. <del> The use of interactive tokens can add user-perceivable latency, since such tokens cannot be pre-fetched.  Origins need not block useful work on token authentication.  Instead, token authentication can be used in similar ways to CAPTCHA validation today, but without the need for user interaction.  If issuance is taking a long time, a website could show an indicator that it is waiting, or fall back to another method of user validation. An origin MUST NOT issue more than one interactive challenge for a </del>  given token type and issuer per client request.  If an origin issues <del> a large number of challenges, such as more than once for each request, this can indicate that the origin is either not functioning correctly or is trying to attack or overload the client or issuance server.  In such cases, a client MUST ignore redundant token challenges for the same request and SHOULD alert the user if possible. </del>  Origins MAY include multiple challenges, where each challenge refers to a different issuer or a different token type, to allow clients to 5. The security properties of token challenges vary depending on whether <del> the challenge is interactive or not, as well as whether the challenge is per-origin or not.  For example, non-interactive, cross-origin tokens can be replayed from one party by another, as shown below. </del>  <del> Interactive token challenges require clients to obtain matching </del>  tokens when challenged, rather than presenting a token that was <del> obtained in the past.  This means that issuance and redemption events will occur at approximately the same time.  For example, if a client is challenged for an interactive token at time T1 and then subsequently obtains a token at time T2, a colluding issuer and origin can link this to the same client if T2 is unique to the client.  This linkability is less feasible as the number of issuance events at time T2 increases.  Depending on the "max-age" token challenge attribute, clients MAY try to augment the time between getting challenged then redeeming a token so as to make this sort of linkability more difficult.  For more discussion on correlation risks between token issuance and redemption, see I-D.ietf-privacypass- architecture. </del>  Applications SHOULD constrain tokens to a single origin unless the use case can accommodate such replay attacks.

We should consider renaming to . This value doesn't need to be a nonce, it's just some origin-selected context that it is binding to. We can also rename the in the Token struct to to make it clear what role it has.

issuance protocol to actually fetch tokens to redeem. In addition to working with different token issuance protocols, this  <ins> scheme supports optionally associating tokens with origin-chosen contexts and specific origin names.  Relying parties that request and redeem tokens can choose a specific kind of token, as appropriate for its use case.  These options allow for different deployment models to prevent double-spending, and allow for both interactive (online challenges) and non-interactive (pre-fetched) tokens. </ins> 1.1. Unless otherwise specified, this document encodes protocol messages in TLS notation from TLS13, Section 3.  <ins> This document uses the terms "Client", "Origin", "Issuer", "Issuance Protocol", and "Token" as defined in I-D.ietf-privacypass- 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. Token challenge: A requirement for tokens sent from an origin to a  <ins> client, using the "WWW-Authenticate" HTTP header.  This challenge is bound to a specific token issuer and issuance protocol, and may be additionally bound to a specific context or origin name. </ins> Token redemption: An action by which a client presents a token to an origin, using the "Authorization" HTTP header. is a hostname that is used to identify the issuer that is allowed to issue tokens that can be redeemed by this origin.  <ins> "redemption_context" is an optional field.  If present, it allows the origin to require that clients fetch tokens bound to a specific context, as opposed to reusing tokens that were fetched for other contexts.  When present, this value is a 32-byte context 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 either 0 or 32 bytes.  Challenges with redemption_context values of invalid lengths MUST be ignored. </ins> "origin_name" is an optional string containing the name of the origin.  This allows a token to be scoped to a specific origin. "nonce" is a 32-octet message containing a client-generated random nonce.  <ins> "challenge_digest" is a 32-octet message containing the hash of the original TokenChallenge, SHA256(TokenChallenge). </ins> "token_key_id" is an Nid-octet identifier for the the token authentication key.  The value of this field is defined by the For token types that support public verifiability, origins verify the token authenticator using the public key of the issuer, and validate that the signed message matches the concatenation of the client nonce  <ins> and the hash of a valid TokenChallenge.  For context-bound tokens, origins store or reconstruct the contexts of previous TokenChallenge structures in order to validate the token.  A TokenChallenge MAY be bound to a specific HTTP session with client, but origins can also accept tokens for valid challenges in new sessions.  Origins SHOULD implement some form of double-spend prevention that prevents a token with the same nonce from being redeemed twice.  This prevents clients from "replaying" tokens for previous challenges.  For context-bound tokens, this double-spend prevention can require no state or minimal state, since the context can be used to verify token uniqueness. </ins> If a client is unable to fetch a token, it MUST react to the challenge as if it could not produce a valid Authorization response. Note that the issuance protocol may separately involve user interaction if the client needs to be newly validated.  <ins> If a client cannot use cached tokens to respond to a challenge (either because it has run out of cached tokens or the associated context is unique), the token issuance process can add user- perceivable latency.  Origins need not block useful work on token authentication.  Instead, token authentication can be used in similar ways to CAPTCHA validation today, but without the need for user interaction.  If issuance is taking a long time, a website could show an indicator that it is waiting, or fall back to another method of user validation. An origin MUST NOT use more than one redemption context value for a </ins> given token type and issuer per client request.  If an origin issues  <ins> a large number of challenges with unique contexts, such as more than once for each request, this can indicate that the origin is either not functioning correctly or is trying to attack or overload the client or issuance server.  In such cases, a client MUST ignore redundant token challenges for the same request and SHOULD alert the user if possible. </ins> Origins MAY include multiple challenges, where each challenge refers to a different issuer or a different token type, to allow clients to 5. The security properties of token challenges vary depending on whether  <ins> the challenge contains a redemption context or not, as well as whether the challenge is per-origin or not.  For example, cross- origin tokens with empty contexts can be replayed from one party by another, as shown below. </ins>  <ins> Context-bound token challenges require clients to obtain matching </ins> tokens when challenged, rather than presenting a token that was  <ins> obtained in the past.  This can make it more likely that issuance and redemption events will occur at approximately the same time.  For example, if a client is challenged for a token with a unique context at time T1 and then subsequently obtains a token at time T2, a colluding issuer and origin can link this to the same client if T2 is unique to the client.  This linkability is less feasible as the number of issuance events at time T2 increases.  Depending on the "max-age" token challenge attribute, clients MAY try to augment the time between getting challenged then redeeming a token so as to make this sort of linkability more difficult.  For more discussion on correlation risks between token issuance and redemption, see I- D.ietf-privacypass-architecture. </ins> Applications SHOULD constrain tokens to a single origin unless the use case can accommodate such replay attacks.


"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:

For anyone unfamiliar with TLS struct notation, spell out the length fields in the 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:


2.1. <del> Origins send a token challenge to Clients in an "WWW-Authenticate" </del>  header with the "PrivateToken" scheme.  This challenge includes a TokenChallenge message, along with information about what keys to use when requesting a token from the issuer. single octet indicating the length.  Challenges with redemption_context values of invalid lengths MUST be ignored. <del> "origin_name" is an optional string containing the name of the 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. </del>  When used in an authentication challenge, the "PrivateToken" scheme uses the following attributes: band mechanism. "max-age", an optional attribute that consists of the number of <del> seconds for which the challenge will be accepted by the Origin. </del>  Clients can ignore the challenge if the token-key is invalid or otherwise untrusted. <del> Origins MAY also include the standard "realm" attribute, if desired. Issuance protocols MAY require other attributes. </del>  As an example, the WWW-Authenticate header could look like this: Upon receipt of this challenge, a client uses the message and keys in the issuance protocol indicated by the token_type.  If the TokenChallenge has a token_type the client does not recognize or <del> support, it MUST NOT parse or respond to the challenge. </del>  Note that it is possible for the WWW-Authenticate header to include <del> multiple challenges, in order to allow the Client to fetch a batch of </del>  multiple tokens for future use. For example, the WWW-Authenticate header could look like this: <del> If a Client fetches a batch of multiple tokens for future use that </del>  are bound to a specific redemption context (the redemption_context in <del> the TokenChallenge was not empty), Clients SHOULD discard these </del>  tokens upon flushing state such as HTTP cookies COOKIES, or changing networks.  Using these tokens in a context that otherwise would not <del> be linkable to the original context could allow the Origin to recognize a Client. </del>  2.1.1. unsupported parameters to "PrivateToken" authentication credentials MUST be ignored. <del> Clients present this Token structure to Origins in a new HTTP request </del>  using the Authorization header as follows: For token types that support public verifiability, origins verify the origin tokens with empty contexts can be replayed from one party by another, as shown below.  Context-bound token challenges require clients to obtain matching tokens when challenged, rather than presenting a token that was obtained from a different context in the past.  This can make it more As discussed in challenge, clients SHOULD discard any context-bound tokens upon flushing cookies or changing networks, to prevent an <del> Origin using the redemption context state as a cookie to recognize </del>  clients. Applications SHOULD constrain tokens to a single origin unless the

NAME please have a look!
From Ted Hardie in Vienna.
We should also clarify more explicitly how the client uses the origin name field for validating the context it is in.
Leaning towards allowing the being able to be a list of hostnames, with comma separation.
+1 to csv. We think this keeps the client impl's simple while allowing for the added flexibility of origin sets.
Might also have to say something about ignoring whitespace vs and then maybe just whitespace is the separator?
While I can understand the appeal, I'm not yet convinced we should do this until we have a use case and have thought through the possible privacy impacts.
perfect!

2.1.  <ins> Origins send a token challenge to clients in an "WWW-Authenticate" </ins> header with the "PrivateToken" scheme.  This challenge includes a TokenChallenge message, along with information about what keys to use when requesting a token from the issuer. single octet indicating the length.  Challenges with redemption_context values of invalid lengths MUST be ignored.  <ins> "origin_info" is an optional string containing one or more origin names, which allows a token to be scoped to a specific set of origins.  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.  If the string contains multiple origin names, they are delimited with commas "," without any whitespace. </ins> When used in an authentication challenge, the "PrivateToken" scheme uses the following attributes: band mechanism. "max-age", an optional attribute that consists of the number of  <ins> seconds for which the challenge will be accepted by the origin. </ins> Clients can ignore the challenge if the token-key is invalid or otherwise untrusted.  <ins> The header MAY also include the standard "realm" attribute, if desired.  Issuance protocols MAY require other attributes. </ins> As an example, the WWW-Authenticate header could look like this: Upon receipt of this challenge, a client uses the message and keys in the issuance protocol indicated by the token_type.  If the TokenChallenge has a token_type the client does not recognize or  <ins> support, it MUST NOT parse or respond to the challenge.  If the TokenChallenge contains a non-empty origin_info field, the client MUST validate that the name of the origin that issued the authentication challenge is included in the list of origin names. Clients MAY have further restrictions and requirements around validating when a challenge is considered acceptable or valid.  For example, clients can choose to reject challenges that list origin names for which current connection is not authoritative (according to the TLS certificate). </ins> Note that it is possible for the WWW-Authenticate header to include  <ins> multiple challenges, in order to allow the client to fetch a batch of </ins> multiple tokens for future use. For example, the WWW-Authenticate header could look like this:  <ins> If a client fetches a batch of multiple tokens for future use that </ins> are bound to a specific redemption context (the redemption_context in  <ins> the TokenChallenge was not empty), clients SHOULD discard these </ins> tokens upon flushing state such as HTTP cookies COOKIES, or changing networks.  Using these tokens in a context that otherwise would not  <ins> be linkable to the original context could allow the origin to recognize a client. </ins> 2.1.1. unsupported parameters to "PrivateToken" authentication credentials MUST be ignored.  <ins> Clients present this Token structure to origins in a new HTTP request </ins> using the Authorization header as follows: For token types that support public verifiability, origins verify the origin tokens with empty contexts can be replayed from one party by another, as shown below. <ins> Token challenges that include non-empty origin_info bind tokens to one or more specific origins.  As described in challenge, clients only accept such challenges from origin names listed in the origin_info string.  Even if multiple origins are listed, a token can only be redeemed for an origin if the challenge has an exact match for the origin_info.  For example, if "a.example.com" issues a challenge with an origin_info string of "a.example.com,b.example.com", a client could redeem a token fetched for this challenge if and only if "b.example.com" also included an origin_info string of "a.example.com,b.example.com".  On the other hand, if "b.example.com" had an origin_info string of "b.example.com" or "b.example.com,a.example.com" or "a.example.com,b.example.com,c.example.com", the string would not match and the client would need to use a different token. </ins> Context-bound token challenges require clients to obtain matching tokens when challenged, rather than presenting a token that was obtained from a different context in the past.  This can make it more As discussed in challenge, clients SHOULD discard any context-bound tokens upon flushing cookies or changing networks, to prevent an  <ins> origin using the redemption context state as a cookie to recognize </ins> clients. Applications SHOULD constrain tokens to a single origin unless the


this might be provided by the redemption protocol in HTTP- Authentication. <del> Both Client and Issuer also share a common public string called "info". </del> Given this configuration and these inputs, the two messages exchanged in this protocol are described below.  This section uses notation described in OPRF, Section 4, including SerializeElement and The Client first creates a context as follows: Here, 0x0004 is the two-octet identifier corresponding to the <del> OPRF(P-384, SHA-384) ciphersuite in OPRF.  SetupPOPRFClient is </del>  defined in OPRF, Section 3.2. The Client then creates an issuance request message for a random value "nonce" using the input challenge and Issuer key identifier as follows: <del> The Blind function is defined in OPRF, Section 3.3.3.  If the Blind </del>  function fails, the Client aborts the protocol.  Otherwise, the Client then creates a TokenRequest structured as follows: "token_key_id" is the least significant byte of the "key_id". <del> "blinded_request" is the Ne-octet blinded message defined above, computed as "SerializeElement(blinded_msg)".  Ne is as defined in OPRF, Section 4. </del>  <del> The value "tweaked_key" is stored locally and used later as described in finalization.  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 "message/token-request".  An example request is shown below. </del>  Upon receipt of the request, the Issuer validates the following conditions: The TokenRequest.token_key_id corresponds to a key ID of a Public Key owned by the issuer. <del> The TokenRequest.blinded_msg is of the correct size. </del>  If any of these conditions is not met, the Issuer MUST return an HTTP <del> 400 error to the Client, which will forward the error to the client. </del>  5.2. <del> If the Issuer is willing to produce a token token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows: </del>  <del> SetupPOPRFServer is in OPRF, Section 3.2 and Evaluate is defined in OPRF, Section 3.3.3.  The Issuer then creates a TokenResponse </del>  structured as follows: The structure fields are defined as follows: <del> "evaluate_response" is the Ne-octet evaluated messaged, computed as "SerializeElement(evaluated_msg)". </del>  "evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a pair of Scalar values, computed as Upon receipt, the Client handles the response and, if successful, deserializes the body values TokenResponse.evaluate_response and <del> TokenResponse.evaluate_proof.  If deserialization of any value fails, the Client aborts the protocol.  Otherwise, when deserialization yields "evaluated_msg" and "proof", the Client processes the response as follows: </del>  <del> The Finalize function is defined in OPRF, Section 3.3.3.  If this </del>  succeeds, the Client then constructs a Token as follows: Otherwise, the Client aborts the protocol.

Since metadata can be bound to tokens via TokenChallenge.redemptioncontext, and the origin is ultimately the one who determines what metadata is supported, there's no more real need for the issuer_ to supply this metadata. So let's go with the simpler VOPRF protocol instead! Test vectors generated from the code here: URL cc NAME NAME NAME
LGTM

this might be provided by the redemption protocol in HTTP- Authentication.  Given this configuration and these inputs, the two messages exchanged in this protocol are described below.  This section uses notation described in OPRF, Section 4, including SerializeElement and The Client first creates a context as follows: Here, 0x0004 is the two-octet identifier corresponding to the  <ins> OPRF(P-384, SHA-384) ciphersuite in OPRF.  SetupVOPRFClient is </ins> defined in OPRF, Section 3.2. The Client then creates an issuance request message for a random value "nonce" using the input challenge and Issuer key identifier as follows:  <ins> The Blind function is defined in OPRF, Section 3.3.2.  If the Blind </ins> function fails, the Client aborts the protocol.  Otherwise, the Client then creates a TokenRequest structured as follows: "token_key_id" is the least significant byte of the "key_id".  <ins> "blinded_msg" is the Ne-octet blinded message defined above, computed as "SerializeElement(blinded_element)".  Ne is as defined in OPRF, Section 4. </ins>  <ins> The values "token_input" and "blinded_element" are stored locally and used later as described in finalization.  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 "message/token- request".  An example request is shown below. </ins> Upon receipt of the request, the Issuer validates the following conditions: The TokenRequest.token_key_id corresponds to a key ID of a Public Key owned by the issuer.  <ins> The TokenRequest.blinded_request is of the correct size. </ins> If any of these conditions is not met, the Issuer MUST return an HTTP  <ins> 400 error to the client. </ins> 5.2.  <ins> Upon receipt of a TokenRequest, the Issuer tries to deseralize TokenRequest.blinded_msg using DeserializeElement from Section 2.1 of OPRF, yielding "blinded_element".  If this fails, the Issuer MUST return an HTTP 400 error to the client.  Otherwise, if the Issuer is willing to produce a token token to the Client, the Issuer completes the issuance flow by computing a blinded response as follows: </ins>  <ins> SetupVOPRFServer is in OPRF, Section 3.2 and Evaluate is defined in OPRF, Section 3.3.2.  The Issuer then creates a TokenResponse </ins> structured as follows: The structure fields are defined as follows:  <ins> "evaluate_msg" is the Ne-octet evaluated messaged, computed as "SerializeElement(evaluate_element)". </ins> "evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a pair of Scalar values, computed as Upon receipt, the Client handles the response and, if successful, deserializes the body values TokenResponse.evaluate_response and  <ins> TokenResponse.evaluate_proof, yielding "evaluated_element" and "proof".  If deserialization of either value fails, the Client aborts the protocol.  Otherwise, the Client processes the response as follows: </ins>  <ins> The Finalize function is defined in OPRF, Section 3.3.2.  If this </ins> succeeds, the Client then constructs a Token as follows: Otherwise, the Client aborts the protocol.


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.

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 .

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.


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>  7.

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 ...

Issuers are configured with Private and Public Key pairs, each denoted skI and pkI, respectively, used to produce tokens.  Each key  <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.


"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>  "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>  "blinded_msg" is the Nk-octet request defined above.

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?

"token_type" is a 2-octet integer, which matches the type in the challenge.  <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.  <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.


Reference: Where this algorithm is defined  The initial contents for this registry are defined in the table below.

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.

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.


3. <del> Issuers MUST provide one parameter for configuration: </del>  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".  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>  <del> As an example, the Issuer's JSON directory could look like: </del>  Issuer directory resources have the media type "application/json" and are located at the well-known location /.well-known/token-issuer-

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.

3.  <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  <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>  <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-


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>  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>  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>  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,

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.

privacy impacts of the protocol, why these impacts are justified, and guidelines on changes to the parametrization in parametrization.  <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  <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  <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,


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>  Concurrent security.  The issuance protocol MUST be safe to run concurrently with arbitrarily many Clients.

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.

One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens  <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.


Each Issuance protocol MUST come with a detailed analysis of the privacy impacts of the protocol, why these impacts are justified, and <del> guidelines on changes to the parametrization in parametrization. </del>  Clients obtain the Issuer public key directly from the Origin using the process described in HTTP-Authentication.  Clients MAY apply some expiration information as metadata alongside the token; See metadata for more discussion about metadata constraints.  Both techniques are equivalent since they cryptographically bind expiration to individual <del> tokens. Key rotations should be limited in frequency for similar reasons. See parametrization for guidelines on what frequency of key rotations are permitted. </del>  3.2.3. unique issuer public key for each value of metadata, such that N keys yields log2(N) bits of metadata.  The total amount of metadata bits included in a token is the sum of public and private metadata bits. <del> See parametrization for discussion about metadata limits. </del> Public metadata is that which clients can observe as part of the token issuance flow.  Public metadata can either be transparent or functionalities through new issuance protocols.  Each issuance protocol SHOULD come with a detailed analysis of the privacy impacts of the extension, why these impacts are justified, and guidelines on <del> changes to the parametrization in parametrization.  Any extension to the Privacy Pass protocol MUST adhere to the guidelines specified in issuer-role for managing Issuer public key data. </del>  4. of information that Issuer's may learn about Clients otherwise. Since this metadata may be useful for practical deployments of Privacy Pass, Issuers must balance this against the reduction in <del> Client privacy.  In general, Issuers should permit no more than 32 bits of metadata, as this can uniquely identify each possible user. We discuss this more in parametrization. </del>  5.2. time, a strict bound SHOULD be applied to the active number of Issuers in the ecosystem.  We propose that allowing no more than 4 Issuers at any one time is highly preferable (leading to a maximum of <del> 64 possible user segregations).  However, as highlighted in parametrization, having a very large user base (> 5 million users), could potentially allow for larger values.  Issuer replacements </del>  should only occur with the same frequency as config rotations as they can lead to similar losses in anonymity if clients still hold redemption tokens for previously active Issuers. Origin requests an excess of tokens, the Client could choose to not present any tokens for verification if a redemption had already occurred in a given time window. <del> 7. This section provides a summary of the parameters used in the Privacy Pass protocol ecosystem.  These parameters are informed by both privacy and security considerations that are highlighted in privacy and security, respectively.  These parameters are intended as a single reference point for those implementing the protocol. Firstly, let U be the total number of Clients (or users), I be the total number of Issuers.  We let M be the total number of metadata bits that are allowed to be added by any given Issuer.  Assuming that each user accept tokens from a uniform sampling of all the possible Issuers, as a worst-case analysis, this segregates Clients into a total of 2^I buckets.  As such, we see an exponential reduction in the size of the anonymity set for any given user.  This allows us to specify the privacy constraints of the protocol below, relative to the setting of A. 7.1. We make the following assumptions in these parameter choices. Inferring the identity of a user in a 5000-strong anonymity set is difficult. After 2 weeks, all Clients in a system will have rotated to the new key. In terms of additional metadata, the only concrete applications of Privacy Pass that use additional metadata require just a single bit. Therefore, we set the ceiling of permitted metadata to 1 bit for now, this may be revisited in future revisions. The maximum choice of I is based on the equation 1/2 * U/2^(2I) = A. This is derived from the fact that permitting I Issuers lead to 2^I segregations of the total user-base U.  Moreover, if we permit M = 1, then this effectively halves the anonymity set for each Issuer, and thus we incur a factor of 2I in the exponent.  By reducing I, we limit the possibility of performing the attacks mentioned in privacy. We must also account for each user holding issued data for more then one possible active keys.  While this may also be a vector for monitoring the access patterns of Clients, it is likely to unavoidable that Clients hold valid issuance data for the previous key epoch.  This also means that the Issuer can continue to verify redemption data for a previously used key.  This makes the rotation period much smoother for Clients. For privacy reasons, it is recommended that key epochs are chosen that limit Clients to holding issuance data for a maximum of two keys.  By choosing F = L/2 then the minimum value of F is a week, since the minimum recommended value of L is 2 weeks.  Therefore, by the initial assumption, then all users should only have access to only two keys at any given time.  This reduces the anonymity set by another half at most. Finally, the minimum security parameter size is related to the cryptographic security offered by the protocol that is run.  This parameter corresponds to the number of operations that any adversary has in breaking one of the security guarantees in the Privacy Pass protocol I-D.ietf-privacypass-protocol. 7.2. Using the specification above, we can give some example parameterizations.  For example, the current Privacy Pass browser extension PPEXT has nearly 300000 active users (from Chrome and Firefox).  As a result, log_2(U/A) is approximately 6 and so the maximum value of I should be 3. If the value of U is much bigger (e.g. 5 million) then this would permit I = (log_2(5000000/5000)-1)/2 ~= 4 Issuers. 7.3. Using the recommendations in more-servers, it is possible to tolerate larger number of Issuers if Clients in the ecosystem ensure that they only store tokens for a small number of them.  In particular, if Clients limit their storage of redemption tokens to the bound implied by I, then prevents a malicious verifier from triggering redemptions for all Issuers in the ecosystem. </del>

After quickly skimming the parameterization section, it became clear that we already discuss these things in various consideration sections throughout the document, so this was just redundant. Moreover, it's very use-case and deployment specific that once had value in the joint deployment model, so it doesn't seem like particularly helpful now that we've generalized things a bit. Removing and avoiding confusion seems like the best path forward.
I'll take this one to the list before merging.
The privacy calculations should be updated to take into account metadata more explicitly, and take into account the cost of the number of redemptions, rather than the global issuer count. If used in a multiple disjoint architecture ecosystem, then the math should also be taken in terms of a specific 'context' rather than treating the whole PrivacyPass ecosystem as a single global system (allowing for more nuanced requirements/limitations on issuer counts).
On reflection, we may be better off deleting the text entirely and making sure the justification for the parameterization is adequately covered in the security and privacy considerations elsewhere in the document.

Each Issuance protocol MUST come with a detailed analysis of the privacy impacts of the protocol, why these impacts are justified, and  <ins> guidelines on how to deploy the protocol to minimize any privacy impacts. </ins> Clients obtain the Issuer public key directly from the Origin using the process described in HTTP-Authentication.  Clients MAY apply some expiration information as metadata alongside the token; See metadata for more discussion about metadata constraints.  Both techniques are equivalent since they cryptographically bind expiration to individual  <ins> tokens.  Key rotations should be limited in frequency for similar reasons. </ins> 3.2.3. unique issuer public key for each value of metadata, such that N keys yields log2(N) bits of metadata.  The total amount of metadata bits included in a token is the sum of public and private metadata bits.  Public metadata is that which clients can observe as part of the token issuance flow.  Public metadata can either be transparent or functionalities through new issuance protocols.  Each issuance protocol SHOULD come with a detailed analysis of the privacy impacts of the extension, why these impacts are justified, and guidelines on  <ins> how to deploy the protocol to minimize any privacy impacts.  Any extension to the Privacy Pass protocol MUST adhere to the guidelines specified in issuer-role for managing Issuer public key data. </ins> 4. of information that Issuer's may learn about Clients otherwise. Since this metadata may be useful for practical deployments of Privacy Pass, Issuers must balance this against the reduction in  <ins> Client privacy.  In general, Issuers should bound the metadata permitted so as to not allow it to uniquely identify each possible user. </ins> 5.2. time, a strict bound SHOULD be applied to the active number of Issuers in the ecosystem.  We propose that allowing no more than 4 Issuers at any one time is highly preferable (leading to a maximum of  <ins> 64 possible user segregations).  However, having a very large user base could potentially allow for larger values.  Issuer replacements </ins> should only occur with the same frequency as config rotations as they can lead to similar losses in anonymity if clients still hold redemption tokens for previously active Issuers. Origin requests an excess of tokens, the Client could choose to not present any tokens for verification if a redemption had already occurred in a given time window.


to a different issuer or a different token type, to allow clients to choose a preferred issuer or type.  4. The security properties of token challenges vary depending on whether

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.

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


past day.  Attesters should not admit attestation types that result in small anonymity sets.  3.2.2. Issuers MUST be uniquely identifiable by all Clients with a

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.

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


Issuers maintain an issuance key pair for the issuance protocol.  The Issuer public key is made available to all Clients in such a way that <del> key rotations and other updates are publicly visible.  The key material and protocol configuration that an Issuer uses to produce tokens corresponds to two different pieces of information. </del>  The issuance protocol in use; and As above, specific mechanisms for key management and discovery are out of scope for this document. <del> 3.2.2.2. Token issuance associates all issued tokens with a particular choice of key.  If an Issuer issues tokens with many keys, then this may harm the anonymity of the Client.  For example, they would be able to map the Client's access patterns by inspecting which key each token they possess has been issued under. To prevent against this, Issuers MUST only use one private key for issuing tokens at any given time.  Servers MAY use one or more keys for redemption to allow Issuers for seamless key rotation. Servers may rotate keys as a means of revoking tokens issued under old or otherwise expired keys.  Alternatively, Issuers may include expiration information as metadata alongside the token; See metadata for more discussion about metadata constraints.  Both techniques are equivalent since they cryptographically bind expiration to individual tokens.  Key rotations should be limited in frequency for similar reasons. </del> 3.2.3. Certain instantiations of the issuance protocol may permit public or 5.2. Issuer key rotation is important to hedge against long-term private <del> key compromise.  However, key rotation can also be used to segment Client anonymity sets.  In particular, when an Issuer rotates their key, any Client that invokes the issuance protocol in this key cycle will be part of a group of possible Clients owning valid tokens for this key.  To mechanize this attack strategy, an Issuer could introduce a key rotation policy that forces Clients into small key cycles, reducing the size of the anonymity set for these Clients. </del>  In general, key rotations represent a trade-off between Client <del> privacy and continued Issuer security.  Therefore, it is still important that key rotations occur on a regular cycle to reduce the harmfulness of an Issuer key compromise. With a large number of Clients, a minimum of one week gives a large enough window for Clients to participate in the issuance protocol and thus enjoy the anonymity guarantees of being part of a larger group. A maximum of 12 weeks limits the damage caused by a key compromise. If an Issuer realizes that a key compromise has occurred then the Issuer should generate a new key and make it available to Clients. If possible, it should invoke any revocation procedures that may apply for the old key. </del>  5.3.

cc NAME
S3.2.2.2 states "Issuers MUST only use one private key for issuing tokens at any given time." The next section (3.2.3), however, suggests that multiple keys could be used to encode metadata, and indeed, I believe the latest draft of rate-limited tokens uses different issuance keys. These seem to be in conflict.

Issuers maintain an issuance key pair for the issuance protocol.  The Issuer public key is made available to all Clients in such a way that  <ins> key rotations and other updates are publicly visible.  See key- rotation-privacy for more considerations around Issuer key rotation. The key material and protocol configuration that an Issuer uses to produce tokens corresponds to two different pieces of information. </ins> The issuance protocol in use; and As above, specific mechanisms for key management and discovery are out of scope for this document.  3.2.3. Certain instantiations of the issuance protocol may permit public or 5.2. Issuer key rotation is important to hedge against long-term private  <ins> key compromise.  If an Issuer realizes that a key compromise has occurred then the Issuer should generate a new key and make it available to Clients.  If possible, it should invoke any revocation procedures that may apply for the old key. Key rotation can also be used to segment Client anonymity sets.  In particular, when an Issuer rotates their key, any Client that invokes the issuance protocol in this key cycle will be part of a group of possible Clients owning valid tokens for this key.  To mechanize this attack strategy, an Issuer could introduce a key rotation policy that forces Clients into small key cycles, reducing the size of the anonymity set for these Clients. </ins> In general, key rotations represent a trade-off between Client  <ins> privacy and Issuer security.  Therefore, it is still important that key rotations occur on a regular cycle to reduce the harmfulness of an Issuer key compromise.  If there are multiple Issuer keys in rotation, Clients can apply some form of consistency mechanism CONSISTENCY to ensure that they receive the same key as other Clients.  Likewise, Origins can use one or more public keys for redemption to support Issuer key rotation. </ins> 5.3.


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>  One-more forgery security.  The issuance protocol MUST NOT allow malicious Clients or Attesters (acting as Clients) to forge tokens

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.

Unconditional input secrecy.  The issuance protocol MUST NOT reveal anything about the Client's private input, including the  <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