| Internet-Draft | MoLE Architecture | June 2026 |
| Schlesinger, et al. | Expires 25 December 2026 | [Page] |
TODO Abstract¶
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/internet-drafts/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/internet-drafts.¶
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 25 December 2026.¶
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.¶
Moderation of unLinkable Endorsements (MoLE) is an architecture in which Sites make authorization decisions from unlinkable, issuer-hiding credential presentations derived from scarce signals.¶
Users often encounter friction when a Site 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 Site 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 aims to reduce this friction, whilst maintaining the privacy of users, by enabling new information flows between Sites subject to cryptographically enforced limits.¶
Some Sites have access to relatively rich context about a user, e.g. because the user maintains an account, made a payment or provided some other scare signal to the Site. MoLE enables such Sites to act as Anchors which issue Endorsements to users, suitable for bootstrapping trust in other contexts.¶
MoLE enables multiple Sites to share an access policy through a Moderator. The Moderator holds a list of trusted Anchors, and can use the Anchor's Endorsements to issue Credentials to Users which are suitable for use on any of it's associated Sites. The Moderator can adjust their confidence in the credentials presented by a user over time. This allows the Moderator to reduce friction for honest users and increase friction for users which are judged to be misbehaving (e.g. spamming, credential stuffing, etc).¶
MoLE delivers this functionality whilst providing strong privacy protections for users. Sites and Moderators cannot learn which Anchors a user has access to, only that it holds at least one suitable Endorsement from the Moderator's trusted list (Anchor Blindness). Further, even if Sites, Moderators and Anchors all collude in an attempt to violate User privacy, the user's presentation of their credentials and endorsements cannot be linked across different contexts (Unlinkability).¶
MoLE is inspired by the Privacy Pass architecture [RFC9576], but differs in a number of aspects.¶
Firstly, MoLE provides greater utility to Sites by enabling Moderators to dynamically adjust access in response to how a credential is used. Privacy Pass enforces a flat rate limit based on access to an underlying credential which cannot be curtailed even if usage is obviously abusive. This leads to fundamentally different information flows, privacy analysis and cryptographic techniques.¶
Secondly, MoLE targets a deployment in an open ecosystem where multiple Anchors, Moderators and Sites coexist with different policies. This openness, necessary for deployment in contexts like the Web, requires stronger privacy properties than are delivered by Privacy Pass. For example, MoLE cannot rely on non-collusion assumptions between Issuer and Attester as is required in Privacy Pass's rate-limiting deployments and must instead ensure it's privacy properties are founded on suitable cryptographic assumptions.¶
This document specifies MoLE roles, privacy and security requirements, and deployment considerations. Wire protocols and cryptographic instantiations are specified in companion documents.¶
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.¶
A user visits a Site for the first time, with no cookies, possibly through a VPN or shared NAT that obscures the network-layer identifier. The Site 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 Site 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 Site 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 Site 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.¶
A user delegates some of their interaction with a Site 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. Sites 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 Site 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 Site 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 Site, 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.¶
A user visits a Site repeatedly, without persistent cookies, expecting that successive visits are not linkable to one another. The Site 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 Site 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.¶
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:¶
An entity that seeks access to resources held by a Site.¶
An entity that consumes presentations from Clients and uses them to make authorization decisions. The Site may operate software client-side, server-side, or both, depending on the deployment.¶
An entity that issues Endorsements to Clients based on scarce signals.¶
A cryptographic object issued by an Anchor to a Client.¶
An entity that consumes presentations from Clients and issues credentials according to a policy.¶
A cryptographic object issued by a Moderator to a Client. This credential has an associated integer state that is updated during presentation.¶
The mechanism by which Clients prove possession of a credential satisfying specified attributes.¶
Rules used by a Moderator or Site to evaluate presentations.¶
The MoLE architecture is constructed to orchestrate trust relationships and infomation flows between four entities: Client, Anchor, Moderator, and Site. These entities have a limited exchange of information that allows for dynamic rate-limiting, bootstrapped from exising knowledge, in an open ecosystem. This section details the information flows and trust relationships between these entities along with requirements for the underlying protocols and APIs.¶
A complete exchange for MoLE has three distinct flows: Endorsement, in which a Client obtains an endorsement signifying its relationship with an Anchor; Issuance, in which a Client uses an endorsement from an Anchor to obtain credentials from a Moderator without revealing which Anchor it was; and Presentation, in which a Client uses credentials from a Moderator of the Site's choosing to prove that it is presently in good standing with the Moderator and that this request matches the Moderator and Site's policies through an online interaction. Clients most often interact with the MoLE architecture either by being requested by a Site to present a credential or by an Anchor to initiate an Endorsement.¶
Beginning with Endorsement and proceeding to a Presentation, a typical overarching flow occurs as follows:¶
A Client interacts with an Anchor in such a way that the Client believes the Anchor may endorse them. This mechanism that advertises the Anchor's endorsement capability is deployment specific. It may be an HTTP header, a Javascript API call, or an HTML attribute. Fundamentally, the Anchor offers to grant an endorsement to the Client so that it may be used later.¶
A Client requests an endorsement from the Anchor. The Anchor responds to this request based upon its policy. Upon success, the Client finalizes its endorsement.¶
Some time later, the Client interacts with the Site.¶
The Site induces the Client to present a credential from a Moderator it (the Site) trusts. The precise mechanism is deployment specific. It may be an HTTP Header, a Javascript API call, or an HTML attribute. Fundamentally, the Site enforces that a given resource may only be obtained upon the Client providing a valid presentation. So it asks the Client to obtain a credential that will produce such a valid presentation.¶
If the Client already has a credential from the Moderator, it may skip to Step 9.¶
The Client requests a list of trusted Anchors from the Moderator.¶
If the Client is unwilling or unable to present a matching endorsement, the flow fails.¶
The Client obtains an endorsement from one of the trusted anchors and presents it along with a credential request to the Moderator. Upon validation of the endorsement presentation, the Moderator returns a credential response that the Client finalizes.¶
The Client provides a credential presentation to the Site. This may be used to prove that the credential's state is over some threshold, but does not reveal the exact value.¶
The Site issues a request to the Moderator to validate the presentation. This may be accompanied by any information the Site wishes to provide the Moderator as context for the request, such as the request itself, following the Site and Moderator's respective policy.¶
Given the context from the Site, the presentation, and its policy, the Moderator validates that the presentation proves a sufficiently large value in the credential's state and determines how to mutate that state. It returns the result to the Site. This response includes material for the Site such as a boolean, and material for the client so they can update their credential state.¶
The Site provides the Moderator's response to the Client, who uses it to produce a modified credential with an updated state.¶
If the validation response indicates to the Site that the Client's presentation does not satisfy the policy, the Site fails the request from Step 4. On success, the Site provides the Client with the material it received from the Moderator.¶
The Client updates its credential for the Moderator with the response forwarded by the Site. This will allow the Client to perform future requests.¶
Taking Figure 1, we can distinguish three flows.¶
Upon passing an attestation, a Client may request an Endorsement from an Anchor. An Endorsement is a cryptographic object that the client can later present to a Moderator that proves the Client has been attested by the Anchor.¶
When an Endorsement is presented to a Moderator, the Moderator learns whether or not the Endorsement originates from the set of Anchors it trusts. The presentation must not be reveal the Anchor the Client has been endorsed by, and must not be linkable to other presentations of made using that same Endorsement.¶
When a Moderator credential is presented to a Site, the Site learns whether or not it satisfies a Site specific policy. The presentation must not be linkable to past updates, or to the credential issuance.¶
Credential updates must demonstrate that they are applied to the same credential as was initially presented. This prevents attacks where an attacker with two credentials shows one, and applies updates only to the other.¶
Credential updates have to be applied before access to resources that an origin may gate or rate limit, so that Clients do not simply ignore the update request after getting them.¶
A Site challenge has to give Clients enough information to discover the Moderator and the policy context for the presentation. The Moderator then gives Clients enough information to discover the accepted Anchor material. The discovery method is deployment-specific. It can use URIs, lookup keys, or other opaque locators for out-of-band material that Clients are expected to resolve.¶
Deployments should make both pieces of discovery material consistent across Clients and resistant to split views. A deployment can use a [CONSISTENCY-MIRROR], [KEYTRANS], [SCITT], or another mechanism with similar properties.¶
This section states the privacy goals for MoLE constructions. The wire protocol and cryptographic instantiation are specified in companion documents.¶
MoLE constructions provide three privacy properties.¶
Moderator-credential unlinkability. A Site cannot link two valid Moderator-credential presentations to the same Client from the presentation alone.¶
Anchor-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.¶
Anchor-endorsement post-issuance unlinkability. A Moderator cannot link an Anchor-endorsement presentation to its issuance transcript. Constructions are expected to preserve this property against adversaries that record issuance traffic and later gain access to a cryptographically relevant quantum computation.¶
A successful presentation tells the Site that the Client holds a Moderator credential satisfying the Site's policy. It does not reveal the Client's identity, the underlying Anchor, or a score assigned by the Moderator.¶
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, a Site 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.¶
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.¶
Moderator credentials can carry policy state, such as quota or revocation state. State updates must not give a Site 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.¶
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 Site; 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-Site channel is outside this architecture.¶
TODO Security¶
TODO Privacy Consideration section is more widespread than properties¶
This document has no IANA actions.¶
TODO acknowledge.¶