matrix-org / matrix-org/matrix-rust-sdk

Expose password-change UIAA flow through matrix-sdk-ffi

Open
#6,771 1 comment 0 reactions 1 assignee Claimed by @Hywan View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.