Interrogate the authority model before you rely on it.

WhoActs is the public brand for Mandate Rail: infrastructure for defining, issuing, presenting, checking and ending evidence of business authority.

It closes the gap between knowing who someone is and knowing whether they may perform a particular act for an organisation.

Identity answers who the actor is. Authority answers who appointed them, what they may do, on which resource, within which limits, through which channel and until when.

A digital mandate is a structured record of an appointment and its policy: principal, representative, actions, resources, limits, jurisdictions, dates, conditions, exclusions and evidence.

Not automatically. A WhoActs mandate is technical evidence. Legal effect depends on governing documents, applicable law and the transaction.

No. The principal organisation and its authorised governance process grant or approve authority. WhoActs records and makes that authority verifiable.

The issuer depends on the deployment and assurance model. The sandbox uses a local test issuer. A connected deployment requires an agreed provider and trust policy.

The appointed representative, its wallet, or an authorised agent service can hold the credential, depending on the workflow and security design.

A relying party verifies it before accepting an instruction or transaction, using its own trust and policy rules.

Not necessarily for every integration. Wallet presentation is one supported model; API-mediated and service-held presentations can also be designed around the use case.

Yes. The authority model can name a software agent and constrain its actions, resources, amounts, channels, expiry, approval requirements and delegation depth.

Yes. The implemented policy model supports amount, currency and resource constraints, including account or system identifiers.

Yes. A mandate can require a recorded human approval before the requested act is permitted.

Delegation can be allowed or prohibited and a maximum depth can be stated. The legal and operational acceptability of delegation still depends on the context.

The mandate moves to a revoked state. A verifier checking the current registered version should then reject an otherwise valid credential.

A verifier should reject it once the signed validity period has ended. Renewal should create a new, governed mandate version.

It is the ability to present only selected signed claims. The verifier must still receive every claim needed to evaluate the requested act.

The product models source provenance, evidence hashes, lifecycle events, audit records and verification receipts. Retention is configured for the deployment and legal context.

It can corroborate an entity record through configured authentic sources. That does not prove that a person may approve or accept a mandate for the entity.

Connected mode includes a live GLEIF lookup that re-resolves an LEI record and stores source time and response hash. GLEIF corroborates the entity, not the representative’s authority.

EUDI provides the EU framework for digital identity wallets. WhoActs is exploring the authority layer between organisational identity, credentials and relying-party policy decisions.

It is a proposed EU framework for interoperable business wallets. The proposal is still moving through the legislative process; WhoActs is not an official wallet.

No.

No. The product can integrate issuer and trust-service boundaries, but WhoActs is not currently a qualified trust service provider or qualified attestation provider.

No. Customers and relying parties must decide whether the authority is legally sufficient for the transaction and jurisdiction.

The architecture separates identity, repository and provider boundaries so an IAM integration can supply authenticated actors while WhoActs handles transaction-specific authority.

Yes, subject to an agreed protocol and assurance profile. A controlled trial has exercised issue, hold, present, verify and revoke operations with iGrant’s hosted trial environment.

Yes. The sandbox exposes an OpenAPI 3.1 contract and verification, mandate, credential and integration boundaries. Production use requires connected authentication and provider configuration.

No production hosting region is promised yet. Data location, sub-processors and transfer controls will be agreed before a connected design-partner deployment.

The public sandbox uses committed test material and is not suitable for reliance. Production requires protected, rotated signing material under an agreed KMS, HSM or provider custody model.

A no-key product sandbox exists. Access to the current design-partner environment is provided during a scoped demonstration and must not be treated as production.

We choose one principal, a small representative group, one narrowly defined action and a real relying party, then test issuance, verification, expiry or revocation, and review the evidence with legal and security stakeholders.

WhoActs offers paid, bounded design-partner pilots. Robert qualifies one authority workflow first, then issues a written scope and fee based on integrations, assurance and evidence requirements.

The sandbox implements SD-JWT selective-disclosure behaviour using RFC 9901 and exposes OpenID4VCI 1.0 and OpenID4VP 1.0-shaped demonstration boundaries. Those boundaries are not presented as certified conformance.

Email the address published on the security page with the subject ‘WhoActs security’. Do not include live credentials, secrets or personal data in the first message.