🔐 SLANG-Password

🔎 What If You Could Check the Evidence Behind a Password Result — Without Rechecking the Password?

A bounded approach to checking whether declared password-verification evidence is complete, consistent, and correctly bound.

🔐 SLANG-Password

Password-related systems often combine several very different questions:

What password-verification result did an external component declare?

Which declared verifier or verifiers supplied the evidence?

Was the evidence correctly bound to the declared subject, credential, request, relying party, and challenge?

Do multiple declared verifiers agree?

Is the evidence complete?

Is the result allowed to be shown?

Can the result later be reconstructed and checked?

SLANG-Password separates the external password-comparison process from the structural admission of the resulting declared evidence. It does not establish whether the comparison actually occurred or whether the external verifier was trustworthy.

Raw passwords are not supported inputs. SLANG-Password does not compare passwords or derive a result from password material.

An existing security component may perform a password comparison and produce declared verifier evidence. SLANG-Password then evaluates whether that evidence is structurally admissible under a declared authentication context, verifier set, evidence mode, profile, and ruleset.

Its central contract is:

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

The idea is deliberately narrow.

SLANG-Password does not authenticate users, grant access, create sessions, issue tokens, change credentials, or replace established security systems.

It asks a smaller structural question:

Given declared password-verification evidence, what bounded admission state follows?

🌐 Explore SLANG-Password on GitHub

🔑 Password Verification Happens Outside the Resolver

SLANG-Password begins after an external password-verification component has produced a declared result.

The supported evidence result is one of:

MATCH

NO_MATCH

The resolver does not infer that result from:

  • a password
  • a username
  • a password hash
  • password length
  • retry history
  • a login sequence
  • a session
  • a token

The distinction is:

declared password-verification evidence != password comparison

A MATCH declaration means that an external component declared a match.

It does not prove that the component was trustworthy or that the comparison actually occurred.

🧩 What Does the Resolver Check?

SLANG-Password evaluates questions such as:

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

A simplified flow is:

submitted input -> admission -> normalization -> context binding -> verifier 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 a verification outcome under the current profile.

🚦 A Result Is Not Forced

Consider a few examples.

If an expected verifier record is missing:

missing expected evidence -> INCOMPLETE

If evidence refers to a different subject, credential, request, relying party, or challenge:

context-binding mismatch -> CONFLICT

If two declared verifiers disagree:

MATCH + NO_MATCH -> CONFLICT

If the caller includes a raw password or password hash:

raw secret field -> 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.

✅ MATCH and NO_MATCH Are Both Resolved Outcomes

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

The current mapping is:

RESOLVED + MATCH -> verification_outcome = MATCH; admission_state = ADMIT

RESOLVED + NO_MATCH -> verification_outcome = NO_MATCH; admission_state = DENY

For every non-result state:

verification_outcome = NONE

admission_state = WITHHOLD

These values remain bounded structural statements.

ADMIT != authenticated

DENY != account lockout

Neither value grants or denies operational access by itself.

🔗 Evidence Must Match the Declared Context

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

  • subject
  • credential
  • credential version
  • request
  • relying party
  • challenge
  • expected verifier set
  • evidence mode

Conceptually:

evidence context = declared evaluation context

A mismatch produces CONFLICT.

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

But context binding has a limited meaning:

context binding != identity ownership

It does not prove who owns the account or whether the external verifier was authentic.

👥 Single-Verifier and Multi-Verifier Modes

The current reference supports two evidence modes.

SINGLE_VERIFIER

The context declares exactly one verifier, and exactly one matching evidence record must be supplied.

MULTI_VERIFIER_EXACT_AGREEMENT

The context declares between two and eight verifiers.

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

Conceptually:

all admitted verifier outcomes agree -> continue

any admitted verifier disagreement -> CONFLICT

This is not:

  • majority voting
  • quorum selection
  • weighted agreement
  • first-arrival selection
  • automatic reconciliation

A MATCH declaration cannot outvote a NO_MATCH declaration.

🖼️ SLANG-Password Reference Diagram

Figure: SLANG-Password separates external password comparison, declared verifier evidence, authentication-context binding, deterministic structural admission, visibility handling, reconstruction bundles, and compact receipts.

🔒 Raw Secrets Are Outside the Supported Input

SLANG-Password rejects recognized fields associated with raw secret material or caller-supplied authority conclusions.

Examples include:

  • password
  • raw_password
  • current_password
  • password_hash
  • salt
  • pepper
  • private_key
  • session_token
  • access_token
  • authenticated
  • access
  • verification_outcome
  • admission_state

The forbidden-field scan is recursive.

Recognized forbidden values are replaced with:

<FORBIDDEN_VALUE_REDACTED>

before reconstruction evidence is 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 or unknown field may still be retained in a reconstruction bundle.

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

