import type { AuthorityRevocationV1 } from '../authority-revocation/types.js';
import { type CorrectedRevocationView, type RevocationWithdrawalV0, type WithdrawalEvaluation, type WithdrawalStanding, type WithdrawalStandingResolver } from './types.js';
export declare function isWithdrawalStanding(value: unknown): value is WithdrawalStanding;
export interface RevocationWithdrawalInput {
    readonly revocation_id: string;
    readonly delegation_id: string;
    readonly withdrawn_by: string;
    readonly withdrawn_at: string;
    readonly reason_code: string;
    readonly detail?: string;
}
/**
 * Build a `RevocationWithdrawalV0`.
 *
 * A shape constructor and nothing more. It does not sign, does not canonicalize, and does
 * not compute an identifier, because minting the signed form of a record type is a
 * conformance-vocabulary decision reserved to the maintainer and this module is not making
 * it. `record_type` carries the `proposed:` namespace for the same reason.
 *
 * An absent `detail` is absent, never `null`: the key is not present at all, matching how
 * the revocation record treats its own optional detail.
 */
export declare function revocationWithdrawal(input: RevocationWithdrawalInput): RevocationWithdrawalV0;
/** A standing resolver that accepts a withdrawal only from the party the revocation itself
 *  names as revoker.
 *
 *  Supplied because it is the rule the forcing fixture chose and it needs to be runnable.
 *  IT IS A CHOICE, NOT A RULE READ FROM ANY TEXT. Draft-03 section 3.5 names the issuer as
 *  the party who may revoke; nothing in draft-03 or in the proposed text says who may
 *  withdraw a revocation, and the concept document's own `Lifecycle standing` entry says
 *  the party who may change an artifact "is not always the issuer". A deployment whose
 *  authority model gives a security function, a successor or a quorum standing to correct a
 *  publication error should pass its own resolver instead of this one. */
export declare const withdrawalSignerIsRevoker: WithdrawalStandingResolver;
/**
 * Decide whether one withdrawal record is accepted against a set of held revocations.
 *
 * Four questions, kept separate on purpose, each with its own code:
 *
 *  1. Is the record a well-formed withdrawal? `WITHDRAWAL_SCHEMA_INVALID`.
 *  2. Does it name a revocation the held set actually contains?
 *     `WITHDRAWAL_NAMES_NO_HELD_REVOCATION`.
 *  3. Does that revocation revoke the delegation this record names?
 *     `WITHDRAWAL_TARGET_MISMATCH`.
 *  4. May this party withdraw it? Asked of the injected resolver, never of the record.
 *     `WITHDRAWAL_SIGNER_WITHOUT_STANDING` when the resolver establishes they may not, and
 *     `WITHDRAWAL_STANDING_NOT_ESTABLISHED` when it cannot establish either way.
 *
 * The last split is the wording rule, executable: a standing question the verifier could
 * not answer is not established, and that is not the same finding as a party established to
 * lack standing. Both refuse the withdrawal, and a caller reporting the refusal has to be
 * able to say which one happened.
 *
 * AUTHENTICATION IS THE CALLER'S. This function never checks a signature, because a
 * withdrawal has no signed form in this SDK, on purpose; see `RevocationWithdrawalV0`.
 * Whoever calls it is the party asserting the record is genuine, exactly as whoever calls
 * `insertVerifiedRevocation` asserts the revocation was verified.
 *
 * NOTHING HERE REMOVES A REVOCATION, on any path. An accepted withdrawal is a record about
 * a record. The held set handed in is not mutated and no store is touched.
 */
export declare function evaluateRevocationWithdrawal(withdrawal: RevocationWithdrawalV0, heldRevocations: readonly AuthorityRevocationV1[], resolveStanding: WithdrawalStandingResolver): WithdrawalEvaluation;
/**
 * The current position of one revocation together with every withdrawal referencing it.
 *
 * This is the field that did not exist. A verifier that must report "revoked, and the
 * revoker later said this was recorded in error" had nowhere to put the second half, in
 * either reference SDK or in the proposed text, so it could only report the first half and
 * drop the rest.
 *
 * `revocation` is present and unchanged whether or not anything was accepted. Accepted
 * withdrawals are listed, refused ones are listed with their codes, and neither list makes
 * the revocation ineffective: a later finding is a new record that references the earlier
 * one and states its own effect, never an edit of it and never its removal.
 *
 * Withdrawals naming a different revocation are not silently dropped. They are evaluated,
 * refused `WITHDRAWAL_NAMES_NO_HELD_REVOCATION`, and appear in `refused`.
 */
export declare function correctedRevocationView(revocation: AuthorityRevocationV1, withdrawals: readonly RevocationWithdrawalV0[], resolveStanding: WithdrawalStandingResolver): CorrectedRevocationView;
//# sourceMappingURL=withdrawal.d.ts.map