AAuth Mission Expiry

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 11 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

AAuth defines expires_at as an OPTIONAL member of the approved mission blob: every Person Server (PS) decision path MUST compare the current time to it and treat a mission past it as terminated, and the PS caps the Person Tokens and Auth Tokens it issues at it (Section 8.2 of [I-D.draft-hardt-oauth-aauth-protocol]). This document profiles the member with the deltas in Section 3 and Section 4.¶

An AAuth mission is approved once and then relied on for as long as it stays active. Absent an expiry, an approval remains usable indefinitely through a stream of fresh short-lived tokens. Because expires_at sits inside the approved mission blob, it is part of what the Person approves, it is covered by the s256 content address, and it cannot be changed in place.¶

2. Conventions and 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.¶

This document uses Person, Agent, Person Server (PS), Access Server (AS), Resource, Person Token, Resource Token, Auth Token, mission, approved mission blob, and mission proposal as defined by [I-D.draft-hardt-oauth-aauth-protocol].¶

The pair of the approving PS and s256 is the Mission Reference, AAuth's mission identity (Section 8.2.1 of [I-D.draft-hardt-oauth-aauth-protocol]). The approving PS is named by the iss of a Person Token, the ps claim of a Resource Token or Auth Token, or the PS a request is made to; the blob carries no member naming it. On the wire, the reference is the mission_s256 claim or parameter.¶

3. The expires_at Member

AAuth defines expires_at as an OPTIONAL member of the approved mission blob [I-D.draft-hardt-oauth-aauth-protocol]. This profile adds one requirement of its own: under this profile, expires_at MUST be an RFC 3339 date-time [RFC3339], the internet profile of the ISO 8601 form AAuth's own text uses, and MUST identify an instant later than the blob's approved_at.¶

Because expires_at is in the approved mission blob, it is covered by s256 and cannot be changed in place, as AAuth specifies for every blob member. Changing an approved expiry requires proposing and approving a new mission, which carries a new s256 and therefore a new Mission Reference.¶

A mission whose approved blob has no expires_at member has no expiry.¶

4. Enforcement

AAuth requires every PS decision path to compare the current time to expires_at and to treat a mission past it as terminated (Section 8.2 of [I-D.draft-hardt-oauth-aauth-protocol]). The PS caps the Person Tokens and Auth Tokens it issues at expires_at (Sections 7.1.2 and 9.4.1 of [I-D.draft-hardt-oauth-aauth-protocol]), and the presented token carries that bound to an AS (Section 9.1.1 of [I-D.draft-hardt-oauth-aauth-protocol]). A Resource Token is a short-lived request artifact whose lifetime is independent of expires_at; the PS verifies that the mission is active and unexpired whenever it acts on one (Sections 6.7.1 and 6.7.2 of [I-D.draft-hardt-oauth-aauth-protocol]). This profile adds only a promptness requirement: the PS SHOULD terminate at the deadline itself, rather than waiting for the next request under the reference, so that status and logging reflect the transition without delay.¶

5. Proposal and Approval

A mission proposal MAY include expires_at, a proposal member this profile defines; AAuth's proposal carries description, tools, and resources (Section 8.1 of [I-D.draft-hardt-oauth-aauth-protocol]). The PS or the Person MAY add or change the value during clarification, before approval. The approved value is the one in the approved mission blob, and the Agent verifies and stores the decoded blob bytes as AAuth specifies (Section 8.2 of [I-D.draft-hardt-oauth-aauth-protocol]).¶

Support is discovered from the approved blob itself: a deployment that requires a lifetime bound checks the approved blob and treats the member's absence according to its policy. A PS that does not implement this profile ignores the proposal member, since AAuth recipients ignore what they do not recognize (Section 11.7 of [I-D.draft-hardt-oauth-aauth-protocol]). A proposal is not a guarantee that the approved blob will carry the bound.¶

6. Relationship to Other Specifications

The Mission Context Binding for AAuth [I-D.draft-mcguinness-mission-aauth] requires AAuth's native expires_at member and approves no mission without it. Base AAuth deployments get enforcement regardless of that binding: it is the base protocol's.¶

A PS that also implements AAuth Mission Management [I-D.draft-mcguinness-mission-aauth-management] records the transition with termination reason expired, surfaced through AAuth's mission_terminated error and the status operation, and serializes automatic expiry with explicit termination as that document specifies.¶

7. Conformance

An AAuth Person Server conforms to this profile when it:¶

1. requires expires_at, once present in the approved mission blob, to be an RFC 3339 date-time naming an instant later than approved_at (Section 3); and¶

2. documents its clock synchronization, comparison precision, and tolerated clock skew (Section 8).¶

Prompt termination at the deadline itself, rather than at the next request under the reference, remains a SHOULD (Section 4). Support for expires_at remains OPTIONAL, following the approved blob member it profiles.¶

8. Security Considerations

AAuth judges a token's exp by the verifier's own clock with no tolerance for clock skew (Section 11.5.2 of [I-D.draft-hardt-oauth-aauth-protocol]), and says nothing about tolerance for the expires_at comparison (Section 8.2 of [I-D.draft-hardt-oauth-aauth-protocol]). Clock synchronization, comparison precision, and tolerated clock skew MUST be documented by the deployment. An Agent SHOULD NOT schedule work that depends on completing near the deadline.¶

Expiry bounds duration; it does not end a mission early. A compromise discovered before the deadline still requires an explicit termination mechanism.¶

Already-issued Person Tokens and Auth Tokens are the residual after expiry. The issuance bound in Section 4 keeps that residual inside the mission's lifetime. A Resource Token can outlive expires_at, but the PS acts on none after it (Section 4).¶

Immutability defeats lifetime extension. An attacker who controls an Agent cannot stretch an approved mission's lifetime; a longer lifetime requires a new proposal and a new approval by the Person.¶

9. Privacy Considerations

expires_at is part of the private mission blob and is not disclosed to Resources or Access Servers. It adds no correlation surface beyond the blob itself.¶

10. IANA Considerations

This document requests no IANA registrations. expires_at is an AAuth mission blob member (Section 8.2 of [I-D.draft-hardt-oauth-aauth-protocol]), and AAuth establishes no registry for mission proposal members. If AAuth creates one before publication, this document will request registration of the proposal member expires_at.¶

Acknowledgments

The AAuth protocol and its extension points are the work of Dick Hardt.¶

References

Author's Address