Identity proves who an actor is. Authority proves which organisation appointed that actor, what they may do, under which limits, and whether that permission is current. Business wallets need both before a relying party can safely accept an instruction.

The gap after authentication

Strong authentication can establish who is at the keyboard or behind a wallet. It can bind a session to a person, service or device with high confidence. That is essential, but it does not establish which organisation appointed the actor or whether the proposed act sits inside that appointment.

A relying party still needs transaction-shaped answers: the action, resource, monetary limit, channel, jurisdiction, dates, approval conditions, exclusions and current status. A verified identity without those answers can make an ambiguous instruction look more trustworthy than it is.

Authority is narrower than a role

Job titles and directory roles are useful internal signals, but they are normally too broad for cross-organisational reliance. ‘Finance director’ does not say which bank account, payment rail, supplier class or daily limit applies. ‘External accountant’ does not say whether filing, payment or delegation is permitted.

Useful authority evidence binds a principal organisation to a representative and a defined act. It then carries the smallest set of constraints the verifier needs to decide on the request in front of it.

Why business wallets need an authority layer

The EU Digital Identity framework creates a common legal and technical direction for digital identity wallets and electronic attestations. A wallet can carry identity and attribute credentials, but a business interaction also needs evidence of the appointment between an organisation and the person or service acting for it.

That authority layer should be current, revocable and capable of selective disclosure. The holder should present only what the relying party needs, while the verifier checks that the disclosed claims are sufficient for its policy decision.

A mandate makes the appointment explicit

A structured mandate records who appointed whom, the acts that are allowed, the resources and limits in scope, the conditions that require additional approval, and the events that end the authority. Supporting documents can remain evidence without forcing every operational team to interpret them from scratch.

The mandate can then be issued as a signed credential, presented by the representative and checked against the relying party’s actual request. Suspension, revocation, renewal and supersession become explicit lifecycle events rather than emails that may be missed.

Verification must explain the decision

A green tick is not enough. A useful verification receipt shows which issuer and signature were checked, whether the credential was in time, whether its status remained valid, how the representative was bound to the principal, and which scope or limit produced the result.

This decomposition matters when an action is denied or requires approval. Operations teams need reason codes they can act on, while auditors need a record of the inputs and policy at that moment.

The relying party still owns acceptance

A valid credential is evidence, not an instruction to proceed. The relying party still chooses trusted issuers, defines its policy, checks contractual and regulatory requirements, and decides whether the authority is legally sufficient for the transaction.

The practical starting point is one narrow workflow with one principal, one representative class and one relying party. Model the decision, test expiry or revocation, and measure whether the new evidence removes a real interpretation step.

Important boundary

Technical verification is evidence. The relying party remains responsible for its trust policy, contractual controls and legal assessment.

Primary sources

Robert Prime

Founder of WhoActs. Robert is building WhoActs to make business authority inspectable before people and software agents act.

About Robert and WhoActs
All insights