import type { ReceiptStageOptionsV1, ReceiptStageResultV1 } from './stage.js';
import type { ReceiptSignatureV1, ReceiptSignerV1, ReceiptV1 } from './types.js';
export declare const RECEIPT_ID_TAG: 'APS-RECEIPT-ID-V1';
export declare const RECEIPT_SIG_TAG: 'APS-RECEIPT-SIG-V1';
/**
 * Exact UTC milliseconds, YYYY-MM-DDTHH:MM:SS.sssZ (draft line 986, with lines 198-199).
 *
 * Second 60 is accepted only at 23:59 on the last day of its month in the proleptic
 * Gregorian calendar, and rejected everywhere else. RFC 3339 section 5.7 admits time-second
 * 60 only for a leap second and Appendix D writes it as "YYYY-MM-DDT23:59:60Z"; the hour,
 * minute and day settle it, so no leap-second table is consulted and none is needed. The
 * same rule is applied on the section 4.1 surface (src/v2/action-reference/v2.ts) and on the
 * section 3 surface, and it stays local to each of them rather than changing a shared
 * helper that other record families also use.
 *
 * The second-60 branch is integer arithmetic because Date cannot represent a leap second.
 * Every other timestamp keeps the previous Date round-trip check unchanged, so the set of
 * accepted values grows by the conforming second-60 instants and by nothing else.
 */
export declare function isExactUtcMilliseconds(value: string): boolean;
/**
 * Order two values that isExactUtcMilliseconds has accepted: true when `later` is
 * strictly after `earlier`.
 *
 * The comparison is lexicographic on purpose. The accepted form is fixed width and
 * zero padded, YYYY-MM-DDTHH:MM:SS.sssZ, with the only letters at fixed positions, so
 * byte order is chronological order, and a leap second at :60 sorts after :59 in the
 * same minute, which is where it belongs. Date.parse cannot be used: it returns NaN
 * for a second-60 instant, so every comparison involving a conforming leap second
 * would silently answer false and reject a record the draft allows.
 */
export declare function isLaterUtcMillisecond(later: string, earlier: string): boolean;
export declare function receiptIdPayloadV1(receipt: ReceiptV1): string;
export declare function computeReceiptIdV1(receipt: ReceiptV1): string;
export declare function receiptSignaturePayloadV1(receipt: ReceiptV1, descriptor: Omit<ReceiptSignatureV1, 'value'>): string;
/**
 * This entrypoint validates the standalone ReceiptV1 structure and the fields available
 * within the receipt. It does not establish cross-document constraints involving the
 * referenced decision, including the requirement that decision valid_until be later than
 * receipt issued_at. Use verifyReceiptWithDecisionV1 when both artifacts are available.
 */
export declare function validateReceiptV1(receipt: ReceiptV1, requireValues?: boolean): void;
export declare function createReceiptV1(fields: Omit<ReceiptV1, 'receipt_id' | 'signatures'>, signers: ReceiptSignerV1[]): ReceiptV1;
/** Section 3.3 line 588 and section 5.6 lines 1225-1228: one of four states, and a caller
 *  MUST NOT collapse indeterminate or unsupported into valid. */
