Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC2284: Making the identity server optional during discovery #2284

Merged
merged 3 commits into from
Nov 18, 2019
Merged

MSC2284: Making the identity server optional during discovery #2284

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
738fa68
Proposal to make the identity server optional during discovery
turt2live Sep 6, 2019
6baeb6c
Assign number
turt2live Sep 6, 2019
dcbdb94
Add explanation
turt2live Nov 8, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions proposals/2284-optional-identity-server-discovery.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# MSC2284: Making the identity server optional during discovery

Currently the specification requires that clients `FAIL_ERROR` (hard failure - do not continue)
when the `.well-known` file for `m.identity_server` points to somewhere invalid or is invalid
itself.

This proposal aims to change that by allowing clients to make a conscious decision to continue
with the invalid identity server configuration, provided the homeserver configuration is valid.

turt2live marked this conversation as resolved.
Show resolved Hide resolved
## Proposal

Instead of `FAIL_ERROR` for an invalid `m.identity_server` schema/server, clients are to move
to the `FAIL_PROMPT` (inform the user, ask for input if applicable) state. Clients can decide
to show a warning that the identity server is unavailable and allow the user to continue with
the invalid (or client's default) configuration.

## Tradeoffs

Clients can end up being configured with an invalid or inoperable identity server. This is
considered a feature by this proposal to allow for less intelligent clients to have their
identity server disabled. Intelligent clients could interpret the lack of identity server
as the homeserver/user asking that identity server functionality be disabled in the client.
Copy link

@joepie91 joepie91 Sep 6, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like in the interest of infrastructure debuggability and general client UX, there should be a flag that indicates whether the identity server is intentionally disabled, so that intelligent clients can distinguish between this and an erroneous misconfiguration (or transient unavailability due to infrastructural issues).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I agree. In terms of transient unavailability, users won't be able to log in in the first place because the homeserver information will also be missing. Spelling errors, structural problems, etc are easily debugged by a community member in a support channel - the problem should be obvious. For instance, if you end up with a user experience that doesn't involve the identity server you were expecting, you can probably guess that it has to do with your config. Hopefully people these days are still testing their configuration changes before going live.

The other point for defaulting to no identity server instead of wanting an explicit flag is to protect user privacy. Where possible, the spec should be heavily suggesting to clients that a default identity server not be used. When the spec says that lack of useful identity server information means that none is selected, the client can't reasonably default to an identity server which might be risky to the user. Not to mention a flag saying "I absolutely don't want to use an identity server" is more fiddly to implement, particularly when the interaction between users and homeservers is already insanely complicated during login.