Skip to main content
An agent can act for a business instead of a single person. It then presents a business credential. At L3 it also presents the credential of the person acting for the business, so you know both who the company is and who is behind this agent.

Business credentials at L2 and L3

A business L2 credential can be presented alone. At L3, the business and person credentials are presented and checked together. A business L3 credential presented alone is refused with ACTOR_MISMATCH. Pass the person’s credential to verify as actor.

How the pair is presented

Both credentials are presented under one nonce, signed by the same agent key. In a token exchange, the business credential arrives as subject_token and the person’s credential as actor_token. The two are checked as one unit. If either fails, the whole presentation is refused.

What you get

Python uses the same names, with to_token_claims() and actor_attests().

What the pair checks add

On top of the normal checks for each credential, the SDK checks:

Verify the pair

The KYA SDK is coming soon. The packages aren’t published yet, so the code below won’t run until they are.
Use verifier.verify(subjectToken, { actor: actorToken, scope }). Pass the person’s credential as actor when there is one, and the scope from your published profile, as in Asking for Fields. Passing the scope is what makes your site refuse credentials that share more than your profile lists.
oauthError and tokenResponse are the helpers from the SDK quickstart.

Checking what Baselayer verified

Each credential carries its own checks. claims.attests(key) is true when the business has the check. It says nothing about the person. claims.actorAttests(key) is true when the person has the check. For any rule that should cover both, such as a clear watchlist result, require both. If you check only attests(), a screened business lets through a person who was never screened.