Agents Acting for a Business

Overview

In B2B, an agent may act for a business through a particular person. A supplier portal or procurement system needs to know both: which business the agent represents and which person is acting for it. Verifying that the business exists doesn’t prove that the person may act on its behalf. For example, an agent for Harbor Concrete reorders parts from Acme Supply’s portal. Acme needs to know that the agent represents Harbor Concrete, which verified person is behind it, and that the person is verified to act for Harbor Concrete. Acme still decides whether to allow the reorder. Key challenges:

Identifying the business an agent represents
Identifying the person behind the agent
Confirming that the person is verified to act for the business
Evaluating the business and person separately when a rule applies to both

With KYA, the agent presents a business credential and the acting person’s credential.

Baselayer mints the two together and binds them to the same agent key.
It mints a business credential only when the operator link between the person and the business is VERIFIED.
The credentials establish identity and the relationship between the two.

The site still decides what the agent may do.

Role	Responsibility
Agent platform	Verifies the person and business, reviews their operator link if needed, and asks Baselayer to mint the credentials.
The site	Checks the credential presentation and decides what the agent may do.

How it works

The site’s checks in the last two steps use the KYA SDK, which is coming soon. That code won’t run until the packages are published.

Verify the person and the business together

The agent platform does one of these:

Uses a Hosted Enrollment journey that collects a business.
Sends a business verification to POST /issuance/identities/verifications with both the person and the business.

It includes the business’s tax ID (tin) so the link can verify on its own.The response includes an individual_ref, a business_ref and the link’s status. See Verifying an Identity.

Check the operator link

The link is VERIFIED when:

A tax ID was provided.
The IRS matched it to the business name.
The business was verified against its state registry.

If a check fell short, the link is UNDER_REVIEW and its shortfalls say which.

Review links that need a decision

The agent platform:

Lists links with status=UNDER_REVIEW.
Looks at the evidence.
Approves or rejects each one.

Decisions apply only to the agent platform’s organization. See Who Can Act for a Business.

Mint the business credential

The agent platform asks Baselayer to mint for the person and the business.The mint returns two credentials minted together: the business’s and the person’s.Each carries only the fields allowed by the site’s published scope.A mint for a link that isn’t VERIFIED is refused with error code 6300. See Minting Credentials.

The agent presents the pair

The agent signs both credentials with the same key and the same nonce. In the token exchange:

The business credential goes as subject_token.
The person’s goes as actor_token.

Verify the pair as one

The site calls verifier.verify(subjectToken, { actor: actorToken, scope }), with the scope from its published profile.If either credential fails, the whole presentation is refused. A business credential sent without its person is refused with ACTOR_MISMATCH. See Business Agents.

Check both the business and the person

Each credential carries its own checks.

claims.attests(key) asks about the business only.
claims.actorAttests(key) asks about the person only.

For any rule that should cover both, such as a clear watchlist result, require both.

If the site checks only attests(), a screened business lets through a person who was never screened.

The business and person carry separate verification results. A check that passed for the business didn’t necessarily pass for the person. When a rule applies to both, the site must check both results.

const report = await verifier.verify(subjectToken, { actor: actorToken, scope });
if (report.accepted) {
  const claims = report.exchangeClaims();
  // attests() asks the business, actorAttests() the person. Require both.
  const cleared =
    claims.attests("watchlist_clear") && claims.actorAttests("watchlist_clear");
}

report = await verifier.verify(subject_token, actor=actor_token, scope=scope)
if report.failure is None:
    claims = report.exchange_claims()
    # attests() asks the business, actor_attests() the person. Require both.
    cleared = claims.attests("watchlist_clear") and claims.actor_attests("watchlist_clear")

What each party sees

Party	What they see
Agent platform	The person and business references, the operator link status, and the credentials Baselayer mints.
The site	IDs, verification results, expiry and shared fields, listed below the table.
Agent	A one-time nonce, then the site’s token if the presentation is accepted.
Person	The verification flow when first enrolled. They don’t repeat it for every presentation.
Baselayer	The identity verifications and mint requests. The site checks credentials in its own code.

The site sees:

A site-specific ID for the business (claims.sub).
The acting person’s site-specific ID (claims.act.sub).
Separate verification results for each (claims.verification.active_keys and claims.act.verification.active_keys).
Their expiry.
Any shared fields.

Recommended settings

Setting	Recommendation
Tax ID	Include `tin` when verifying the business. When the IRS and registry match, the operator link verifies automatically. Without it, the link waits for review.
Preset	`b2b_ecommerce` shares the person’s name, email and phone, and the business’s name and basic registration details. See the note below the table.
Gating	For a rule that should cover both credentials, require `attests(key)` and `actorAttests(key)`. `attests()` alone checks only the business.
Officer match	Treat `officer_match` as supporting evidence in a review. It never verifies or holds a link on its own, because many states don’t list officers.
Rejection	Rejecting a link blocks new business credentials for that pair until the decision changes. It does not revoke credentials already minted; revoke those yourself.
Sandbox	Test with a sandbox key. Sandbox and production links are separate.

Preset

Use b2b_ecommerce only when those fields match what the site’s KYA profile asks for.
A mint applies no preset unless it names one.

See Presets.

Next steps

Verify the relationship: Who Can Act for a Business
Mint the credential pair: Minting Credentials
Check the pair at the site: Business Agents

GET STARTED

KEY CONCEPTS

PLAYBOOKS

PRODUCT GUIDES

INTEGRATIONS

Agents Acting for a Business

Overview

How it works

What each party sees

Recommended settings

Next steps

​Overview

​How it works

​What each party sees

​Recommended settings

​Next steps

Overview

How it works

What each party sees

Recommended settings

Next steps