Sandbox trust onboarding blocked — likely related to #143 (checksum mismatch in didtoolbox 2.3.0)

[ajnurademi]

Summary

While following the Sandbox onboarding cookbook (onboarding-base-and-trust-registry), I was unable to
complete step 5.1 ("Fetch the Challenge") of the trust onboarding process. I suspect this is a
downstream effect of #143.

Steps to reproduce

1. Registered a business partner in the swiyu Service Portal, subscribed to all three APIs
   (identifier, status, trust), reserved a DID space.

2. Ran didtoolbox-2.3.0.jar create to generate the DID log — hit the exact checksum mismatch
   crash described in didtoolbox-java 2.3.0 checksum mismatch #143:

   Exception in thread "main" java.lang.ExceptionInInitializerError
           at ch.admin.eid.did_sidekicks.Did_sidekicksKt.uniffiEnsureInitialized(did_sidekicks.kt:1349)
           at ch.admin.eid.didresolver.UniffiLib.<clinit>(did.kt:679)
           at ch.admin.eid.didresolver.Did.<init>(did.kt:1274)
           at ch.admin.bj.swiyu.didtoolbox.model.WebVerifiableHistoryDidLogMetaPeeker.peek(WebVerifiableHistoryDidLogMetaPeeker.java:124)
           at ch.admin.bj.swiyu.didtoolbox.webvh.WebVerifiableHistoryCreator.createDidLog(WebVerifiableHistoryCreator.java:577)
           at ch.admin.bj.swiyu.didtoolbox.webvh.WebVerifiableHistoryCreator.createDidLog(WebVerifiableHistoryCreator.java:499)
           at ch.admin.bj.swiyu.didtoolbox.context.DidLogCreatorContext.create(DidLogCreatorContext.java:412)
           at ch.admin.bj.swiyu.didtoolbox.context.DidLogCreatorContext.create(DidLogCreatorContext.java:393)
           at ch.admin.bj.swiyu.didtoolbox.JCommanderRunner.runCreateDidLogCommand(JCommanderRunner.java:134)
           at ch.admin.bj.swiyu.didtoolbox.Main.run(Main.java:88)
           at ch.admin.bj.swiyu.didtoolbox.Main.main(Main.java:20)
   Caused by: java.lang.RuntimeException: UniFFI API checksum mismatch: try cleaning and rebuilding your project
           at ch.admin.eid.did_sidekicks.Did_sidekicksKt.uniffiCheckApiChecksums(did_sidekicks.kt:1131)
           at ch.admin.eid.did_sidekicks.Did_sidekicksKt.access$uniffiCheckApiChecksums(did_sidekicks.kt:1)
           at ch.admin.eid.did_sidekicks.IntegrityCheckingUniffiLib.<clinit>(did_sidekicks.kt:659)
           ... 11 more
   

3. As a workaround, used an older didtoolbox release to generate and upload the DID log.
   Upload succeeded (200 OK), and the DID shows status "Active" in the Service Portal.

4. Proceeded to step 5.1: GET /api/v1/trust/trust-onboarding-submission/proof-of-possessions
   on the trust-reg-api. Received:

   {"errorCode":"resource_not_found","message":"No UNSUBMITTED TrustOnboardingSubmission found for partner and therefore no submission of proof of possessions is possible","additionalDetails":[]}

Additional testing

• Repeated the entire flow from scratch with a brand-new business partner and a brand-new DID —
  same result.
• Could not find any explicit "start trust onboarding" button/step in the Service Portal; the
  cookbook only says this should happen "in the swiyu Service Portal" without pointing to a
  specific action.
• Verified access tokens are correctly scoped for the trust API (no auth errors on the request,
  only the "resource_not_found" business error).

Hypothesis

The release announcement for the new Sandbox onboarding flow states: "new DID's must be created
with the new standard (and new toolbox version)." Since didtoolbox 2.3.0 — the version
implementing this new standard — is currently broken (#143), I could only generate a DID with an
older toolbox version. It's possible the trust registry silently declines to create an onboarding
submission for DIDs that don't meet the new standard, without surfacing a clear error at DID
upload time.

Question

Could someone confirm whether trust onboarding requires a DID created with a specific toolbox
version, and/or whether there's a way to manually trigger the trust onboarding submission that
I might have missed in the Service Portal?

This effectively blocks Sandbox onboarding end-to-end until #143 is resolved, since there's
currently no working path to produce a DID that satisfies both the checksum-mismatch-free
toolbox requirement and whatever the trust registry expects.

[andre-kunz]

Hi Ajnur

The DID Toolbox versions 2.1.0 and 2.2.1 both support the new standard (see compatibility matrix). With which older version did you try the onboarding?

If this doesn't help, I try to get some support from our developers.

Best regards, André

[ajnurademi]

Hi André,

Thanks for the quick reply.

To answer your question: I used didtoolbox-java 2.2.1
(https://github.com/swiyu-admin-ch/didtoolbox-java/releases/tag/2.2.1).

One clarification on the toolbox side: 2.2.1 worked fine on Windows. When I later tried
2.3.0 (to test with Ed25519), it consistently crashed with the checksum mismatch on Windows,
but ran successfully on Ubuntu (WSL) with the exact same JAR — so that crash looks
platform-specific (likely related to mozilla/uniffi-rs#2939, which someone else pointed out on
#143). Not the focus of this issue, just flagging it as context in case it's useful.

The actual problem I still can't get past is step 5 of the onboarding cookbook ("Create
Proof of Possession for initial did" — onboarding-base-and-trust-registry#5). No matter which
toolbox version I use to generate the DID, I cannot complete the Proof of Possession:

1. DID generated (with 2.2.1), uploaded via PUT /identifier-entries/{id} → 200 OK, status
   "Active" in the Service Portal, resolves correctly.
2. Per the cookbook, I should now "start your trust onboarding process in the swiyu Service
   Portal" — I could not find this action anywhere in the portal. Checked the DID detail page,
   "PartnerProfil", and "Profil verifizieren" (the latter turned out to be the organizational
   e-ID/UID identity check, unrelated to DID trust onboarding).
3. Calling the API directly confirms nothing was created server-side:

GET /api/v1/trust/trust-onboarding-submission/proof-of-possessions
→ {"errorCode":"resource_not_found","message":"No UNSUBMITTED TrustOnboardingSubmission found
   for partner and therefore no submission of proof of possessions is possible"}

Reproduced this end-to-end twice, with two separate business partners and two separate
freshly-generated DIDs — same result both times.

So my actual question is: what is supposed to trigger the creation of a
TrustOnboardingSubmission in the first place? Since it's clearly not the toolbox version, I
must be missing a step or a button somewhere in the portal — or there's currently a gap there.
Would appreciate if your developers could point me to the correct action.

Thanks!

[bit-sbonzelet]

Hi @ajnurademi

to onboard your DID into the trust registry you need to verify your business partner, during this process you are then asked to provide the proof of possessions of your DIDs.