🔐 What If You Could Check a Password Reset Decision — Without Seeing the Reset Code or New Password?

A bounded way to check whether declared reset evidence is complete, consistent, and linked to the declared subject, credential, and recovery request.

🔄 SLANG-ResetPassword

Password-reset systems often combine several very different questions:

Was identity proofing completed?

Was a reset token, one-time password, or recovery code validated?

What credential-replacement authorization result did the external authorizer declare?

Was the evidence intended for this subject, credential, replacement request, relying party, and recovery case?

Do multiple declared authorizers agree?

Is the evidence complete?

Is the outcome allowed to be shown?

Can the result later be reconstructed and checked?

SLANG-ResetPassword separates the operational recovery process from the structural admission of the resulting declared authorization evidence.

It does not establish whether identity proofing occurred, whether a reset token was valid, whether a recovery code was genuine, or whether an external authorizer was trustworthy.

Raw passwords, reset tokens, one-time passwords, recovery codes, and new passwords are not supported inputs.

An existing recovery and security system may perform identity proofing, validate recovery secrets, apply policy checks, and produce declared credential-replacement authorization evidence.

SLANG-ResetPassword then evaluates whether that evidence is structurally admissible under a declared reset context, authorizer set, evidence mode, profile, and ruleset.

Its central contract is:

same admitted canonical evidence + same bound reset context + same versioned profile and ruleset -> same bounded result state

The idea is deliberately narrow.

SLANG-ResetPassword does not authenticate users, replace credentials, grant access, create sessions, or execute password resets.

It asks a smaller structural question:

Given declared credential-replacement authorization evidence, what bounded admission state follows?

🌐 Explore SLANG-ResetPassword on GitHub

🧭 Reset Authorization Happens Outside the Resolver

SLANG-ResetPassword begins after an external recovery or security system has produced a declared authorization result.

The supported authorization result is one of:

RESET_AUTHORIZED

RESET_NOT_AUTHORIZED

The resolver does not infer that result from:

a password
a reset token
a reset code
a one-time password
a recovery code
an email address
a username
password strength
retry history
a recovery workflow

The distinction is:

declared reset-authorization evidence != independently repeated recovery checks

A RESET_AUTHORIZED declaration means that an external component declared authorization.

It does not prove that the external component was trustworthy, that the recovery checks occurred, or that a credential should actually be replaced.

🧩 What Does the Resolver Check?

SLANG-ResetPassword evaluates questions such as:

Is the input inside the supported portable JSON boundary?
Are the schema, profile, ruleset, and evidence mode supported?
Is every expected authorizer record present?
Does every evidence record match the declared reset context?
Are authorizer and evidence identifiers unique?
Do declared structural identities match their recomputed values?
Do multiple authorizers agree exactly?
Is evaluation authorized?
Is the outcome admitted for presentation?
Can the result be reconstructed from preserved evidence?

A simplified flow is:

submitted input -> admission -> normalization -> reset-context binding -> authorizer agreement -> bounded resolution -> visibility -> evidence

The resolver may return:

RESOLVED

INCOMPLETE

CONFLICT

FORBIDDEN

UNSUPPORTED

ABSTAIN

A non-result is not automatically a system failure.

It means that the submitted structure does not justify forcing an authorization outcome under the current profile.

🚦 A Result Is Not Forced

Consider a few examples.

If an expected authorizer record is missing:

missing expected evidence -> INCOMPLETE

If evidence refers to a different subject, credential, replacement request, relying party, or recovery case:

reset-context mismatch -> CONFLICT

If two declared authorizers disagree:

RESET_AUTHORIZED + RESET_NOT_AUTHORIZED -> CONFLICT

If the caller includes a reset token, recovery code, password, or new password:

raw recovery or password material -> FORBIDDEN

If the caller supplies its own reset-authority conclusion:

caller-supplied derived authority -> FORBIDDEN

If the schema or evidence mode is unknown:

