Skip to content

Home

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

PermitReceipt Public Evaluation Wiki

Important

This repository is a synthetic, source-available public evaluation artifact for standards discussion, interoperability review, and reproducible running-code review. It is not production software, not an IETF standard, not an official IETF reference implementation, not a certification or conformance program, and does not grant a patent license or production-use right.

The review question

Before a protected external effect commits, is there current, scope-bound permit evidence authorizing the exact effect being attempted now?

A protected external effect should be committed only when a verifier can establish—immediately before the effect boundary—that machine-verifiable evidence authorizes that exact effect under the applicable policy, validity, scope, issuer, status/recency, anti-replay, and profile requirements.

Start by goal

Your goal Start here Typical path
Run the review packet Reviewer Fast Path 5–15 minutes
Understand the security model Concepts and Threat Model 10 minutes
Review components and boundaries Architecture and Trust Boundaries 10–20 minutes
Audit the published evidence Evidence and Test Matrix 15–30 minutes
Verify release integrity Reproducibility and Release Integrity 15–45 minutes
Review the IETF discussion artifact IETF 126 Review 10–30 minutes
Check known issues Current Status and Errata 3 minutes
Read in Korean 한국어 개요 5 minutes

Narrow security claim

For a protected external interface I and effect request e, the intended control posture is:

Commit_I(e) only when Verify(e, receipt, policy, status, context) = ALLOW
and every policy-designated downstream capability check succeeds.

The model binds authorization to a canonical request representation and action_digest, then checks policy epoch, validity, scope, issuer/authenticity evidence, status or revocation recency, anti-replay state, and profile-specific requirements. Missing, stale, ambiguous, conflicting, malformed, revoked, replayed, unsupported, or unverifiable authorization-critical evidence is expected to fail closed.

This does not prove that a deployment has placed a non-bypassable interceptor on every production path. It also does not solve policy correctness, root-of-trust integrity, model alignment, or operational security by itself.

Current public status

  • Canonical public-evaluation release: v2.2.6-public-eval
  • Release classification: synthetic public evaluation; not production software
  • Internet-Draft: draft-lee-orprg-permit-receipts-00
  • Datatracker status: active individual Internet-Draft; not endorsed by the IETF and without formal standing in the IETF standards process
  • Known release erratum: issue #1 — portable build-backend bootstrap
  • Separate IETF 126 payment-composition input: ietf126-payment-composition-v0.1 — HOLD; FROZEN PRE-EXECUTION INPUT — NOT A RESULT. It does not modify, replace, or supersede v2.2.6-public-eval, and no successful composition or interoperability result is claimed.

Published release evidence

The v2.2.6-public-eval release page reports the following results. This wiki records those values as published project evidence; it does not independently rerun, certify, or endorse them.

Check Published result
Strict pytest suite 323 / 323 PASS
Public evaluation vectors 76 / 76 PASS
IETF 126 selected review packet 20 / 20 PASS
Independent recomputation checks 17 / 17 PASS
Independent cryptographic checks 19 / 19 PASS
Extended public runners 21 / 21 PASS
Full orprg_eval statement coverage 99.33%
Full orprg_eval branch coverage 98.44%
Security-core line coverage 100.00%
Security-core branch coverage 99.705%
Verifier branch coverage 100.00%
Strict-schema branch coverage 100.00%

See Evidence and Test Matrix for commands, interpretation, limitations, and source links.

Source authority by question

This wiki is a curated navigation and explanation layer, not the canonical store for release bytes or normative status.

Question Use this source
Which bytes and hashes define a release? The explicit release asset tuple verified against its checksum, member manifest, provenance statement, and tag
What corrections or known defects apply? The release-page errata, Current Status and Errata, and the linked public issue
What behavior belongs to a specific version? The tagged source, schemas, vectors, tests, and release notes for that version
What is the current Internet-Draft or IPR status? The IETF Datatracker document and IPR records
Where should a reviewer begin? This wiki

Key sources:

Next step

Run the Reviewer Fast Path, then inspect at least one ALLOW vector and several fail-closed DENY vectors before forming a security conclusion.

Clone this wiki locally