]> Google LLC

sgschlesinger@gmail.com

Mozilla

ietf@dennis-jackson.uk

Cloudflare

ot-ietf@thibault.uk

moderation endorsement unlinkability privacy MoLE targets browser deployments, so Clients, Anchors, and Moderators need an HTTP transport for the protocol flows defined by the architecture. This document defines the Mole HTTP authentication scheme, which carries challenges and presentations for the endorsement and credential flows, and the headers used to return credential material. The grant exchanges with the Anchor are defined per protocol in . About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction TODO

Terminology 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 when, and only when, they appear in all capitals, as shown here.

Presentation Language This document uses the TLS presentation language to describe the structure of protocol messages. In addition to the base syntax, it uses two additional features: the ability for fields to be optional and the ability for vectors to have variable-size length headers.

Optional Value An optional value is encoded with a presence-signaling octet, followed by the value itself if present. When decoding, a presence octet with a value other than 0 or 1 MUST be rejected as malformed. ; ]]>

Variable-Size Vector Length Headers In the TLS presentation language, vectors are encoded as a sequence of encoded elements prefixed with a length. The length field has a fixed size set by specifying the minimum and maximum lengths of the encoded sequence of elements. In this document, there are several vectors whose sizes vary over significant ranges. So instead of using a fixed-size length field, it uses a variable-size length using a variable-length integer encoding based on the one described in . They differ only in that the one here requires a minimum-size encoding. Instead of presenting min and max values, the vector description simply includes a V. For example: ; opaque variable; } StructWithVectors; ]]>

HTTP Authentication Scheme We describe the HTTP authentication method used by a Client that has an Endorsement from an Anchor and obtains a Credential from a Moderator. The Mole authentication scheme follows the HTTP authentication framework defined in . It carries challenges, redemptions, and presentations: an Anchor or a Moderator challenges the Client, and the Client answers in the Authorization header of a request. Only the grant exchanges with the Anchor sit outside the scheme. Their carriage is defined per endorsement protocol in , for example over HTTP POST. | | | |<----------------------- Mole-Credential --+ | | ]]> A challenge names a single endorsement or credential type. To offer a choice, a server sends multiple Mole challenges; the Client picks one it supports and MUST ignore challenges whose type it does not recognize. All base64url values in this document are encoded without padding ().

Configuration Anchors and Moderators publish configuration used by Clients before running the HTTP authentication flows. Configuration includes endpoint URLs, supported protocol types, public key material, and the Anchor set associated with each Moderator policy. Its contents and format are defined in the Key Rotation and Discovery section of .

Error Handling Moderators can use MoLE as optional authentication. A 200 response MAY include a WWW-Authenticate: Mole challenge. This tells the Client that a later request can include a presentation, for example to get a higher limit or avoid other friction. In such deployments, Clients SHOULD apply the greasing rules of . A 401 response with a WWW-Authenticate: Mole challenge means that the Moderator requires MoLE, or another acceptable authentication scheme, before serving the resource. A 403 response means that the Moderator understood the presented MoLE material but did not accept it under policy.

Endorsement The criteria to provide an endorsement is left to the Anchor. This document only defines the HTTP carriage for the Endorsement protocol messages.

Anchor -> Client ; } EndorsementChallenge; ]]>

• challenge contains a base64url EndorsementChallenge value, encoded per .

", realm="anchor" ]]>

Client <-> Anchor After receiving a challenge, the Client runs the grant exchanges with the Anchor as defined by the endorsement protocol in , for example HTTP POST requests such as the ones defined there. The anchor_context from the challenge is carried into the first request as specified by the endorsement type.

Issuance

Moderator -> Client ; } ModeratorChallenge; ]]>

• challenge which contains a base64url ModeratorChallenge value, encoded per

The challenge field carries the Challenge structure of the named endorsement type, defined in .

Example refinement The following structure is an example refinement of ModeratorChallenge. ; // Moderator-generated policy identifier opaque anchor_set; // Endorsement-type-specific Anchor material } MoleModeratorChallenge; ]]> In MoleModeratorChallenge, anchor_set is opaque. Clients MUST NOT assume array semantics unless the endorsement type defines them. ", realm="moderator" ]]>

Client -> Moderator The Client answers with a CredentialRequest () in the Authorization header of a request to the Moderator. It carries the endorsement redemption, bound to this challenge, together with the issuance request. " ]]>

Moderator -> Client The Moderator returns the CredentialResponse () in the Mole-Credential response header. " ]]>

Presentation

Moderator -> Client - Challenge ; } CredentialChallenge; ]]>

• challenge which contains a base64url CredentialChallenge value, encoded per

The challenge field carries the Challenge structure of the named credential type, defined in .

Example refinement The following structures are example refinements of CredentialChallenge. ; // URI of the moderator opaque presentation_context; } MoleCredentialChallenge; struct { opaque policy_context; // Moderator-generated policy identifier opaque request_context; // binding value, analogous to // redemption_context in RFC 9577 } MolePresentationContext; ]]> The moderator_uri field contains a URI (defined by ). It names the endpoint where the Client runs Redeem & Issue if it holds no Credential. In MolePresentationContext, policy_context identifies the Moderator policy and accepted Anchor set used for this resource. Different resources MAY use different policy contexts while sharing the same Moderator. The value MUST be non-empty. The request_context field binds the presentation to a request, session, or time window. A non-empty value affects credential caching and replay handling. TODO(thibault): 1. decide exact construction rules for request_context. maybe it should include policy_context. ", realm="moderator" ]]>

Client -> Moderator - Presentation ; } CredentialPresentation; ]]> The presentation_and_update field carries the PresentationAndUpdate structure of the named credential type, defined in . " ]]> A complete instantiation example is given in the appendix of .

Moderator -> Client - Update TODO(thibault) 1. Headers do not have a fixed protocol limit, but large values are hard to deploy. Other instantiations may define another method, such as returning a URL that the client can fetch. TBD ; } CredentialUpdate; struct { optional update; } OptionalCredentialUpdate; ]]> The update_response field carries the Update structure of the named credential type, defined in . Updates use the same Mole-Credential header as issuance: both return credential material from the Moderator. The parameter distinguishes them, response for issuance and update after a presentation. The Moderator MUST send Mole-Credential with the update parameter after a presentation. It sets the update when the Credential remains usable after presentation. It marks the update as absent to intentionally consume the Credential. Clients MUST follow the Credential type semantics for reuse after an omitted update.

• update which contains a base64url OptionalCredentialUpdate value, encoded per

" ]]> Each credential type MUST define the challenge fields that partition cached Credentials, or state that Credentials of that type are not cacheable.

Security Considerations All exchanges defined in this document MUST be carried over HTTPS. TODO. The list to cover:

1. Challenge replay and caching: when a Client may reuse a cached credential against a repeated challenge.
2. Header size limits and what happens when updates exceed them.

IANA Considerations

Authentication Scheme This document registers the Mole authentication scheme, as defined in , in the "HTTP Authentication Schemes" registry.

HTTP Field Names This document registers the Mole-Credential field name in the "Hypertext Transfer Protocol (HTTP) Field Name Registry". Endorsement and credential type values are registered in , not in this document.

References Normative References The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. n.d. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.

Acknowledgments TODO acknowledge.