unsupported representation -> UNSUPPORTED

If evaluation is not authorized:

evaluation_authorized = false -> ABSTAIN

The principle is:

Resolve when the declared contract supports a result. Refuse when it does not.

✅ RESET_AUTHORIZED and RESET_NOT_AUTHORIZED Are Both Resolved Outcomes

A complete supported negative declaration is not treated as a structural error.

The current mapping is:

RESOLVED + RESET_AUTHORIZED -> authorization_outcome = RESET_AUTHORIZED; admission_state = ADMIT

RESOLVED + RESET_NOT_AUTHORIZED -> authorization_outcome = RESET_NOT_AUTHORIZED; admission_state = DENY

For every non-result state:

authorization_outcome = NONE

admission_state = WITHHOLD

These values remain bounded structural statements.

ADMIT != operational reset authorization

DENY != account lockout

Neither value replaces a credential or grants reset authority by itself.

🔗 Evidence Must Match the Declared Reset Context

Each authorization record is bound to a declared context containing references such as:

subject
credential
credential version before replacement
replacement request
relying party
recovery case
expected authorizer set
evidence mode

Conceptually:

evidence reset context = declared reset evaluation context

A mismatch produces CONFLICT.

This prevents evidence declared for one recovery case, request, or credential version from being admitted as though it belonged to another.

But context binding has a limited meaning:

reset-context binding != identity ownership

It does not prove who owns the account, whether the recovery case is genuine, or whether the external authorizer was authentic.

👥 Single-Authorizer and Multi-Authorizer Modes

The current reference supports two evidence modes.

`SINGLE_AUTHORIZER`

The context declares exactly one authorizer, and exactly one matching authorization record must be supplied.

`MULTI_AUTHORIZER_EXACT_AGREEMENT`

The context declares between two and eight authorizers.

Every expected authorizer must provide one supported evidence record, and all admitted authorization results must agree exactly.

Conceptually:

all admitted authorizer outcomes agree -> continue

any admitted authorizer disagreement -> CONFLICT

This is not:

majority voting
quorum selection
weighted approval
first-arrival selection
automatic reconciliation

A RESET_AUTHORIZED declaration cannot outvote a RESET_NOT_AUTHORIZED declaration.

🖼️ SLANG-ResetPassword Reference Diagram

Figure: SLANG-ResetPassword separates existing recovery and security controls, declared reset-authorization evidence, reset-context binding, deterministic structural admission, visibility-aware public summaries, reconstruction bundles, and compact receipts.

🔒 Recovery Secrets and Password Material Are Outside the Supported Input

SLANG-ResetPassword rejects recognized fields associated with recovery secrets, password material, or caller-supplied authority conclusions.

Examples include:

password
current_password
new_password
reset_token
reset_code
otp
one_time_password
recovery_code
backup_code
recovery_secret
password_hash
salt
pepper
private_key
session_token
access_token
reset_authorized
credential_replaced
reset_authority
authorization_outcome
admission_state

The forbidden-field scan is recursive.

Recognized forbidden values are replaced with:

<FORBIDDEN_VALUE_REDACTED>

before reconstruction evidence or deterministic identities are created.

However, this is field-name-based protection.

It is not content-based secret detection.

forbidden-field rejection != value-level secret detection

A sensitive value placed inside an otherwise permitted, unknown, or unsupported field may still be retained in a reconstruction bundle.

Callers must therefore use opaque, non-secret references and review private artifacts before storing, transmitting, or sharing them.

👁️ Resolution and Visibility Are Different

SLANG-ResetPassword separates structural resolution from presentation.

For a resolved result:

reference_visibility_authorized = true -> VISIBLE

reference_visibility_authorized = false -> WITHHELD

The reconstruction bundle and compact receipt retain the complete deterministic outcome even when visibility is withheld.

They are private verification artifacts, not visibility-filtered presentation surfaces.

Visibility filtering is applied only through the public summary.

