Portable Means the Second Business Says Yes, and That Is Not a Cryptography Problem

This page is about the part of our own idea we have not solved.

What portability is usually sold as

A credential is issued once, held by the person it describes, and verified by anyone afterwards without contacting the issuer again. The signature travels with it. No integration between the issuer and the verifier is required, no shared session, no API relationship.

All of that is true, it is designed into the credential standards themselves, and it is the easy half.

The hard half, stated as a question

Why would a second business accept an identity check performed by a company it has never heard of?

Not "can it verify the signature". It can. The signature is valid, the format is standard, the maths works. The question is whether the second business is willing to take on the consequences of that check being wrong, having had no say in how it was performed and no relationship with whoever performed it.

That is a liability question and a trust question. Cryptography does not answer either one.

Why this is the part that has killed the idea before

Verify once, reuse everywhere is not a new idea. uPort, Civic, Sovrin, Evernym and ShoCard all built toward it, over a decade, with cryptography that largely worked. None of that generation made portable identity the default anywhere.

The failure was not technical. It was that the second verifier kept saying no, because saying yes meant accepting somebody else's work on their own regulatory exposure, and nobody could give them a reason strong enough.

Our bet is narrower than "we solved it". It is that the standards underneath are more mature than they were for that generation, which changes the cost of trying and does not by itself change the answer to the question above.

What we actually do not have

Any pitch that implies otherwise is asking a compliance officer to take a risk on our behalf.

We do not have an external audit. It is targeted and it is contingent on funding that has not been awarded.

We do not have a stranger-runnable end-to-end demonstration. The full cross-client call, a credential issued at one business and verified at another with no shared session between them, sits behind a client API key. You can watch the trust registry underneath refuse an unenrolled issuer without an account, and you cannot run the whole loop without one.

That refusal is checkable in one command:

curl https://capture-api.solidus.network/registry/issuers/did:example:test

It answers issuer not enrolled in this registry, which is a decision rather than a missing route. That distinction is the whole point of the mechanism, and it is also the limit of what we can show you for free.

Where reuse works today, and why that is the honest sequence

The place to start is wherever a business can accept a reused check on its own commercial judgement, without a regulator having to bless the decision.

Hotel and travel check-in, where the same passport is read repeatedly by parties who would rather not read it again. Age-gated purchases, where the requirement is a threshold rather than a dossier. SIM registration. Marketplace seller onboarding. In each of these the accepting business is weighing its own fraud loss against its own friction, which is a decision it is allowed to make in an afternoon.

Banking is the opposite case, and it is deliberately not first. Not because the technology is different but because the answer to "who is accountable if this check was wrong" has to come from somewhere we cannot yet supply.

What that means for the value on offer

If your onboarding cost is dominated by re-establishing identity for people who have already proved it elsewhere, and you are permitted to decide for yourself whether to accept that proof, portability is worth something to you today and the arithmetic is yours to run.

If you need somebody else to have certified the original check before you may rely on it, the missing piece is supervisory and not technical, and no vendor in this space can hand it to you right now regardless of what their material says.

What to ask anyone selling reusable identity

"Who bears the loss if the original check was wrong?" If the answer is a diagram, ask again. If the answer is a contract clause, read it. If the answer is the accepting business, that is honest and it is also the whole decision.

"Which of your verifiers accepted a credential they did not issue?" Reuse is only demonstrated at the second verifier. Everything before that is issuance with extra steps.

"What can I run without an account?" A vendor that can show you a component refusing something is showing you a mechanism. A vendor that can only show you a recorded demonstration is showing you a slide.

Where this leaves a decision

We think portability is the right bet and we are not going to pretend the unsolved part is small. The cryptography travels. The willingness to accept it does not, it is earned per relying party, and the first ones will accept it for commercial reasons rather than regulatory ones. If you are one of those, that is a conversation worth having now. If you are a bank, the honest answer is not yet, and the reason is written above rather than left for due diligence to find.