]> 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 defines the MOLE messages. This document carries them over HTTP. Challenges and presentations use the Mole authentication scheme . Credential material returns in the Mole-Credential response header. Grant exchanges with an Anchor are defined in .

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 when, and only when, they appear in all capitals, as shown here. Payload encodings and abstract operations are defined by . Header payloads use canonical unpadded base64url (). HTTP carries type-specific payloads directly, without outer type or length wrappers.

The Mole Authentication Scheme | | | |<------------ Mole-Credential: update-T= --+ | | ]]> Payload parameter names end in -T, where T is a registered endorsement or credential type from , written as exactly four lowercase hexadecimal digits. For example, EC-IHAT (endorsement type 0x0002) is challenged with redeem-0002, and EC-ACT (credential type 0x0001) is presented with presentation-0001. Recipients also accept uppercase digits, since parameter names are case-insensitive (). Type 0x0000 is invalid. Each Mole challenge has exactly one payload parameter: Challenge parameters

Parameter	Registry	Decoded payload
endorse-T	Endorsement	Anchor context, empty for the types here
redeem-T	Endorsement	RedemptionChallenge
challenge-T	Credential	Type-specific Challenge

A server offers a choice using separate Mole challenges. The Client ignores unknown types and chooses a supported configuration. A redeem-T challenge selects the endorsement type. The Client selects the credential type from the same Moderator's configuration, independently of the endorsement type. A Mole credential in Authorization selects one operation: Authorization parameters

Parameters	Decoded payloads
redeem-E, credential-request-C	Redemption, IssuanceRequest
presentation-T	PresentationAndUpdate
recovery-T	Recovery handle

E uses the endorsement registry. C, presentation, and recovery use the credential registry. Only Redeem & Issue has two payload parameters. It requires exactly one of each, in either order. Type 0001's empty redemption is carried as redeem-0001="". Parameters use auth-param syntax (). Values can be tokens or quoted-strings. Senders quote empty values. Recipients unescape quoted-strings before decoding. Multiple challenges in one field follow . These rules apply to each challenge separately. Unknown parameters, including realm, are ignored. A name beginning with one of the operation prefixes above but lacking exactly four hexadecimal digits is malformed, not an unknown extension. A recipient MUST reject duplicate parameter names, mixed operations, and missing or extra payload parameters, including payloads of unknown types. It MUST reject noncanonical base64url and, for known types, trailing bytes or malformed content. Clients ignore malformed challenges and may use another one. An unknown presentation type is treated as absent when authentication is optional and rejected when required, as specified by . Other requests of unknown type are rejected. Unknown types never select a known payload decoder. Greased types follow these same rules.

The Mole-Credential Field Mole-Credential returns credential material to the Client. Its value is one parameter, with the syntax above: Mole-Credential parameters

Parameter	Decoded payload
response-T	IssuanceResponse
update-T	Update, or empty for recorded NoUpdate

T uses the credential registry and MUST match the pending exchange. The field contains exactly one parameter and MUST NOT be repeated. An empty update-T="" means the Moderator consumed the Credential without replacement. A nonempty value carries the type's Update. Registered credential protocols MUST define nonempty Update encodings. A missing Mole-Credential field carries no such decision. A Client MUST process Mole-Credential whatever the response status. The credential result does not establish whether the protected operation completed. Recovery returns this result without another operation attempt. A server sending Mole-Credential MUST also send Cache-Control: no-store. A server answering cross-origin requests MUST list WWW-Authenticate and Mole-Credential in Access-Control-Expose-Headers.

Configuration The Anchor and Moderator configurations are defined in . A Client stores each Credential with the Moderator and Redeem & Issue endpoint it came from. A Client that keeps a presentation for recovery also keeps the HTTP request that carried it.

Exchanges

Grant The grant endpoint comes from Anchor configuration. The Client sends a POST with the type-specific grant message as its body. The media type is application/mole-endorsement-request with a required type parameter using the same four-digit hexadecimal encoding. The response uses application/mole-endorsement-response with the same type. There is no outer EndorsementRequest or EndorsementResponse wrapper. The first EC-IHAT request carries a GrantRequest naming the number of Endorsements the Client asks for (): The criteria for granting are the Anchor's. The Anchor returns 200 (OK) with the response media type only when it produced a complete grant response. A Client MUST reject a non-success status, an unexpected media type, a response whose type differs from its request, trailing bytes, or malformed type-specific content. Clients MUST NOT automatically redirect a grant POST carrying protocol state.

