Skip to main content
An API key authenticates your organization. It is not the key that signs your evidence.

​
The two sets

A key can anchor, or anchor and verify. The console shows those two words; the scope names travel on the API and appear inside a refusal. They are listed here to be recognized, not to be picked from. A key you create carries one of those two sets and nothing else. Scopes are not selected individually. POST /api/v1/user/keys refuses any other combination, with its own message: “A key can anchor, or anchor and verify. Send scopes with exactly the three anchor scopes, or those three and the two verify scopes.” What each scope allows:

​
Why the three anchor scopes travel together

Each one is useless without the others, which is why they are one choice rather than three.
  • agent:enroll runs first. Both SDKs enroll the signing key before the first anchor, in the runtime, which is where the signing key is. A key that could write but not enroll would anchor nothing, because the plane refuses an envelope signed by a key it has no agent for.
  • anchor:read runs last. Building a hand-over pack reads your own records back, and bundle reports each pack it writes with the same key. Anchoring never touches the read routes, so a key that could write but not read would work for weeks and fail the first time you hand anything over.
The verify pair is separate because it is a different act: asking Sanning for a verdict, rather than producing evidence. An agent runtime never needs it. The console’s Create key dialog always shows the choice, disabled and with a sentence naming the address to ask, where an organization does not have verify access.

​
What the signing key does, and what it never leaves

The API key and the signing key are different things and the split is the security model. Sanning cannot produce a record that verifies as yours, because it has never held the key that signs one.