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 16 April 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

[PROTOCOLS] defines the MoLE messages. This document carries them over HTTP. Challenges and presentations use the Mole authentication scheme [HTTP]. Credential material returns in the Mole-Credential response header. Grant exchanges with an Anchor are HTTP POST requests defined in [PROTOCOLS].¶

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

Message structures, their encoding, and the abstract operations (ProcessPresentation) are those of [PROTOCOLS]. Every binary value in a header is the unpadded base64url encoding ([BASE64]) of the TLS presentation encoding of the named structure.¶

3. The Mole Authentication Scheme

Each Mole challenge carries exactly one of these payload parameters:¶

The parameter name tells the Client which structure it holds; ModeratorChallenge and CredentialChallenge share a layout. A server offering a choice sends several Mole challenges. The Client picks one it supports and MUST ignore challenges of unknown type.¶

A Mole credential in Authorization carries exactly one of these payload parameters:¶

Parameters follow the auth-param syntax of Section 11.2 of [HTTP]; a value may be a token or a quoted-string. One WWW-Authenticate field can carry several challenges (Section 11.6.1 of [HTTP]), and the rules below apply to each Mole challenge or credential separately. A recipient ignores unknown parameters, including realm. It MUST reject as malformed a challenge or credential with a repeated parameter, or with none or more than one of the payload parameters above. It MUST reject a payload value that is not canonical unpadded base64url, or whose decoded value does not parse as the named structure. A Client ignores a malformed challenge and can use another one.¶

4. The Mole-Credential Field

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

An absent CredentialUpdate means the Moderator consumed the Credential without replacement. A missing Mole-Credential field carries no such decision. A Client MUST process Mole-Credential whatever the response status.¶

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

5. Configuration

The Anchor and Moderator configurations are defined in [PROTOCOLS]. 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.¶

6. Exchanges

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

WWW-Authenticate: Mole endorse="<endorsement-challenge>"

WWW-Authenticate: Mole redeem="<moderator-challenge>"

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

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

WWW-Authenticate: Mole challenge="<credential-challenge>"

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

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

struct {
  uint16 credential_type;
  opaque recovery_handle<V>;
} CredentialRecovery;

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

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