authenticate- Module
- std.
lispex - Receiver
- Not applicable
- Minimum arity
- 3
- Maximum arity
- 3
Declaration and parameters
LinkAvailability
Included by default: no
Import std.lispex from an application package with a verified lock. Packages with [lispex] require --locked. Application profile topaz/ uses evaluator profile lispex/. Application profile topaz/ uses evaluator profile lispex/.
The generated-module resolver gate starts at language mode 5.18. Compatibility of this API with earlier released editions remains Pending. Target deployment conditions are native (native-only), web (web-isolated-workers), web- (web-isolated-workers). Runtime payload follows checker-reached rules. An empty reached-rule set includes no runtime payload. Application quotas are required. Lock-only packages do not receive these application modules.
Source evidence
- compiler/crates/topaz_lispex_product/src/lib.rs at
b48527d0a174· 202 - compiler/crates/topaz_lispex_product/src/lib.rs at
b48527d0a174· 202 - compiler/crates/topaz_resolve/src/lib.rs at
b48527d0a174· 801 - compiler/crates/topaz_cli/src/package/target.rs at
b48527d0a174· 71 - compiler/crates/topaz_value/src/lispex_application.rs at
b48527d0a174· 11 - compiler/crates/topaz_lispex_product/src/lib.rs at
b48527d0a174· 739 - compiler/crates/topaz_lispex_product/src/full_product.rs at
b48527d0a174· 44 - compiler/crates/topaz_lispex_product/src/lib.rs at
b48527d0a174· 634 - compiler/crates/topaz_lispex_product/src/lib.rs at
b48527d0a174· 496 - compiler/crates/topaz_lispex_product/src/full_product.rs at
b48527d0a174· 356
Receiver
Parameter constraints
authenticateEvidence accepts an admitted LispexConsumerArtifact, explicit LispexTrustPolicy and complete finite host limits. The key, issuer and algorithm arrays follow collection value semantics at call entry, before verification.
Each LispexTrustKey contains its key identifier, issuer, algorithm and immutable public key bytes. The policy lists the issuers and algorithms it accepts. Duplicate identifiers, malformed keys, unsupported algorithms and contradictory policy rows return Authentication with a structured report.
A valid envelope must bind the artifact and its request, canonical outcome, execution evidence and declared profile work as required by its versioned signing contract. Use a matching caller supplied key whose issuer and algorithm the policy allows.
An unsigned artifact, an unknown issuer, an untrusted key, a disallowed algorithm or an invalid signature returns Authentication. A lack of trust is not a language failure. Unsupported envelope contracts return Admission. Host budget exhaustion returns LimitExceeded.
Return LispexAuthentication with the authenticated artifact identity, issuer, key identifier and algorithm. The value records this policy decision. It does not say that the guest program is correct or that the caller may perform an external action.
No implicit system trust store, network key lookup, revocation request or live clock participates. If an application needs time or revocation policy, it evaluates explicit captured facts in a separate host decision. The signature contract and supported cryptography remain versioned upstream choices.
Authentication performs no guest evaluation and does not change request identity, canonical outcome or replay eligibility. The same artifact, trust data, algorithm contract and limits produce the same authentication decision unless the physical host fails.
Inspection establishes a structurally valid record. Authentication establishes the selected issuer binding. Replay compares the actual canonical outcome of the same request. A successful result from one operation does not imply success from either of the others.
Related rule: Authenticate evidence through explicit trustResult
The declared result type is Result<Lispex.
Effects
Failures
Result and effects
LinkAuthenticate the supplied evidence envelope under explicit host trust.
Why
LinkThe authentication contract gives this operation one explicit input boundary and preserves the distinct result and failure cases.
Related entries
LinkAuthenticate evidence through explicit trust
LinkAuthenticate evidence through explicit trust
authenticateEvidence accepts an admitted LispexConsumerArtifact, explicit LispexTrustPolicy and complete finite host limits. The key, issuer and algorithm arrays follow collection value semantics at call entry, before verification.
Each LispexTrustKey contains its key identifier, issuer, algorithm and immutable public key bytes. The policy lists the issuers and algorithms it accepts. Duplicate identifiers, malformed keys, unsupported algorithms and contradictory policy rows return Authentication with a structured report.
A valid envelope must bind the artifact and its request, canonical outcome, execution evidence and declared profile work as required by its versioned signing contract. Use a matching caller supplied key whose issuer and algorithm the policy allows.
An unsigned artifact, an unknown issuer, an untrusted key, a disallowed algorithm or an invalid signature returns Authentication. A lack of trust is not a language failure. Unsupported envelope contracts return Admission. Host budget exhaustion returns LimitExceeded.
Return LispexAuthentication with the authenticated artifact identity, issuer, key identifier and algorithm. The value records this policy decision. It does not say that the guest program is correct or that the caller may perform an external action.
No implicit system trust store, network key lookup, revocation request or live clock participates. If an application needs time or revocation policy, it evaluates explicit captured facts in a separate host decision. The signature contract and supported cryptography remain versioned upstream choices.
Authentication performs no guest evaluation and does not change request identity, canonical outcome or replay eligibility. The same artifact, trust data, algorithm contract and limits produce the same authentication decision unless the physical host fails.
Inspection establishes a structurally valid record. Authentication establishes the selected issuer binding. Replay compares the actual canonical outcome of the same request. A successful result from one operation does not imply success from either of the others.
Why
Trust in an issuer, structural validity and semantic reproducibility express different intentions. Explicit trust data prevents machine configuration from silently changing authentication and keeps authorization in the host application.
Source evidence
- docs/content-next/en/receipt-and-replay.json at
f455ac95ab30· 1 - docs/content-next/en/embedding.json at
f455ac95ab30· 1 - docs/content-next/en/resources.json at
f455ac95ab30· 1 -
topaz.stdlib.contract.lispex-authenticationatworking-tree
Authenticate a record with supplied verification keys
Linkimport std.bytes { Bytes }import std.lispex {LispexConsumerArtifact,LispexTrustPolicy,LispexHostLimits,LispexAuthentication,LispexEvidenceError,authenticateEvidence,}function authenticate(artifact: LispexConsumerArtifact, trust: LispexTrustPolicy, host: LispexHostLimits) -> Result<LispexAuthentication, LispexEvidenceError> {return authenticateEvidence(artifact, trust, host)}export function main(args: Array<string>, stdin: string) -> Result<int, string> {return Ok(0)}
No stdout.
Expected result
Expected result
Checking accepts the program. Exit code 0.
Use a verified Lispex application package supplied through TOPAZ_LISPEX_APPLICATION. This example specifies the Lispex 2.0 behavior. The product scope remains the public 5.21.3 observation scope.
Source evidence
- docs/content-next/en/receipt-and-replay.json at
f455ac95ab30· 1 - docs/content-next/en/embedding.json at
f455ac95ab30· 1 - docs/content-next/en/resources.json at
f455ac95ab30· 1 -
topaz.stdlib.contract.lispex-authenticationatworking-tree