Skip to content

IETF 126 Review

Jump to bottom
Meridian Verity Group edited this page Jul 19, 2026 · 1 revision

IETF 126 Review

Standards status

draft-lee-orprg-permit-receipts-00 is an active individual Internet-Draft. It is a work in progress, has no formal standing as an IETF standard, and is not endorsed by the IETF. The current -00 revision expires on 2026-12-06 unless updated or replaced.

This repository is a companion public evaluation artifact for discussion and running-code review. It is not an official IETF reference implementation, certification suite, or conformance program.

Five-minute packet

python -m pip install -r requirements.txt
python -m pip install -e . --no-deps
python ietf126/run_review_packet.py
python ietf126/independent_recompute.py
python ietf126/independent_crypto_verify.py

See Reviewer Fast Path for environment setup and the v2.2.6 install erratum.

Separate frozen payment-composition input

ietf126-payment-composition-v0.1 is a frozen pre-execution input, not a composition or interoperability result. It does not modify or supersede the canonical v2.2.6-public-eval review packet. Result classification must wait for execution of the separately frozen composition and review of returned evidence.

High-value review questions

Field model

  • Which fields are authorization-critical for each effect family?
  • Are optional and absent values unambiguous?
  • Are policy, epoch, scope, issuer, validity, status, and replay relationships clear enough for independent implementation?
  • Which fields belong in a common receipt core versus a profile?

Canonicalization and action binding

  • Can two materially different effects produce the same canonical representation?
  • Are numbers, strings, time values, Unicode, duplicate keys, defaults, arrays, and omitted fields handled deterministically?
  • Is the canonicalization profile explicitly identified and cryptographically bound?

Verification and failure semantics

  • Are missing, stale, conflicting, malformed, revoked, replayed, unsupported, or unverifiable conditions consistently DENY?
  • Are policy rollback and minimum-epoch rules clear?
  • Are constrained modes narrow and unable to waive non-waivable checks?
  • Are denial reasons stable and useful for interoperability without leaking sensitive data?

Non-bypassability and dual enforcement

  • What deployment evidence would be required to claim all protected paths traverse an interceptor?
  • Which high-risk effect families need a downstream capability or decision-receipt check?
  • How should audience, digest, epoch, validity, and replay state be bound at the second boundary?

Public-safe feedback

Good public feedback includes:

  • a synthetic vector;
  • a reproducible canonicalization discrepancy;
  • a field-model ambiguity;
  • a proposed fail-closed negative case;
  • a release reproducibility finding; or
  • a cross-reference or signature-coverage question using only public artifacts.

Do not publish customer data, credentials, production logs, payment data, claim charts, confidential implementation mappings, private legal analysis, or commercial strategy.

Use the structured repository Issue Forms for artifact feedback when enabled. Use applicable IETF venues for standards-process discussion. Repository activity remains governed by the repository's evaluation-only terms unless separately agreed in writing.

IPR boundary

A related IETF IPR disclosure exists. The repository itself does not grant a patent license or standards commitment. Review the disclosure, PATENT-NOTICE.md, and LICENSE-EVALUATION.md before implementation or use beyond permitted evaluation.

Clone this wiki locally