A valid signature still needs a trust decision

A valid signature leaves a question for the recipient

You receive a product illustration with a content credential. Its signature validates and its recorded content matches the file. That is useful, but your team still needs to decide whether it recognises the signing organisation. Combining those questions into one green badge makes the file look easier to accept by hiding the decision that remains.

Oprindo’s public signed JPEG sample shows that combination clearly. A local inspection with the Content Authenticity Initiative’s c2pa-python library, version 0.38.1, found successful asset-binding and signature checks while the signing credential remained untrusted under the chosen settings.[1][2] The top-level validation state said Valid. The detailed report was answering several questions; the interface needs to let the recipient see them.

Oprindo is Hamsa Software’s project for content credentials and provenance workflows. The local inspection gives its interface a concrete file to explain.

What belongs to these bytes?

The downloaded sample was a 61,310-byte JPEG. Its active manifest named Oprindo Release Validation as the generating software and recorded a created action with an AI-generated digital-source type. The signing information named Oprindo, with Hamsa Software LTD as issuer, and an 8 October timestamp. These are the statements the credential records about the file. Inspecting them does not independently establish how every pixel was produced.

C2PA checks different relationships around those statements. A hard binding ties the relevant asset content to the recorded claim. Signature validation checks the claim against its signing credential. Trust policy asks whether that credential is accepted.[3] A recipient can therefore have a matching binding and validated signature while still needing an answer about the signer. None of the three results needs to erase the others.

The successful checks in this report included assertion.dataHash.match and claimSignature.validated. The signingCredential.untrusted result concerned acceptance of the credential under this verifier’s policy. Timestamp digest validation also succeeded, while timestamp trust was unestablished. Certificate-status fetching, labelled OCSP in the settings, was disabled. The figure puts each ordinary-language question beside its exact result so the reader can connect the explanation to the machine report.

An image of a real event raises a further question about what happened in the world. This sample instead records an AI-generation claim. Its binding and signature make that recorded statement inspectable; they do not turn the illustration into a photograph of an event. An editor needs to carry the nature of the claim into the use they propose for the image.

Who accepts the signing credential?

The local reader enabled certificate-anchor verification and supplied no additional trust anchors. It disabled remote-manifest and OCSP fetching. Those choices belong with the result because another verifier can apply a different trust policy. The downloadable record retains them with the library version, file size and SHA-256 digest identifying the inspected bytes.

For an agency receiving this file, the next step is to identify the trust policy it means to use. Has that policy accepted this issuer, and is any required check missing? The local untrusted result leaves that question open. It does not accuse the signer of forgery. Equally, a validated signature is not a reason to add the signer to the accepted set simply to remove an inconvenient warning.

The SDK supports per-instance settings and explicit trust anchors.[2] A private arrangement might justify adding the sample certificate after an identity decision. Doing so changes the question the verifier asks. A subsequent trusted result would describe that chosen arrangement, rather than demonstrate acceptance under the earlier configuration. Record the reason for the anchor so the next reviewer can see which decision changed.

A production service needs a named trust policy with its relevant version or retrieval time. If a network check is disabled or unavailable, retain that fact beside the answer it limits. A trusted timestamp, a mathematically valid timestamp token and a current certificate-status check provide different information. The recipient needs to know which of those the service obtained before relying on a short status label.

Write the explanation before choosing the colour

Consider a small agency accepting product illustrations from several suppliers. Its client needs to know whether an image was generated, whether its credential still binds to the received file, and whether the signing organisation is recognised under the agency’s policy. Those are useful questions. A single “authentic” label is much less useful because each person can reasonably hear a different promise in it.

For the observed sample, a precise summary could say: “A content credential is present. The recorded AI-generation claim has a matching asset binding and a validated claim signature. This verifier did not establish the signer as trusted. Certificate-status fetching was not performed.” The detailed view can show the machine codes, configuration and asset identifier. The ordinary-language view should carry the same limits.

Now compare an image with no credential. Its appropriate explanation would concern missing inspectable provenance, not a failed signature and certainly not an accusation that the supplier is dishonest. An image with a mismatching asset binding presents a different issue again. Keeping those states distinct helps an operator decide whether to request the original file, examine a transformation or review the trust policy.

Ready for review, Needs original asset and Trust review required could help an agency operate a concise queue. Link each label to the codes and policy that produced it. The short state should point to the next work without turning a missing credential into a failed signature or treating a validated signature as acceptance of the signer. The display can be compact while its underlying distinctions remain available to the person who needs them.

The export is another asset

The downloaded JPEG is the file this inspection describes. A resized JPEG, WebP thumbnail, compressed social upload or image inside a PDF would be another output with its own bytes. The original report cannot establish what remains in each of them. Those export-path checks are proposed deployment work, rather than results from the local sample inspection.

To try the publishing path, retain an authorised original and inspect the actual file a recipient downloads after export. The reader can report a surviving embedded credential, a new credential describing the transformation or absent provenance. Where a supported workflow creates a signed ingredient relationship, inspect that relationship too. A visually unchanged illustration can have a different provenance state after its delivery path processes it.

The distinction affects the receiving agency’s explanation. A report attached to the original should not silently become the report for a thumbnail merely because the filenames resemble one another. Keep an asset identity and digest that resolve to the inspected file, then compare the exported result with that original. A missing relationship becomes a specific publishing-path investigation instead of a general suspicion about every signature.

A small agency might manage this by retaining the authorised original and its verification record. A higher-volume platform may need automated intake and a queue for missing checks. Either arrangement needs to follow the hand-off: which file arrived, which report describes it and what the recipient was actually told. The diagram traces the separate derivatives so that an original-file result does not get copied as an assumed result for all of them.

Do not make the evidence log into a second problem

The inspection record should be useful without collecting unrelated information. An internal asset identifier, digest, verification time, software version, policy reference and relevant status codes can often explain a decision without copying every client document into the log. Keep the original where its existing access and retention rules apply, and link the record through an identifier your team can resolve.

Oprindo’s public verifier describes uploading a file to its service.[4] That is a different deployment choice from the local library inspection used here. A team handling confidential client material needs to decide which path fits its obligations before using a convenient web form. A provenance result does not settle the permission to send the underlying file somewhere.

Provenance can contribute a specific result to the asset decision: these inspected bytes match a signed claim under the stated settings. That result alone cannot demonstrate legal compliance. Contractual rights, consent and intended use still require their own checks. Name those alongside the technical result where they matter to approval, so a matching hash contributes what it actually examined without standing in for the organisation’s wider obligations.

Leave the recipient a decision they can make

Before the agency records the signer as accepted, apply its chosen trust policy to the inspected JPEG. If that decision requires certificate-status fetching, obtain the missing check and keep its result with the same asset. The existing binding and signature checks remain useful while that work is unfinished. The review can now move to the issuer decision, instead of restarting verification or treating the top-level state as permission to finish.