When a resolved outcome is withheld, the public summary sets:

authorization_outcome = null

admission_state = null

reason_codes = ["RESET_OUTCOME_WITHHELD"]

result_id = null

bundle_id = null

outcome_fields_redacted = true

The summary does not expose a directional reason code or an outcome-dependent private result or bundle identity.

For otherwise identical withheld cases:

withheld RESET_AUTHORIZED public summary = withheld RESET_NOT_AUTHORIZED public summary

This property is called:

WITHHELD_OUTCOME_NONINTERFERENCE

For otherwise identical withheld cases, the visibility-filtered public projection does not reveal whether the private resolved outcome was positive or negative.

This remains a presentation property.

It is not encryption, access control, cryptographic confidentiality, or operational reset authority.

public-summary redaction != cryptographic confidentiality

🧾 Public Summaries, Bundles, and Receipts Serve Different Purposes

Public summary

The public summary is the sole visibility-aware presentation projection.

It:

removes outcome-dependent private fields when the result is withheld
uses a neutral reason code
produces a deterministic public_summary_id
does not contain the complete submitted input
does not support complete reconstruction
is not a reset instruction, credential, token, or session authority

Reconstruction bundle

A reconstruction bundle preserves:

the parsed submitted input
the normalized projection
the complete result
deterministic structural identities
the bundle identity

Bundle verification reconstructs the normalized projection, result, and bundle identity from the preserved submitted input and requires exact canonical agreement.

A bundle may retain unknown or unsupported submitted values.

It must therefore be treated as a sensitive, access-controlled verification artifact.

Compact receipt

A compact receipt preserves selected states, reset-context references, identities, authority boundaries, and exact bundle binding without repeating the complete submitted input.

The receipt retains the full outcome even when public visibility is withheld.

Receipt verification checks receipt integrity.

Receipt-to-bundle verification checks whether the receipt corresponds exactly to the supplied reconstruction bundle.

The broader principle is:

A resolver should preserve enough declared evidence to explain and reproduce what it resolved, while keeping public presentation separate from private reconstruction.

🧠 Deterministic Identity Is Not Real-World Truth

SLANG-ResetPassword constructs domain-separated SHA-256 identities for structures including:

submitted input
canonical input
reset context
authorizer manifest
evidence set
evidence-agreement material
rule profile
bounded outcome
result
bundle
receipt
public summary

The general form is:

identity = prefix + sha256(canonical_json(preimage))

These identities support deterministic comparison, reconstruction, and tamper detection within the declared reference contract.

They do not prove:

authorizer authenticity
account ownership
recovery success
token validity
legal authority
credential-mutation authority
operational authorization
real-world truth

Important distinctions include:

evidence commitment syntax != source authenticity

deterministic reconstruction != successful recovery

receipt verification != reset authority

public-summary integrity != exact private-bundle binding

⚖️ What Does SLANG-ResetPassword Not Provide?

SLANG-ResetPassword does not replace:

account discovery
recovery-channel selection
identity proofing
reset-token validation
one-time-password validation
recovery-code validation
expiry and replay prevention
challenge consumption
retry and lockout controls
password-policy checks
breach checks
password hashing
credential storage
MFA
step-up authentication
abuse detection
rate limiting
credential replacement
session invalidation
authorization
access enforcement
monitoring and governance

A possible surrounding relation is:

credential_replacement_may_proceed = recovery_checks_pass AND structural_reset_authorization_admitted AND operational_policy_allows

SLANG-ResetPassword resolves only:

structural_reset_authorization_admitted

🔄 How Is This Different from SLANG-Password?

The two references address different bounded questions.

SLANG-Password asks:

Is declared evidence concerning an existing password-verification result structurally admissible?

SLANG-ResetPassword asks:

Is declared evidence concerning credential-replacement authorization structurally admissible?

A successful SLANG-Password result does not authorize credential replacement.