👁️ Resolution and Visibility Are Different

SLANG-Password separates structural resolution from presentation.

For a resolved result:

reference_visibility_authorized = true -> VISIBLE

reference_visibility_authorized = false -> WITHHELD

When the outcome is withheld, the public summary removes the principal outcome fields:

verification_outcome = null

admission_state = null

outcome_fields_redacted = true

This is a presentation boundary.

Under v0.1.0, the public summary may still retain stable reason codes and deterministic result and bundle identities. It must not be treated as encryption, access control, cryptographic confidentiality, or proof that the withheld outcome cannot be inferred or correlated.

The reconstruction bundle and compact receipt may retain additional outcome-bearing and context-bearing material for verification and should be treated as potentially sensitive artifacts.

The practical distinction is:

principal outcome fields may be withheld from the public summary while the complete bounded result remains available in private verification artifacts

And:

public-summary redaction != cryptographic confidentiality

🧾 Bundles and Receipts

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 and result from the preserved submitted input and requires exact canonical agreement.

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

Receipt verification checks receipt integrity.

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

The broader principle is:

A resolver should preserve enough declared evidence to explain and reproduce what it resolved.

Bundles and receipts may contain sensitive or correlatable information. They are verification artifacts, not authentication credentials or access tokens.

🧠 Deterministic Identity Is Not Real-World Truth

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

  • submitted input
  • canonical input
  • authentication context
  • verifier manifest
  • evidence set
  • evidence-agreement material
  • rule profile
  • bounded outcome
  • result
  • bundle
  • receipt

The general form is:

identity = prefix + sha256(canonical_json(preimage))

These identities support deterministic comparison and reconstruction.

They do not prove:

  • verifier authenticity
  • account ownership
  • password correctness
  • legal authority
  • operational authorization
  • real-world truth

Important distinctions include:

evidence commitment syntax != source authenticity

deterministic reconstruction != successful authentication

receipt verification != access authority

⚖️ What Does SLANG-Password Not Provide?

SLANG-Password does not replace:

  • password hashing and comparison
  • credential storage
  • salts, peppers, and key management
  • authentication protocols
  • MFA
  • retry and lockout controls
  • abuse detection
  • risk evaluation
  • session creation
  • authorization policy
  • access enforcement
  • identity governance
  • secure transport or storage
  • operational monitoring

A possible surrounding relation is:

protected_action_allowed = security_checks_pass AND structural_evidence_admitted AND authorization_allows

SLANG-Password resolves only:

structural_evidence_admitted

🧪 Current Reference Status

The current reference is SLANG-Password v0.1.0.

Published verification results include:

  • permanent reference audit: 299/299 PASS
  • semantic vectors: 86/86 reproduced
  • presentation vectors: 5/5 reproduced
  • parser vectors: 13/13 reproduced
  • artifact vectors: 10/10 reproduced
  • reference evidence: 3/3 reproduced
  • serialization bytes: 3/3 reproduced
  • metamorphic relations: 12/12 reproduced
  • frozen-vector verification: PASS
  • canonical bundle verification: PASS
  • canonical receipt verification: PASS
  • receipt-to-bundle verification: 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
  • verification and 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 or production certification.

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

SLANG-Password demonstrates:

  • strict structural input admission
  • context-bound password-verification evidence
  • exact verifier-set checking
  • exact multi-verifier agreement
  • explicit non-result states
  • deterministic state resolution
  • bounded order independence
  • visibility-aware presentation
  • deterministic structural identities
  • reconstruction bundles
  • compact receipts
  • frozen conformance vectors
  • reproducible reference artifacts

It does not provide:

  • password comparison
  • authentication
  • authorization
  • access control
  • session creation
  • credential storage
  • password reset
  • MFA
  • source authentication
  • production security
  • legal or institutional authority

Its claim is narrower:

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

🌐 Explore SLANG-Password

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

🔗 SLANG-Password on GitHub

The SLANG-Password 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 systems necessarily involve secrets, secure comparison, cryptography, authentication, authorization, sessions, enforcement, monitoring, and governance.

SLANG-Password does not attempt to remove those responsibilities.

It adds a narrower question:

Once declared password-verification evidence exists, can its structural admissibility be resolved deterministically, refused explicitly when incomplete or contradictory, and preserved with inspectable evidence?

The principle is:

Declare the context. Admit only supported evidence. Resolve only what the profile justifies. Preserve explicit non-result states. Keep operational authority outside the resolver.

✍️ Authorship and Disclaimer

Created by the authors of the Shunyaya Framework.

SLANG-Password is a bounded deterministic reference implementation for structural admission of declared password-verification evidence.

It is not a password verifier, authentication system, access-control system, session authority, identity provider, credential store, or password-reset system.

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

OMP