export type ReceiptVerificationStatusV1 = 'valid' | 'invalid' | 'indeterminate' | 'unsupported';
export interface ReceiptVerificationV1 {
    /** True only when status is valid. Kept so existing callers are unaffected. */
    valid: boolean;
    status: ReceiptVerificationStatusV1;
    /** `not_checked` where the record never reached the recomputation. Reporting false
     *  there said the identifier did not match when it was never computed. */
    receipt_id_valid: boolean | 'not_checked';
    /** The signer-authority axis of section 5.6 line 1223, kept apart from artifact
     *  integrity. `not_established` means a key could not be resolved or the resolver
     *  failed: section 2.4 line 322 and section 2.5 lines 360-369 make that a resolution
     *  outcome, and section 5.6 line 1226 makes missing live state indeterminate. It is not
     *  evidence that a signature is wrong. */
    signer_authority: 'verified' | 'not_established' | 'invalid' | 'not_checked';
    /** The section 5.3 stage result for this record's own receipt_type. Section 5.6 line
     *  1214 has a verifier enforce the closed envelope AND the type-specific schema, so a
     *  result that reports the draft's own state word has to include it. `not_checked` is
     *  reported only where the record never reached the stage layer, which is when the
     *  envelope itself failed or the artifact is under another profile. */
    stage: ReceiptStageResultV1 | 'not_checked';
    /** Every signature the record carries, required or not, with the outcome of its own
     *  key resolution. `required` marks the ones the aggregate state depends on. */
    signature_results: {
        signer: string;
        key_id: string;
        valid: boolean;
        required: boolean;
        reason?: string;
    }[];
    /** Signatures outside the required set, on their own axis. Draft line 1041 has a
     *  verifier verify every REQUIRED signature, and line 999 names one: the issuer's. A
     *  signature nobody required that does not verify says nothing about the record, and it
     *  must not move the aggregate state: signatures sit outside receipt_id by
     *  construction (lines 1003-1009), so anyone can append one to a published receipt
     *  without changing a digest, and letting that flip a conforming record to invalid
     *  puts the verification outcome in a third party's hands. */
    other_signatures: 'none' | 'all_verified' | 'not_all_verified';
    errors: string[];
}
/** Verifier input for the signature layer. */
export interface ReceiptSignatureRequirementsV1 {
    /** Signers the applicable profile or this verifier requires, beyond the issuer. A
     *  named signer that carries no descriptor at all is a missing required signature. */
    requiredSigners?: readonly string[];
}
/** The section 2.5 resolution outcomes a receipt key resolver may name, alongside the
 *  key itself. Draft lines 360-364 require a resolver to keep them apart; this SDK
 *  reported every one of them as the same answer. */
export interface KeyResolutionFailure {
    outcome: 'not_found' | 'ambiguous' | 'malformed' | 'unreachable' | 'unsupported_scheme';
}
/**
 * This entrypoint validates the standalone ReceiptV1 structure and the fields available
 * within the receipt. It does not establish cross-document constraints involving the
 * referenced decision, including the requirement that decision valid_until be later than
 * receipt issued_at. Use verifyReceiptWithDecisionV1 when both artifacts are available.
 *
 * This entrypoint operates on an already-parsed object and therefore cannot detect
 * duplicate members that may have existed in serialized JSON. For verification of
 * serialized artifacts, use the Serialized variant.
 */
export declare function verifyReceiptV1(receipt: ReceiptV1, resolveKey: (signer: string, keyId: string, issuedAt: string) => string | undefined | KeyResolutionFailure, stageOptions?: ReceiptStageOptionsV1, requirements?: ReceiptSignatureRequirementsV1): ReceiptVerificationV1;
/**
 * Verify a receipt from its serialized bytes.
 *
 * The chain is raw -> strict duplicate-rejecting parse -> the existing structural
 * validation -> the existing cryptographic verification. Every stage after the parse is
 * verifyReceiptV1 itself, called once and unchanged, so this adds a parser in front of
 * the existing path rather than a second implementation of it.
 *
 * WHY A SERIALIZED ENTRY POINT IS NEEDED AT ALL. Rejecting a duplicate object member is
 * a property of parsing. Once bytes have become an object the later member has already
 * overwritten the earlier one and the evidence is gone, so verifyReceiptV1, which
 * receives an object, cannot detect it however carefully it validates. Exposing only the
 * object-taking form would leave JSON.parse plus verifyReceiptV1 as the easy and
 * superficially legitimate composition, which is exactly the shape this is meant to
 * remove.
 *
 * Parse failure is reported as the error code `parse_error` followed by the parser's own
 * message, so it is distinguishable from a structural failure, which surfaces the
 * validator's message with no code, and from a signature failure, which surfaces
 * `signature_invalid`. That uses the existing free-form `errors` array of
 * ReceiptVerificationV1; no shared enum or result contract was widened to carry it.
 */
export declare function verifyReceiptV1Serialized(raw: string, resolveKey: (signer: string, keyId: string, issuedAt: string) => string | undefined | KeyResolutionFailure, stageOptions?: ReceiptStageOptionsV1, requirements?: ReceiptSignatureRequirementsV1): ReceiptVerificationV1;
//# sourceMappingURL=receipt.d.ts.map