A successful SLANG-ResetPassword result does not prove that an existing password matched.

The two projects share structural vocabulary and verification practices while preserving separate profiles and authority boundaries.

🧪 Current Reference Status

The current reference is SLANG-ResetPassword v0.1.0.

Published verification results include:

permanent reference audit: 368/368 PASS
semantic vectors: 94/94 reproduced
presentation vectors: 6/6 reproduced
parser vectors: 13/13 reproduced
artifact vectors: 22/22 reproduced
reference evidence: 3/3 reproduced
serialization bytes: 4/4 reproduced
metamorphic relations: 12/12 reproduced
frozen-vector verification: PASS
canonical example resolution: PASS
canonical bundle verification: PASS
canonical receipt verification: PASS
receipt-to-bundle verification: PASS
public-summary verification: PASS
public-summary-against-bundle projection verification: PASS
withheld-outcome noninterference: PASS

The repository contains:

the Python reference implementation
frozen conformance vectors
a canonical example input
a reconstruction bundle
a compact receipt
the bounded profile
the reference diagram
public-summary verification commands
artifact regeneration commands

These results apply only to the declared v0.1.0 implementation, profile, ruleset, schemas, limits, artifacts, and test boundary.

They are not an independent security audit, identity-proofing assessment, or production certification.

⚠️ What SLANG-ResetPassword Claims — and Does Not Claim

SLANG-ResetPassword demonstrates:

strict structural input admission
reset-context-bound authorization evidence
exact authorizer-set checking
exact multi-authorizer agreement
explicit non-result states
deterministic state resolution
bounded order independence
visibility-safe public-summary presentation
withheld-outcome noninterference
deterministic structural identities
reconstruction bundles
compact receipts
frozen conformance vectors
reproducible reference artifacts

It does not provide:

identity proofing
password comparison
token validation
one-time-password validation
recovery-code validation
authentication
authorization
access control
credential mutation
session creation
password reset execution
source authentication
production security
legal or institutional authority

Its claim is narrower:

same admitted canonical evidence + same bound reset context + same versioned profile and ruleset -> same bounded result state

🌐 Explore SLANG-ResetPassword

The GitHub repository contains the reference implementation, profile, frozen vectors, canonical example input, reconstruction bundle, compact receipt, verification commands, architecture details, and reference diagram.

🔗 SLANG-ResetPassword on GitHub

The SLANG-ResetPassword reference implementation and verification artifacts are free to use, copy, modify, test, study, and redistribute without a license fee, subject to the repository LICENSE.

Architecture materials, documentation, specifications, diagrams, and explanatory content are subject to CC BY-NC 4.0 as stated in the LICENSE.

🌌 The Larger Question

Password recovery and credential replacement necessarily involve identity proofing, secure recovery channels, token or code validation, cryptography, authentication, authorization, credential mutation, session management, monitoring, and governance.

SLANG-ResetPassword does not attempt to remove those responsibilities.

It adds a narrower question:

Once declared credential-replacement authorization evidence exists, can its structural admissibility be resolved deterministically, refused explicitly when incomplete or contradictory, safely filtered for presentation, and preserved with inspectable evidence?

The principle is:

Declare the reset context. Admit only supported evidence. Require exact authorizer agreement. Resolve only what the profile justifies. Separate public presentation from private reconstruction. Keep operational authority outside the resolver.

✍️ Authorship and Disclaimer

Created by the authors of the Shunyaya Framework.

SLANG-ResetPassword is a bounded deterministic reference implementation for structural admission of declared credential-replacement authorization evidence.

It is not a password-reset engine, authentication system, identity-proofing system, token validator, credential store, credential-mutation authority, access-control mechanism, session authority, or identity provider.

Any operational or security-sensitive use requires independent implementation review, security assessment, privacy analysis, suitable recovery and identity-proofing controls, appropriate authorization, and suitable organizational governance.

OMP

Search This Blog

SHUNYAYA FRAMEWORK