One Identity Primitive for Humans, Agents and Machines: True of the Identifier, Not of the Credential

The claim, and why it is worth testing rather than repeating

One identity primitive that works for a person, for an agent and for a machine is the sentence this company organises itself around.

It is a claim about our own code, which makes it checkable, so this page checks it instead of restating it.

What genuinely is one primitive

Every backend examined depends on the same software kit and the same shared type package. That is where the identifier method lives, and it is the same method for a person and for an agent: the same scheme, the same resolution call, the same document shape.

So an identifier issued to an agent and an identifier issued to a person are the same kind of object, differing in what they point at rather than in what they are.

That is the load-bearing half of the thesis and it holds.

What is not one primitive

The credential format differs. The selective-disclosure package is a dependency of the agents backend and of the verification backend, and it is not a dependency of the identity backend at all.

And elsewhere the shared kit carries a different credential format again, a token-based one which does not appear on this surface.

What this surface emits is a Solidus-defined envelope whose own proof type declines to claim conformance with a standard cryptosuite.

So: one identifier, more than one credential. Anyone who read the thesis as "one format everywhere" was reading more than the code supports.

What was not tested, said plainly

No cross-surface verification was attempted here. This page reports what the dependency manifests say, not the result of handing an agent credential to a verifier built for a different format.

The dependency fact is enough to say the formats differ. It is not enough to say what happens if you try, and inventing that result would be exactly the kind of claim this estate refuses.

Why the split may be correct rather than drift

A relying ecosystem chooses the credential format, and the choices differ. A European wallet context wants formats defined there; a chain context wants something compact and selectively disclosable; a login context wants a token.

Forcing one format across all of them would make each worse, and the honest version of the thesis is that the identifier is the thing that must be shared and the credential is the thing that must adapt.

The cost of that is real and should not be smoothed over: every additional format is another verifier to write, another conformance question, and another place a claim can be right in one encoding and absent in another.

What this means for somebody building on it

Rely on the identifier being portable across our surfaces. That is the part the code supports.

Do not assume a credential issued on one surface verifies on another. Check the format you are receiving, and treat "same company" as no evidence at all about interoperability.

And note that the portability of the identifier is itself architectural rather than operational, because no resolver driver exists for the method, so third-party tooling resolves nothing today regardless of surface.