SDK profile update rejected: 401 invalid signature on PUT /users/<cryptoId>/profile

[oxoxDev]

Summary

Every wallet profile update — users.updateProfile() (CLI: profile set) — fails on staging with HTTP 401 {"error":"invalid signature"} on PUT /users/<cryptoId>/profile. The endpoint is currently unusable.

Where

• SDK: sdk/typescript/src/api/users.ts → updateProfile + userProfileSignaturePayload (canonical user.profile).
• Surfaces in the OpenClaw plugin as profile set, and previously as a false failure of domain buy (the post-register recordHarness telemetry write hit this endpoint; mitigated client-side in fix(openclaw): record harness key best-effort so domain buy survives a profile-write failure #88, but the root is here).

Isolation (what is NOT the cause)

The signing machinery is fine — these all pass against staging with the same signFreshCanonicalPayload + directory-auth (X-Agent-ID = publicKeyBase64):

• card publish, domain primary
• registry.updateProfileVisibility (body-canonical identity.profile.visibility)
• POST /users/<cryptoId>/email/verification (startEmailVerification) — same /users/* directory auth, and its canonical (user.email.start) includes harnessKey and still verifies.

So: the /users/* directory auth, the freshness/nonce scheme, and including harnessKey in the canonical are all correct. Only the user.profile canonical on the profile-update endpoint is rejected.

Further narrowing (all return 401):

• canonical variants: full 8-field, drop harnessKey, minimal {cryptoId, displayName}, action: "users.profile", actorType: "agent" filled, drop avatarEmail/actorType.
• both X-Agent-ID = publicKeyBase64 and X-Agent-ID = cryptoId.

Conclusion

The backend's userProfilePayload (the string it rebuilds to verify) diverges from the SDK's userProfileSignaturePayload (users.ts:105) in the non-harnessKey fields. Since email.start verifies with harnessKey present, harnessKey is not the culprit. Most likely a field the backend includes or excludes that the SDK doesn't mirror — e.g. the stored email on the profile, or a server-side defaulting of actorType/avatarEmail — or a field-name/casing drift. The fix is to realign the two canonical builders field-for-field.

SDK canonical today

canonicalPayload("user.profile", {
  actorType, avatarEmail, bio, cryptoId, displayName, harnessKey, link, tags
})   // omitted fields -> null; keys sorted; then "\n{ts}\n{nonce}" appended and signed

Repro

const client = makeClient(config, signer);            // staging-api.tiny.place
await client.users.updateProfile(signer.agentId, { displayName: "X" });
// -> HTTP 401 { error: "invalid signature" }

Reproduced on a registered staging agent; resolve @<handle> confirms the wallet exists and other signed writes succeed for the same key.

Impact

• profile set unusable.
• Any flow that touches it secondarily fails (e.g. domain buy's harness-key write — patched to best-effort in fix(openclaw): record harness key best-effort so domain buy survives a profile-write failure #88, but profiles still can't be edited).

Suspected regression window

Commit 2df2d3c (2026-06-15) added harnessKey to the profile canonical — but since email.start verifies with harnessKey, the break is likely in another field of the profile canonical, not harnessKey itself. Needs a field-for-field diff against the backend userProfilePayload.

[oxoxDev]

Root cause found — staging backend is stale, not an SDK bug

Traced against the backend source (backend-tinyplace, internal/users/handler.go):

• The backend's userProfilePayload builds the identical canonical to the SDK's userProfileSignaturePayload — same 8 fields (actorType, avatarEmail, bio, cryptoId, displayName, harnessKey, link, tags), same names. Dumping both for a displayName+harnessKey update gives byte-identical strings.
• The backend's own auth round-trip tests pass against current code: TestUserProfileUpdateRoundTrip (signs userProfilePayload the SDK way → 200), TestUserProfileUpdateStoresHarnessKey, partial-update, foreign-signer-reject. So current backend main + current SDK are fully consistent — the signature verifies locally on the first try.
• Yet deployed staging-api.tiny.place rejects the identical current-SDK signature with 401 invalid signature, while it accepts the SDK's user.email.start signature (same /users/* directory auth + freshness scheme + harnessKey-in-canonical). Tried ~15 profile canonical/header permutations (with/without harnessKey in body+canonical, merged-record values, actorType filled, X-Agent-ID = pubkey vs cryptoId) — none verify on staging.

Conclusion: the deployed staging backend predates / diverges from current main on the user.profile signature path. No SDK or plugin change is needed.

Action: redeploy the backend submodule from current main to staging, then re-verify users.updateProfile / profile set. Closing-ready once staging is on current main.

(Note: PR #88 makes recordHarness best-effort so this can't mask a successful domain buy regardless — keep it.)

[graycyrus]

Fixed in #120. Your diagnosis was spot on — the backend's canonical user.profile payload (internal/users/handler.go userProfilePayload) includes a field the SDK wasn't mirroring: the wallet-level private flag. The SDK signed an 8-field payload while the backend rebuilt a 9-field one, so the signature never verified → 401 invalid signature.

#120 adds private to the signed canonical in both the TS and Rust SDKs (with a test that reconstructs and ed25519-verifies the freshness signature covers it). TS SDK republished at 0.10.0; Rust at 0.6.0+. profile set / users.updateProfile() verify now. Closing as resolved.