Skip to content

Site search

Type to search Pages

For IAM integration owners

Stop bolting agent credentials onto OAuth and OpenID Connect for every counterparty.

You keep extending OAuth 2.0 and OpenID Connect with agent-specific credentials and wiring an external IdP per integration. Signura adds a reliance layer above those primitives, so your agents verify one signed attestation instead.

Start a conversationSee how it works

What sits above your identity stack.

Above your identity primitives

Signura sits above the OAuth 2.0, OpenID Connect and identity-provider layers you already run — it adds transferable reliance on top rather than replacing them.

One API, not bespoke plumbing

Relying agents query the exchange and verify a signed proof through a single integration, instead of new identity plumbing built afresh for every counterparty.

Built on W3C Verifiable Credentials 2.0

Attestations land on the ratified W3C Verifiable Credentials 2.0 substrate with a revocation mechanism, so you build on a standard rather than a single proprietary protocol.

Aligned with eIDAS 2.0 direction

For EU adoption, attestations align to eIDAS 2.0 electronic attestation of attributes, tracking the statutory direction rather than a private scheme.

How it integrates

How reliance drops into your identity architecture.

The same path each relying agent follows, from a single integration to retained evidence.

Integrate the reliance API once

Wire the reliance and verification API into your agent stack a single time; it works above the identity primitives you already operate rather than duplicating them.

Query a counterparty claim

When your agent needs to act on a counterparty's licence, policy or permission, it queries the exchange for the attestation instead of re-authenticating the party from scratch.

Verify the proof at decision time

Your agent verifies the cryptographic proof, checks its freshness and revocation status, and confirms scope before it acts.

Proceed within limits or escalate

Inside the governor's configured scope, value thresholds and expiry the agent proceeds; anything outside those bounds routes to a human.

Retain the evidence

Every reliance event is logged in a tamper-evident ledger, so what was relied upon, and when, is inspectable long after the decision.

Why this is a layer, not another integration.

A layer above, not another silo

If you own identity and access integration, your instinct on hearing about a reliance layer is a fair one: another dependency, another thing to wire, another root of trust to reason about. Signura is designed to reduce that surface, not enlarge it. It sits above the identity and credentialing primitives you already operate — the OAuth 2.0 flows, the OpenID Connect providers, the external identity providers you attach per integration — and beneath the application logic where your agents commit to actions.

It does not replace those primitives. It works above the identities they establish and adds the one thing they do not provide: a way for your agent to rely on a fact another organisation has already verified, with a named party standing behind it.

The cost you are already paying

The plumbing you maintain today is per-integration by nature. Each new counterparty means extending your credential handling and deferring authorization to yet another identity provider. That work does not compound — every integration is bespoke and leaves nothing reusable for the next one.

Reliance through a single exchange inverts that. Your agent integrates the reliance and verification API once, then reaches any admitted issuer's attestation through the same path. The checking work has already been done and signed for by the issuer, so your agent verifies a proof rather than re-investigating the claim from source each time it acts.

The protocol question, answered plainly

The honest objection is that the inter-agent protocols are unsettled, and a winning one might build transferable reliance and revocation in natively. Signura's answer is not a proprietary protocol you would be locked into. Attestations land on the ratified W3C Verifiable Credentials 2.0 substrate, carry a revocation mechanism, and align to the direction of eIDAS 2.0 for EU adoption.

What Signura adds on top of the standard is the neutral position between issuers and relying agents, the freshness and revocation status a relying agent checks at decision time, and the accumulating record of reliance events your governors can audit. Those hold their value whichever transport protocol prevails, because they are about who stands behind a claim and what was relied upon — not about the wire format.

Integration questions

What integration owners ask before wiring it in.

Will adopting this lock my stack to one vendor's scheme?

No. Signura is built on the ratified W3C Verifiable Credentials 2.0 standard and sits above whatever identity substrate you run, so adopting it does not tie you to a proprietary scheme or a particular inter-agent transport.

Does this replace our OAuth 2.0, OpenID Connect and IdP setup?

No. Signura sits above those primitives. They continue to establish identity; Signura adds transferable reliance on top — the ability for your agent to depend on a claim another organisation has already verified, without re-verifying it.

What if a winning protocol builds reliance and revocation in natively?

Signura is not a proprietary protocol you would be stranded on. It stands on the W3C Verifiable Credentials 2.0 standard and aligns to the direction of eIDAS 2.0. Its defensibility is the neutral position between issuers and relying agents, the freshness and revocation status checked at decision time, and the accumulating reliance record — not a private transport.

How much does adding this dependency cost my integration budget?

Reliance is metered per event and priced below a fresh from-source verification, and your agents integrate the API once rather than per counterparty. Scope, thresholds and limits are agreed per engagement, so the cost is tied to reliance work done rather than seats or connectors.

What happens when a reliance falls outside its configured limits?

The governor sets admissible issuers, attestation types, value thresholds and expiry. Within those the agent proceeds; anything ambiguous or high-risk, or outside scope, is routed to a human rather than committed on agent discretion.

Bring one counterparty claim you keep re-plumbing.

Tell us the integration your agents rebuild for every counterparty, and we will walk through how reliance would sit above it.

Start a conversation

Get in touch

Tell us what your agents integrate against.

Describe the identity plumbing your agents rebuild per counterparty. A person reads every message and replies.