Skip to content

Site search

Type to search Pages

For credential and licence issuers

Publish a fact once, on liability terms you set.

Your team answers the same verification request over and over, with no clear liability framing. Signura lets your AI colleagues issue signed, revocable attestations — each carrying the scope, expiry and liability you approve.

What issuing on the exchange gives your team.

Scoped, bounded liability

Attach explicit liability terms and an expiry to each attestation type, so you stand behind a claim without accepting open-ended legal exposure.

Issuance by AI colleagues

AI colleagues issue signed attestations against verified source facts, within the policy your governor has approved — not on their own discretion.

Revocation that propagates

When an underlying fact changes, you revoke the attestation and the engine propagates the change to relying parties, so none continues to act on a claim you no longer stand behind.

One reusable published fact

Replace repeated bilateral requests to confirm licence validity, policy status or certification with a single signed attestation relying parties consume directly.

How a fact becomes an attestation

How your organisation issues and stands behind a claim.

Approve

Your governor decides which facts the organisation will attest to and the liability it is prepared to accept.

Issue

An AI colleague issues signed attestations against verified source facts, inside your approved policy.

Scope

Each attestation is written with explicit scope, expiry and liability terms before any relying party can depend on it.

Publish

The attestation is published to the exchange, where relying agents verify the proof at their point of decision.

Revoke

When an underlying fact no longer holds, you revoke the attestation and the change reaches relying parties promptly.

What you take on, and what you do not.

Liability you define, not liability you inherit

For most of your team's work, a verification request arrives with no statement of what you would be standing behind if you answered it. That is why issuing anything formal can feel like accepting exposure with no edges. Signura inverts the order.

Before a single relying party can depend on a fact, your governor decides which facts the organisation will attest to and the liability it is prepared to accept. Each attestation type then carries explicit, scoped liability terms and an expiry, written with their boundaries intact. You are not signing an open-ended promise; you are publishing a bounded one, on terms you set in advance.

Where the accountability sits

A fair objection is that a reliance layer merely moves liability around rather than removing it. Signura does not claim to remove it. What you stand behind stays exactly what you chose to attest to, within the scope you defined — the layer adds an accountable party where there was none, rather than reassigning one.

Signura does not become a relied-upon party beyond the integrity of the cryptographic proof and the accuracy of the freshness and revocation status it reports. A relying agent verifies your signed proof at the moment it acts and keeps it as evidence, and every reliance event is logged — so accountability rests with the party that signed the claim, which is you.

Why a reusable attestation beats a bilateral request

Today your team fields the same requests — licence validity, policy status, certification — again and again, per integration, producing no reusable output. When you publish a fact once as a signed attestation, relying parties consume it directly, and your staff stop confirming the same fact by hand.

On price, there is no established pattern for agent-to-agent reliance yet, so we are plain about it: issuance fees and attestation-management subscriptions cover the issuing side, reliance is metered per event on the relying side, and the specific scope, thresholds and limits are agreed with you per engagement rather than quoted from a rate card we cannot yet justify.

What issuers ask before publishing a fact.

Does issuing attestations expose us to open-ended liability?

No. Each attestation type carries explicit, scoped liability terms and an expiry that your governor sets before publication, so you stand behind a bounded claim on terms defined in advance rather than an open-ended one.

Doesn't a reliance layer just shift liability around?

It relocates nothing you did not choose. You decide what to attest to and what to stand behind; relying agents verify your signed proof and retain it as evidence; Signura stays neutral and does not become a relied-upon party beyond proof integrity and the accuracy of freshness and revocation status.

How is issuance priced?

Issuance fees and attestation-management subscriptions apply to the issuing side, and reliance is metered per event on the relying side. There is no fixed rate card yet for agent-to-agent reliance, so scope and limits are agreed with you per engagement.

What happens when a fact we attested to changes?

You revoke the attestation, and the freshness and revocation engine propagates the change to relying parties, so no agent continues to act on a claim you no longer stand behind.

Do our staff still answer each verification request by hand?

No. You publish the fact once as a signed attestation; relying parties consume it directly through the exchange instead of your team confirming the same fact per integration.

What standard are the attestations built on?

Attestations are signed and verifiable on the ratified W3C Verifiable Credentials 2.0 substrate, with a revocation mechanism, and — for EU adoption — aligned to the direction of eIDAS 2.0 electronic attestation of attributes.

Bring one fact your organisation is asked to confirm.

Tell us the fact you are repeatedly asked to verify, and we will show how it becomes a signed attestation with scope, expiry and liability you set.

Tell us which facts you're asked to confirm.

Describe the facts relying parties keep asking your team to verify. A person reads every message and replies.