The Signature Envelope Decides Who Can Verify You, and Ours Is Not the One in Our Own Examples
What our live issuer signs with is not what our documentation shows it signing with.
Two ways to attach a signature to a credential
One approach attaches a proof block to the document itself. The credential keeps its structure, and alongside it sits an object naming the suite used, the key that signed, the time, and the signature value. The document stays readable; the proof is a part of it you can inspect.
The other approach wraps the whole thing in a signed token. The credential becomes the payload of a compact, signed envelope. Header, payload, signature, one string.
These are not two syntaxes for one idea. Different canonicalisation, different suite names, different verification code, and a different set of libraries in every language.
Why a buyer should care about a plumbing detail
Because it decides who can check your credentials without your cooperation.
A verifier already running one family cannot verify the other by configuration. They add a library, or they do not verify you. That is a procurement conversation and an integration cost, not a preference.
And the suite name inside the proof matters as much as the family. Suites get versioned and renamed as specifications move. Material showing an older suite name is a signal about when it was written, and about whether anyone has checked it against what ships.
The general point, which outlives our particular gap
Documentation is written once and describes an intention. The wire is regenerated on every deploy and describes the product. When they disagree, the wire is right and the documentation is a record of what somebody meant at the time.
This is checkable in one request for any vendor in this category, which makes it one of the highest-value questions a non-specialist buyer can ask. You do not need to evaluate cryptography to notice that the examples and the endpoint disagree.
What to ask any vendor about signatures
"Which envelope does your live issuer use?" Then fetch the metadata and confirm it rather than accepting the answer. Ours says one thing and our documentation says another.
"Which suite, and which version of its name?" An older suite name in current material means nobody has checked it recently.
"What does a verifier have to install to check you?" If the answer is "nothing, it is standards-based", the question has been dodged.
"Has the signing code been independently reviewed?" For us: no, and for the selective-disclosure half specifically, the audit is targeted and unfunded.
Where this leaves a decision
If your verifiers are built for proof blocks, we do not emit them, and our documentation showing them is our defect rather than your option.
If your verifiers handle signed tokens, that is what runs today, you can confirm it in one request before speaking to anyone here, and being able to check the claim without the vendor in the room is the property to insist on from all of us.