# JWS Signature Checks and Their Limits

Quick answer: JWS signature verification runs locally and supports asymmetric signatures, using RFC 8785 canonical JSON with A2A field-presence rules. It never follows key URLs provided in the card, such as `jku` or `x5u`. A valid signature proves the standard fields against the supplied key, but it does not prove the key belongs to the claimed organization, and unsigned or unverified cards stay labeled.

## What the signature check does

The check confirms two concrete things: the message has not changed since it was signed, and it was signed by the holder of the key used to verify it. That is a real integrity and origin check, and it is performed locally rather than delegated to a remote service.

Canonicalization matters here, because the same JSON can be serialized in more than one byte form. The check follows RFC 8785 canonical JSON with the A2A field-presence rules, so a difference in encoding does not get mistaken for a tampered message.

Take a card that arrives with a signed set of skill fields. The check first reduces the JSON to its canonical bytes, then verifies those bytes against the key you supplied. If a single field changes after signing, the verification fails, even when the change is small and the document still parses. That catches a message altered in transit, and it does not depend on a person spotting the difference. The same check passes for a correctly signed message, but it still only speaks to the relationship between the bytes and the key. It does not inspect whether the skill claims are sensible, and it does not run the agent.

## Why card-provided key URLs are not followed

A card can name a URL that points to a key, and following it would let the card choose the key that verifies it. That undercuts the check, because an attacker who can write the card can also point to their own key.

The desktop therefore does not place trust in `jku` or `x5u` references.

| Element | Treatment |
|---|---|
| Asymmetric signatures | Supported |
| Canonical JSON | RFC 8785 with A2A field-presence rules |
| `jku` / `x5u` key URLs | Not followed, no trust |
| Verification location | Local |

## The exact claim a valid signature supports

A valid signature supports a narrow statement, and it is worth keeping that statement precise.

1. The standard fields are verified against the key you supplied.
2. The bytes match the canonical form that was signed.
3. The holder of that key signed the message.
4. The check does not establish that the key belongs to the named organization.

The identity question is separate. If the key itself came from an unverified source, a valid signature against it proves nothing about the organization printed on the card, and treating it otherwise over-extends the check.

## Unsigned and unverified cards

The desktop does not quietly promote a card that cannot be verified. Unsigned and unverified cards are labeled, and saving a snapshot does not save a trust decision. The label keeps the open question visible rather than hiding it behind a green-looking status.

This is the same boundary that keeps a static signal from being written as a guarantee. The signature is evidence for integrity and key possession, not a certificate of correctness or ownership.

Powerduck keeps the verification local and the limits explicit, so the signature is read for exactly what it proves.

## Frequently asked questions

**Does a valid signature prove the organization is real?** No. It proves the fields against the supplied key, not that the key belongs to the claimed organization.

**Why are jku and x5u URLs ignored?** Following a card-provided key URL lets the card choose the key that verifies it, which undercuts the check.

**What does RFC 8785 canonicalization do?** It settles the byte form of the JSON so an encoding difference is not mistaken for tampering, with the A2A field-presence rules applied.

## The bottom line

A JWS check is a strong but narrow control: it verifies integrity and key possession locally, with asymmetric signatures and RFC 8785 canonical JSON, and it never trusts card-provided key URLs. It does not prove the key belongs to the organization named on the card, and unsigned cards stay labeled. Read the signature as evidence for the fields, not as a full identity or correctness certificate. Continue in the [A2A guide](https://www.powerduck.com/blog/a2a-guide-hub/).