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 withACTOR_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 assubject_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.
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.