Network Working Group S. Schlesinger Internet-Draft Google LLC Intended status: Informational 11 May 2026 Expires: 12 November 2026 MoLE Architecture draft-schlesinger-mole-architecture-latest Abstract TODO Abstract About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://Moderation- of-unLinkable-Endorsements.github.io/architecture-draft/draft- schlesinger-mole-architecture.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- schlesinger-mole-architecture/. Source for this draft and an issue tracker can be found at https://github.com/Moderation-of-unLinkable-Endorsements/ architecture-draft. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 2. Use Cases 2.1. Reduced-Friction Challenges 2.2. User Agents Acting Under Delegation 2.3. Private Access Control 3. Conventions and Definitions 4. Architecture overview 5. Privacy Properties 5.1. Goals 5.2. Threat Model 5.3. Anonymity Sets 5.4. State 5.5. Side Channels 6. Security Considerations 7. Privacy Considerations 8. IANA Considerations 9. References 9.1. Normative References 9.2. Informative References Acknowledgments Author's Address 1. Introduction Moderation of unLinkable Endorsements (MoLE) is an architecture in which Origins make authorization decisions from unlinkable, issuer- hiding credential presentations derived from scarce signals. Users often encounter friction when an Origin has little prior context about them: for example, when they arrive with no cookies, use a VPN, enable privacy-preserving browser settings, or delegate browsing to a software agent. In those cases, the Origin may present a CAPTCHA, use fingerprinting, reject the request, or return a degraded experience. These mechanisms add friction, collect more information about users, or both. They affect users with strong privacy preferences and users with accessibility needs. [INTERNET-END-USER] directs the IETF to consider the interests of end users; [PERVASIVE-MONITORING] treats pervasive monitoring as an attack. MoLE reduces this friction without requiring the user to reveal a stable identity to an Origin or disclose which scarce signals they can use. An Anchor issues credentials from scarce signals. A Moderator evaluates presentations of Anchor credentials under a policy and issues Moderator credentials. A Client presents a Moderator credential to an Origin with a request. The Anchor/Moderator split avoids binding an Origin's admission policy to one source of scarcity. A Moderator commits to a policy. An Origin chooses one or more Moderators. The Moderator can then add, remove, or restrict Anchors without requiring Origins or Clients to reconfigure. Issuer-hiding presentation makes this useful: the Origin learns that the underlying Anchor is in the Moderator's accepted set, but not which Anchor issued the credential. MoLE is inspired by the Privacy Pass architecture [RFC9576], but differs in three ways. First, Moderator issuance depends on an issuer-hiding presentation of an Anchor credential. Second, Anchor- credential presentation is intended to remain secure against future quantum adversaries. Third, Moderator credentials can carry policy state across presentations. These differences motivate a separate architecture. This document specifies MoLE roles, privacy and security requirements, and deployment considerations. Wire protocols and cryptographic instantiations are specified in companion documents. 2. Use Cases In each use case the Client acts on behalf of a user, as part of, or accessed by, a user agent [RFC9110]. The architecture distinguishes the trust the user places in the user agent from any further delegation the user agent may itself perform, and does not prejudge the latter. No use case below by itself motivates the full architecture: simpler designs cover each in isolation. The case for the architecture rests on the openness argument in the Introduction together with the union of these cases, and is most strongly load-bearing for the second. 2.1. Reduced-Friction Challenges A user visits an Origin for the first time, with no cookies, possibly through a VPN or shared NAT that obscures the network-layer identifier. The Origin has no per-user history and limited reputational signal from the network path. The user is the party who bears the cost of whatever the Origin then chooses --- repeated CAPTCHAs, silent rejection, or a degraded experience --- with disproportionate cost to users on privacy-preserving network paths and to users with accessibility needs. In this use case, the Client presents a Moderator credential whose underlying Anchor credential attests to a scarce property accepted under the Moderator's policy. The Origin combines this signal with its existing inputs to decide whether to admit, challenge, or reject the request. A Moderator credential is one input among several; it does not entitle the Client to admission. Two consequences shape the design. First, the Client presents a Moderator credential to the Origin in a single request/response exchange; acquisition of Anchor and Moderator credentials happens off this path. Second, the design must admit user agents partially or wholly automated on behalf of the user; see Section 2.2. 2.2. User Agents Acting Under Delegation A user delegates some of their interaction with an Origin to an automated agent running in, or alongside, their browser. Such an agent is a user agent: it acts under delegation from a user who could otherwise have driven the browser themselves. Origins that lack a richer signal commonly treat the appearance of automation as grounds for friction or denial of service. This blocks delegated browsing as a side effect of resisting unwanted automation. In this use case, the user agent presents a Moderator credential on the user's behalf. The Origin admits the request based on the user's standing without the user agent surfacing a stable identity or correlatable state. From the credential alone, the Moderator and the Origin cannot distinguish presentations driven by the agent from presentations driven by the user directly. Distinguishability via request content, timing, or rate is the responsibility of the user agent and is not addressed by the credential. When delegated agent behaviour violates a Moderator's policy, the Moderator may update state bound to the user's Moderator credential. This is a deliberate design choice: the user bears the policy consequence of how they have chosen to delegate, but does so via a credential unlinkable to the Origin, not via per-user reputation visible to it. The scope of that state, and the requirement that Moderator state updates not leak information equivalent to per-user state queries, are addressed in Section 5. This use case is in tension with Section 2.1: the same surface that admits a low-friction first visit can also admit unwanted automation. The architecture locates the trust decision at the Anchor (over scarce signals about the user or device) and at the Moderator (over policy), not at the appearance of automation in any single request. User agents not acting under delegation from a user --- for example, autonomous crawlers and non-browser automation --- are not explicitly dealt with by this document, though the architecture can likely apply in many such cases as well. Whether such an agent obtains an Anchor credential is determined by Anchor policy, and whether a Moderator continues to admit them when detectable is determined by Moderator policy. The line between user-driven and autonomous agents is therefore drawn by Anchors and Moderators. 2.3. Private Access Control A user visits an Origin repeatedly, without persistent cookies, expecting that successive visits are not linkable to one another. The Origin gates some functionality on a non-public criterion such as a paid subscription, group membership, or a per-period quota of allowed operations. In this use case, the Anchor's attestation conveys eligibility under such a criterion, and the Moderator translates that eligibility into a credential under a policy that may include rate or quota state. Against the Origin alone, successive presentations are unlinkable to each other and to issuance. The Moderator necessarily observes issuance; cross-presentation linkage at the Moderator is bounded to the granularity of the rate or quota state the credential carries, with details in Section 5. This use case is a secondary goal: it does not by itself motivate the state-bearing Moderator credential, but the architecture admits it and the authors recommend it's usage for deployments which require this feature. More elaborate authorization policies, including rich attribute-based access control and multi-factor eligibility combinations, are out of scope of this architecture document but may be included in companion documents. 3. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms are used throughout this document: *Client:* An entity that seeks authorization to an Origin. *Origin:* An entity that consumes presentations from Clients and uses them to make authorization decisions. *Moderator:* An entity that consumes presentations from Clients and issues credentials according to a policy. *Anchor:* An entity that issues credentials to Clients based on scarce signals. *Credential:* A cryptographic object issued by an Anchor or Moderator to a Client. *Presentation:* The mechanism by which Clients prove possession of a credential satisfying specified attributes. *Policy:* Rules used by a Moderator or Origin to evaluate presentations. 4. Architecture overview The Client obtains a credential from an Anchor, presents it to a Moderator, and uses the resulting Moderator credential when sending requests to an Origin. TODO: should tghis be three diagarms so we can detail things better? Should it be like reverse flow privacy pass and then map roles (anchor, moderator) onto flows? +--------+ +--------+ +-----------+ +--------+ | Client | | Anchor | | Moderator | | Origin | +---+----+ +---+----+ +-----+-----+ +---+----+ | | | | +-- CredentialRequest->| | | |<-CredentialResponse--+ | | CredentialFinalization | | | | | | | CredentialPresentation | | | +----------- CredentialPresentation ----------->| | |<----------- CredentialResponse ---------------+ | CredentialFinalization | | | | | | | CredentialPresentation | | | +----------------- Request+CredentialPresentation --------------------->| | | |<-- ValidateRequest ---+ | | +-- ValidationResult -->| |<---------------- Response+CredentialResponse -------------------------+ CredentialFinalization | | | | | | | Figure 1: MoLE Architecture 5. Privacy Properties This section states the privacy goals for MoLE constructions. The wire protocol and cryptographic instantiation are specified in companion documents. 5.1. Goals MoLE constructions provide three privacy properties. 1. _Moderator-credential unlinkability._ An Origin cannot link two valid Moderator-credential presentations to the same Client from the presentation alone. 2. _Issuer-hiding._ A Moderator-credential presentation reveals that the underlying Anchor is in the Moderator's accepted Anchor set, but not which Anchor issued the Anchor credential. 3. _Anchor-credential post-issuance unlinkability._ A Moderator cannot link an Anchor-credential presentation to its issuance transcript. Constructions are expected to preserve this property against adversaries that record issuance traffic and later gain access to quantum computation. A successful presentation tells the Origin that the Client holds a Moderator credential satisfying the Origin's policy. It does not reveal the Client's identity, the underlying Anchor, or a score assigned by the Moderator. 5.2. Threat Model The properties above are cryptographic properties of the protocol transcript. They do not hide information available outside the transcript, such as network metadata, request contents, timing, or user-agent fingerprinting. Collusion changes the privacy properties. For example, an Origin and Moderator that share request timing, network metadata, and validation logs may be able to link presentations even when the credential presentation itself is unlinkable. Deployment sections describe which entities need to be separated for a given privacy claim. 5.3. Anonymity Sets The strength of these properties depends on anonymity-set size. For Moderator-credential unlinkability, the relevant set is the population of Clients holding credentials under the same Moderator policy. For issuer-hiding, the relevant set is the Moderator's accepted Anchor set. A Moderator with one accepted Anchor provides no issuer-hiding. Deployments should avoid policy choices, key rotations, or Anchor-set changes that partition Clients into small sets. 5.4. State Moderator credentials can carry policy state, such as quota or revocation state. State updates must not give an Origin or Moderator a stable handle that links future presentations by the same Client. The details are construction-specific. Companion documents need to specify what state is carried, who can update it, and what information is revealed by each update. 5.5. Side Channels MoLE does not address all channels that can identify Clients. Relevant channels include network metadata between Client and Anchor, Client and Moderator, and Client and Origin; presentation timing; request contents; accepted-set churn; policy changes; and key rotation. These channels need deployment-specific mitigations. For example, [OBLIVIOUS-HTTP] can hide network metadata between the Client and Anchor or Moderator. The Client-Origin channel is outside this architecture. 6. Security Considerations TODO Security 7. Privacy Considerations TODO Privacy Consideration section is more widespread than properties 8. IANA Considerations This document has no IANA actions. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [INTERNET-END-USER] Nottingham, M., "The Internet is for End Users", RFC 8890, DOI 10.17487/RFC8890, August 2020, . [OBLIVIOUS-HTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458, DOI 10.17487/RFC9458, January 2024, . [PERVASIVE-MONITORING] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9576] Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, June 2024, . Acknowledgments TODO acknowledge. Author's Address Samuel Schlesinger Google LLC Email: sgschlesinger@gmail.com