Skip to content
Topaz6.0 · Before release
Download

Search documentation

Specification 6.0 · Not released · Tested product 5.21.3

Use arrow keys to choose a result. Press Enter to open.

Type an API name, diagnostic number, rule, or project topic.

    Library · std.lispex

    LispexTrustPolicy

    Select the accepted issuers, algorithms and keys without ambient trust.

    LispexTrustPolicy { keys: Array<LispexTrustKey>, issuers: Array<string>, algorithms: Array<string> }
    Receiver
    Not applicable
    Minimum arity
    0
    Maximum arity
    0

    Declaration and parameters

    Link

    Availability

    Included by default: no

    Import std.lispex from an application package with a verified lock. Packages with [lispex] require --locked. Application profile topaz/lispex-decision-application/1 uses evaluator profile lispex/r7rs-rule-embedded-core/1. Application profile topaz/lispex-decision-application/2 uses evaluator profile lispex/r7rs-rule-current-profile-bounded/1.

    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-worker (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

    Receiver

    Not applicable

    Parameter constraints

    Additional contracts are Pending.

    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 trust

    Result

    Pending

    Effects

    Pending

    Failures

    Pending

    Result and effects

    Link

    Select the accepted issuers, algorithms and keys without ambient trust.

    Why

    Link

    The authentication contract gives this operation one explicit input boundary and preserves the distinct result and failure cases.

    Related entries

    Link

    std.lispex

    Authenticate evidence through explicit trust

    Link
    Ruletopaz.stdlib.contract.lispex-authentication.rule

    Authenticate 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.

    Examples Authenticate a record with supplied verification keys

    Source evidence

    Authenticate a record with supplied verification keys

    Link

    check · checking · Verification: not-run

    main.tpzAuthenticate a record with supplied verification keysOpen in Playground
    1. import std.bytes { Bytes }
    2. import std.lispex {
    3. LispexConsumerArtifact,
    4. LispexTrustPolicy,
    5. LispexHostLimits,
    6. LispexAuthentication,
    7. LispexEvidenceError,
    8. authenticateEvidence,
    9. }
    11. function authenticate(artifact: LispexConsumerArtifact, trust: LispexTrustPolicy, host: LispexHostLimits) -> Result<LispexAuthentication, LispexEvidenceError> {
    12. return authenticateEvidence(artifact, trust, host)
    13. }
    15. export function main(args: Array<string>, stdin: string) -> Result<int, string> {
    16. return Ok(0)
    17. }
    Expected outputexit 0
    No stdout.
    $ topaz check main.tpz --locked --format json · target product 5.21.3
    Expected result

    Expected result

    Checking accepts the program. Exit code 0.

    No stderr.

    No stdout.

    This exact example has not been executed.

    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

    Menu

    Download