MoLE HTTP Transport

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 7 January 2027.¶

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

TODO¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Presentation Language

This document uses the TLS presentation language [TLS13] 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.¶

struct {
    uint8 present;
    select (present) {
        case 0: struct{};
        case 1: T value;
    };
} optional<T>;

struct {
    uint32 fixed<0..255>;
    opaque variable<V>;
} StructWithVectors;

4. 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 [HTTP]. 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 [PROTOCOLS], for example over HTTP POST.¶

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 ([BASE64]).¶

5. 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 [PROTOCOLS].¶

6. 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 [PROTOCOLS].¶

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

struct {
  uint16 endorsement_type;
  opaque anchor_context<V>;
} EndorsementChallenge;

WWW-Authenticate: Mole challenge="<endorsement-challenge>",
                       realm="anchor"

struct {
  uint16 endorsement_type; // always present, see PROTOCOLS
  opaque challenge<V>;
} ModeratorChallenge;

struct {
  opaque policy_context<V>; // Moderator-generated policy identifier
  opaque anchor_set<V>; // Endorsement-type-specific Anchor material
} MoleModeratorChallenge;

WWW-Authenticate: Mole challenge="<moderator-challenge>",
                       realm="moderator"

Authorization: Mole credential-request="<credential-request>"

Mole-Credential: response="<credential-response>"

struct {
  uint16 credential_type; // always present, see PROTOCOLS
  opaque challenge<V>;
} CredentialChallenge;

struct {
  opaque moderator_uri<1..2^16-1>; // URI of the moderator
  opaque presentation_context<V>;
} MoleCredentialChallenge;

struct {
  opaque policy_context<V>; // Moderator-generated policy identifier
  opaque request_context<V>; // binding value, analogous to
                             // redemption_context in RFC 9577
} MolePresentationContext;

WWW-Authenticate: Mole challenge="<credential-challenge>",
                       realm="moderator"

struct {
  uint16 credential_type; // always present, see PROTOCOLS
  opaque presentation_and_update<V>;
} CredentialPresentation;

Authorization: Mole presentation="<credential-presentation>"

struct {
  uint16 credential_type;
  opaque update_response<V>;
} CredentialUpdate;

struct {
  optional<CredentialUpdate> update;
} OptionalCredentialUpdate;

Mole-Credential: update="<optional-credential-update>"

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

8. IANA Considerations

9. References

Acknowledgments

TODO acknowledge.¶

Authors' Addresses