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 25 December 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

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]. The same scheme is used for three protocol exchanges: Client to Anchor endorsement, Client to Moderator credential issuance, and Client to Site credential presentation.¶

Mole-Issuance is a placeholder header. We might want Mole-Presentation as well.¶

5. Configuration

TODO(thibault) 1. if protocol section goes into its own draft, this should follow 2. I suspect we'll use JSON here. If we use key material, I think re-using JWKS is important (even if there are feelings).¶

Anchors and Moderators publish configuration used by Clients and Sites 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.¶

6. Error Handling

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

A 401 response with a WWW-Authenticate: Mole challenge means that the Site requires MoLE, or another acceptable authentication scheme, before serving the resource. A 403 response means that the Site 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;
  opaque request<V>;
} EndorsementRequest;

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

struct {
  uint16 endorsement_type;
  opaque response<V>;
} EndorsementResponse;

Mole-Endorsement: response="<endorsement-response>"

struct {
  uint16 endorsement_type; // We always want endorsement type to be present
  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 endorsement="..."

struct {
  uint16 credential_type; // We always want credential type to be present
  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 site_context<V>; // Site-chosen binding value, analogous to redemption_context in RFC9577
} MolePresentationContext;

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

struct {
  uint16 credential_type; // We always want credential type to be present
  opaque presentation_and_update<V>;
} CredentialPresentation;

struct {
  opaque presentation_context<V>;
  opaque presentation_proof[Npp];
  opaque update_request[Nur];
} MolePresentationAndUpdate;

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

struct {
  uint16 credential_type;
  opaque presentation_and_update<V>;
} ValidationRequest;

struct {
  uint16 credential_type;
  uint8 valid;
  opaque update_response<V>;
} ValidationResult;

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

struct {
  optional<CredentialUpdate> update;
} OptionalCredentialUpdate;

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

7. HTTP protocol (probably its own draft)

In Section 4, we define two protocol registries: endorsement and site.¶

8. Security Considerations

9. IANA Considerations

10. References

Acknowledgments

TODO acknowledge.¶

Author's Address