matrix-org / matrix-org/matrix-rust-sdk
Expose password-change UIAA flow through matrix-sdk-ffi
- Dominant language
- Rust
- Stars
- 2.3k
- Forks
- 500
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 106
Description
## Problem
The Rust SDK exposes `Account::change_password(new_password, auth_data)` with UIAA support, but the generated FFI/Swift surface does not expose a password-change execution method or a password-specific `AccountManagementAction`.
Current FFI evidence:
- `HomeserverCapabilities.can_change_password()` / Swift `canChangePassword()` reports capability only.
- `Client.account_url(action)` / Swift `accountUrl(action:)` supports `profile`, device-list/view/delete, account deactivation, and cross-signing reset.
- There is no password-change action and no FFI account method that can initiate or continue the UIAA password-change request.
This leaves native Swift clients unable to change a password through the SDK without either using an unrelated generic web account page or implementing a second authenticated Matrix transport.
## Requested FFI capability
Expose an SDK-owned password-change flow through `matrix-sdk-ffi`, including:
1. initiation with the new password and the SDK's normal default for logging out other devices;
2. a typed UIAA challenge/result that can be presented by native clients;
3. resubmission with the selected authentication data/session;
4. explicit completed, cancelled/aborted, unsupported, and typed failure outcomes;
5. no access token, password, raw authenticated request, or secret-bearing URL returned across the boundary.
A password-specific account-management action would also be useful where the homeserver advertises a delegated web flow, but a generic `accountUrl(nil)` is not sufficient because clients cannot establish that the URL is specifically authorized for password change.
## Acceptance
- Generated Kotlin/Swift bindings can discover whether password change is supported and execute the full native/UIAA flow.
- UIAA continuation does not require clients to construct their own authenticated HTTP request.
- Tests cover success, UIAA challenge/continuation, cancellation, weak-password/error handling, and session/logout-device behavior.
- Sensitive values are not embedded in URLs, logs, debug descriptions, or durable FFI state.
## Downstream context
ZenithResearch/macOS-client#10 is blocked on this capability. Its pinned generated Swift artifact confirms the capability/action gap; no custom authenticated transport will be added downstream.
Contributor guide
Assessment
This issue has not been assessed yet.