How to Issue a Capability Credential, and What the Bundle in the Response Actually Is

What the route accepts

Two credential types through this path, an ownership binding and a capability scope, and a claims object that is untyped at the boundary and validated in the service against a schema for that type.

A rejection names the field and the reason, rather than returning a generic failure, which is a small thing that matters at three in the morning.

Ownership claims are derived, not accepted

If you ask for an ownership credential, your claims are ignored. The service builds them from what it knows: the agent's identifier, the operator's identifier, and the stored assurance level.

The code states the principle in one line, that an ownership binding says what the issuer attests rather than what the caller asserts, and that is the correct shape for the whole category.

The agent's identifier is forced server-side for both types, so a caller cannot issue a credential naming somebody else's agent.

One provenance caveat this estate has already measured: the assurance level being derived from stored state does not make it verified. It arrived from the operator's own earlier request, and the issuer's verdict is not carried in the credential at all.

Issuing a capability scope

You supply the scopes, or omit them and inherit the capabilities recorded when the agent was created.

Those strings answer to no vocabulary. Nothing anywhere defines an allowed set, so a verifier checking them is doing string equality against a convention that does not exist yet. Agree them out of band.

The bundle comes back once, and no other route returns it

The response carries a bundle: a signature, a public key, the encoded messages and a version. That is the material a holder needs to derive a presentation later.

The listing route does not return it. Its shape carries identifiers, timestamps and status references and no cryptographic material at all. If you discard the bundle, you re-issue.

The bundle is a bearer credential

Measured: there is no holder key binding anywhere in either package. No holder key, no confirmation claim, nothing that ties a presentation to a second secret the holder alone controls.

CONTROL: binding vocabulary matches seven times across the same paths, so the searcher works and the zero is an absence.

So possession of the bundle is sufficient to present the credential. Whoever holds it can derive a valid proof, and the verifier learns that a valid credential was presented rather than that its subject participated.

Treat it like a key, not like a receipt.

And the issuer keeps the signature

The stored credential document contains the proof, including the signature and the public key. The encoded messages follow from the claims and the version, both of which are stored beside it.

So the issuer retains everything needed to reconstruct the bundle.

This is a property, not an exploit, and the distinction is the honest part. No third party gains anything, and an issuer that wanted to assert something could simply issue another credential. What it does mean is narrower and worth stating: a presentation demonstrates possession of the bundle, and possession is not confined to the holder.

The artefact discloses its own limitations, which deserves saying

The proof type is Solidus-defined and the code says so, explicitly refusing to present it as conformance with a standard cryptosuite it has not been assessed against.

And when the chain cannot accept a credential type, the stored credential says so in its own text, carrying a plain sentence that it is unanchored, rather than leaving a null for somebody to misinterpret.

A document that carries its own caveat into every copy of itself is a better design than a caveat that lives only in a page like this one.

What the live card showed today

Fetched over the open internet, with no account: the documented agent's card returns its passport token and registry address, a render-time timestamp, and no credentials at all.

And its registry-status string still says the identifier method is under review and not yet registered. It is registered, merged into the registry in July, and the repository was corrected accordingly. The deployed build predates that correction, so the public document under-claims a shipped result.

Under-claiming reads as caution, which is exactly why nobody reports it. It has been filed.