Public-key verification is the process of checking that a digital signature was created by the holder of a particular private key and that the matching public key belongs to an accepted entity. In a signed request, this lets a receiving system check who sent the message, whether its contents changed, and whether the request is still valid.
For banks, payment providers and digital platforms, public-key verification helps establish trust between services, devices, browsers and software agents. It is one control in a larger decision process. A valid signature does not, by itself, prove that an agent is authorized to perform every requested action.
Public-key verification uses asymmetric cryptography, which assigns a related key pair to an entity. The private key creates a signature and must remain protected. The public key verifies that signature and can be shared through an approved trust process.
The verifier normally checks four connected questions:
The first two checks concern cryptographic integrity. The last two concern identity, context and authorization. Keeping those layers separate is essential for secure system design.
A signed request usually combines an HTTP method, target URI, selected headers and a request body or digest. The sender creates a deterministic representation of those components, signs it with the private key and sends the signature with key-identifying information.
The receiving service reconstructs the same representation. It locates the approved public key, checks the declared algorithm, verifies the signature and then applies request-level policy. HTTP Message Signatures defines a standard approach for signing and verifying components of an HTTP message, including requests that may pass through intermediaries.
A successful verification can show that the message matches the signed content and that the signer controlled the corresponding private key at the time of signing. Depending on the trust model, it can also connect the public key to a named organization, service, device or agent.
It does not automatically prove that the signer is a person, that the private key is still protected, or that the requested operation is permitted. Authorization requires additional controls such as scopes, transaction limits, audience checks, account relationships and risk rules.
| Check | Question answered | Typical control |
|---|---|---|
| Integrity | Did the signed content change? | Signature verification |
| Authenticity | Which key signed it? | Trusted key mapping |
| Freshness | Could this be an old message reused? | Timestamp and nonce |
| Authorization | May this agent perform this action? | Scope and policy checks |
| Intent | What exact transaction or instruction was approved? | Transaction signing and dynamic linking |
A trusted agent is a software component that acts for a user, institution or service. Examples include payment orchestration services, banking applications, automated support systems and AI-enabled transaction agents. The key question is not only whether the request was signed, but also what the agent was permitted to do.
Valid signature ≠ authorized action
A signed request must still meet identity, scope, transaction-limit and risk requirements before the action proceeds.
A robust trust model binds the key to an identified agent, an owner or sponsoring institution, an intended audience and a defined scope. It also records when the key was issued, how it can be rotated, and what happens when the agent is suspended or compromised.
For a high-value banking action, a receiving service may need to verify the agent signature, confirm the customer or institution relationship, check the transaction details, evaluate risk and request an additional approval. Transaction signing adds evidence that the approved content was tied to a specific financial instruction.
Public-key verification supports phishing-resistant authentication because the private key can remain on a trusted device or browser rather than being copied into a form. A verifier checks proof created by that key, while the private key stays protected by the device or its secure execution environment.
Entersekt’s Browser Authentication materials describe browser-based certificates, FIDO2 methods and device binding as controls for trusted web interactions. Its Silent Authentication approach uses endpoint identity and cryptographic keys to support low-interruption verification when risk conditions allow it.
In financial services, the signed object may be more important than the login event. A transaction signature can bind approval to an amount, beneficiary, account, payment instruction or other material detail. If those details change after signing, verification should fail or trigger a new approval.
Public-key verification is strongest when the cryptographic design and operating controls are treated as one system. The following practices reduce avoidable weaknesses:
NIST SP 800-89 describes assurance questions for digital signature applications, including public-key validity, private-key possession and the identity of the key-pair owner. These questions matter when a financial institution decides how much trust to place in a signed request.
Public-key verification is often confused with encryption. Encryption protects confidentiality by making information unreadable to unauthorized parties. Verification checks integrity and the claimed signer. A system may use both, but one does not replace the other.
Verification also differs from authentication and authorization. Verification checks cryptographic evidence. Authentication links that evidence to an entity or account. Authorization decides which actions that entity may take. Secure banking flows need all three decisions, plus risk analysis where the action or context warrants it.
A public key verifies signatures, while a private key creates them. The public key may be distributed through a trusted process, but the private key must remain protected. Anyone with the public key can test a signature, but only the private-key holder should be able to create a matching one.
No. A valid signature shows that the holder of the matching private key signed the relevant content. The receiving service must still check the agent’s identity, audience, scope, transaction limits, freshness and current risk before accepting the action.
Public-key verification helps prevent replay when the signed request includes freshness controls such as a nonce, timestamp, expiration or unique request identifier. The recipient must reject a signature that is valid cryptographically but outside its accepted time window or already used.
Public-key verification can bind an approval to the exact transaction data being approved. Entersekt connects cryptographic device and browser identity with transaction signing and risk-aware authentication to help financial institutions verify trusted interactions and protect high-risk actions.
Digital signature verification is a primary use of public-key verification. The broader process also includes checking the public key’s trust source, certificate or registry status, algorithm policy, message context, freshness and the signer’s authorization for the requested action.