Does Your Identifier Work With Other Tools? Three Answers, One of Them No

"Does it interoperate" is three questions wearing one coat, and they have different answers. Taking them apart is most of the value here.

One: can another tool resolve your identifier? No, not the usual way

Most tooling in this space resolves identifiers through a standard aggregator that loads a small driver per method. No driver for our method exists.

We searched the whole repository for that vocabulary and the only matches are unrelated: marketing prose about traffic, and a prototype document listing a driving licence. Our own resolution function appears in nine files of the shared package, so the search finds resolution machinery when it is there. There is simply no driver to find.

So a third-party tool pointed at the standard aggregator gets nothing for our identifiers. A determined integrator can call our chain endpoint directly, and that works, and it is a bespoke integration rather than the plug-in path everybody else uses.

And there is a second cost once they do. Our endpoint and our package spell the same document differently: one emits snake-case field names with the key as hex, the other camel-case with the key as multibase. Same document, two renderings. An integrator comparing what the endpoint returns against what a standard library expects will find fields missing that are simply named differently.

Two: can another tool verify a credential we issued? Yes, in principle

The credential format we issue is one of the two the European framework accepts, and it is a published format with multiple independent implementations.

So a conformant library can verify one of ours using the issuer's public key, with no code of ours and no account. That is a real portability property and it is the strongest interoperability claim on this page.

In principle is doing some work, because obtaining the issuer's key still means resolving the issuer's identifier, which lands back on question one.

Three: can another tool receive a presentation from this wallet? No

This wallet cannot present at all. It holds a catalogue rather than credentials, and the share control produces an unsigned summary that says so in its own words.

So the question of whether some other verifier would accept our presentation does not arise yet. Nothing is being presented to anybody.

What the identifier document does not offer other tools

No encryption key. The key-agreement slot is empty, so there is nothing in the document to encrypt a message to, and any messaging protocol that expects one has nothing to work with.

No service endpoints. The service slot is empty, so nothing about you is discoverable from the document beyond the keys.

Both are absences rather than defects, and both bound what an outside tool can do with one of our identifiers even after it manages to resolve it.

The honest summary for an integrator

Verifying our credentials: straightforward, given the issuer key.

Resolving our identifiers: bespoke. Direct endpoint call, and mind the two spellings.

Receiving presentations: not applicable yet.