RepSec Non-Reusable Data Extension (NRU)

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 5 March 2026.¶

Copyright Notice

Copyright (c) 2025 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

NRU binds a one-time verification token to four inputs:¶

• dataset_id¶

• requester_id¶

• ts (issuance time)¶

• nonce (random)¶

Stolen copies fail verification because tokens are single-use and time-bound.¶

2. Requirements

Implementations MUST satisfy these requirements:¶

• Generate signed one-time tokens.¶

• Validate freshness and reject reuse.¶

• Consult revocation lists for compromised tokens.¶

3. Token Format

COSE_Sign1 payload fields are defined as follows.¶

dataset_id

tstr or bstr.¶

requester_id

tstr.¶

ts

int (UNIX time).¶

nonce

bstr (96-bit).¶

exp

int (absolute expiry).¶

Ed25519 signatures are RECOMMENDED.¶

4. Verification and Revocation

Verifiers MUST check signature validity, single-use, freshness, and absence on a signed revocation manifest.¶

5. Security Considerations

TLS 1.3 [RFC8446] is RECOMMENDED for transport. Reliable time sources are REQUIRED.¶

6. IANA Considerations

No IANA actions.¶

Author's Address