Redeem & Issue The Moderator challenges with the endorsement type: " ]]> The Client answers with a POST to the Redeem & Issue endpoint from configuration, whichever resource sent the challenge: ", credential-request-0001="" ]]> On success the Moderator answers 200 with: " ]]>

Presentation The Moderator challenges with the credential type: " ]]> A challenge in a 401 response means the resource requires a presentation. A challenge in a 200 response means a presentation is optional, for instance to raise a limit. Clients then apply the greasing rules of . The Client repeats the protected request with: " ]]> The Moderator runs ProcessPresentation. Every response to an accepted presentation, fresh or not, MUST carry the recorded update, including when the protected operation fails with a 4xx or 5xx status: " ]]> For a fresh result the Moderator attempts the protected operation and returns its status. For a result that is not fresh, it MUST return 409 () and MUST NOT attempt the protected operation. A rejected presentation MUST NOT carry Mole-Credential. A Client that receives no Mole-Credential after sending a presentation keeps its pending state and MAY recover (). Each credential type MUST define the challenge fields that partition cached Credentials, or state that its Credentials are not cacheable.

Recovery Instead of resending a presentation, a Client MAY send a POST with empty content to the Redeem & Issue endpoint it stored with the Credential: " ]]> The recovery handle is defined by the credential type in . The Moderator treats it as the byte-identical presentation and uses no other Client identifier. It MUST NOT verify a proof or attempt the protected operation. If a result is still retained, it answers 200 with the recorded update-T, including the empty value for a recorded NoUpdate. Otherwise it answers 404 without Mole-Credential, whether or not a record exists.

Status Codes Mole responses

Outcome	Status	Mole-Credential
Malformed request	400	none
Missing, expired, or invalid authentication	401	none
Rejected by policy before acceptance	403	none
Credential issued	200	response-T
Fresh accepted presentation	protected operation's status	update-T
Duplicate presentation with retained result sent to the protected resource	409	update-T
Recovery, result retained	200	update-T
Recovery, result unavailable	404	none

The Moderator MUST use these rules for every credential type. A 401 response MUST carry a Mole challenge for the required exchange. A 403 returned by the protected operation after a fresh acceptance is that operation's status, and carries the update. A Client MUST NOT infer chain termination from any status without the recorded empty update.

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

1. Header size limits: request and response field limits a deployment must provision for the payloads it offers, and the status returned before acceptance when a payload does not fit. A Moderator must not consume an Endorsement, or record NoUpdate, because a response would be too large.
2. Challenge caching and reuse: when a Client may reuse a cached challenge (same Moderator, type, key and context, scope), and that reuse never permits reuse of a spent Credential or Endorsement.
3. Request binding: this document defines no canonical HTTP request serialization. EC-ACT request_context must cover what the Moderator authorizes, including the body. Reverse flow has no request binding.
4. Recovery: what recovery reveals and its lack of Client authentication beyond the handle.
5. Grant and issuance recovery: a lost grant or issuance response currently costs the Client its session or Endorsement. Whether to add recovery for these exchanges, and how to authenticate a lookup by session ID or nullifier, is open.

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. Google LLC Mozilla Cloudflare This document defines protocols that instantiate the MoLE architecture: two endorsement protocols, by which a Client proves to a Moderator that it holds an Endorsement from a trusted Anchor without revealing which one, and three credential protocols, by which a Moderator issues, verifies, and updates per-Client state without being able to link presentations. It also establishes the registries that identify these protocols. 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]

Acknowledgments TODO acknowledge.

Changelog draft-jms-mole-http-transport-01

• Select protocol types in parameter names and carry type-specific payloads directly, removing the outer message wrappers.
• Separate endorsement redemption from credential issuance parameters and send Redeem & Issue to the configured endpoint.
• Add recovery by handle and define status codes for fresh presentations, duplicates, and recovery. Distinguish an empty update from a missing response.
• Specify parameter validation, canonical base64url, caching, and CORS rules.
• Support batched EC-IHAT grants and require a media type parameter identifying the endorsement type.