WIP: Decentralize Matrix identity verification #26

Open
yarmo wants to merge 2 commits from matrix-room-verification into main
yarmo commented 2 months ago
Owner

What?

This PR deprecates the current Matrix verification method as a "legacy method" and adds a new fully decentralized verification method.

Why?

The current method is not a good method as it requires everyone to create a post in a central room, facilitating scraping and requiring verifier libraries to create an account that is a member of this central room.

A new method is needed that doesn't require a central room to work and can be verified by a single API call (with access token).

How?

The new method is similar to the Telegram verification method.

The new method requires people to create a "private (invite-only)" room, set "Who can read history?" to "Anyone" and then add the identity proof to the room's topic. The topic can be read without an account being member of the room.

The v

The new method uses the same configuration as the legacy method.

Issues

When performing the steps described above on matrix.org, it works instantly. The API call looks roughly like:

{
	"chunk": [
		{
			"content": {
				"org.matrix.msc3765.topic": [
					{
						"body": "XXX",
						"mimetype": "text/plain"
					}
				],
				"topic": "XXX"
			},
			"origin_server_ts": 123123,
			"room_id": "!XXX:matrix.org",
			"sender": "@XXX:matrix.org",
			"state_key": "",
			"type": "m.room.topic",
			"unsigned": {
				"age": 123123
			},
			"event_id": "$XXX",
			"user_id": "@Yarmo:matrix.org",
			"age": 123123
		}
	],
	"start": "t8-3301255111_0_0_0_0_0_0_0_0",
	"end": "t8-3301132175_0_0_0_0_0_0_0_0"
}

When performed on my personal Synapse homeserver, and verifying using an account on matrix.org, I get the following error:

{
	"errcode": "M_FORBIDDEN",
	"error": "User @XXX:matrix.org not in room !XXX:otherserver.org, and room previews are disabled"
}

Either I have not properly configured my homeserver, or room previews do not work across instances, which would not be great.

A potential solution would be to have a matrix.org account, create the room on the matrix.org server, invite your account as admin and let that account set the topic.

Downsides to this solution:

  • matrix.org may not be a fan of this behavior
  • it centralizes the verification to a single instance

We need to figure out what the correct configuration is.

Then comes the issue of accounts on instances with admins unwilling to change the config.

A solution would be to set up a dedicated instance (with correct configuration) where we automatically set up rooms and set up the verifiees as moderator so they can set the topic.

Downside: responsibility of hosting and centralization.

TODO

  • Make sure account to verify is the poster of the topic
## What? This PR deprecates the current Matrix verification method as a "legacy method" and adds a new fully decentralized verification method. ## Why? The current method is not a good method as it requires everyone to create a post in a central room, facilitating scraping and requiring verifier libraries to create an account that is a member of this central room. A new method is needed that doesn't require a central room to work and can be verified by a single API call (with access token). ## How? The new method is similar to the Telegram verification method. The new method requires people to create a "private (invite-only)" room, set "Who can read history?" to "Anyone" and then add the identity proof to the room's topic. The topic can be read without an account being member of the room. The v The new method uses the same configuration as the legacy method. ## Issues When performing the steps described above on matrix.org, it works instantly. The API call looks roughly like: ``` { "chunk": [ { "content": { "org.matrix.msc3765.topic": [ { "body": "XXX", "mimetype": "text/plain" } ], "topic": "XXX" }, "origin_server_ts": 123123, "room_id": "!XXX:matrix.org", "sender": "@XXX:matrix.org", "state_key": "", "type": "m.room.topic", "unsigned": { "age": 123123 }, "event_id": "$XXX", "user_id": "@Yarmo:matrix.org", "age": 123123 } ], "start": "t8-3301255111_0_0_0_0_0_0_0_0", "end": "t8-3301132175_0_0_0_0_0_0_0_0" } ``` When performed on my personal Synapse homeserver, and verifying using an account on matrix.org, I get the following error: ``` { "errcode": "M_FORBIDDEN", "error": "User @XXX:matrix.org not in room !XXX:otherserver.org, and room previews are disabled" } ``` Either I have not properly configured my homeserver, or room previews do not work across instances, which would not be great. A potential solution would be to have a matrix.org account, create the room on the matrix.org server, invite your account as admin and let that account set the topic. Downsides to this solution: - matrix.org may not be a fan of this behavior - it centralizes the verification to a single instance We need to figure out what the correct configuration is. Then comes the issue of accounts on instances with admins unwilling to change the config. A solution would be to set up a dedicated instance (with correct configuration) where we automatically set up rooms and set up the verifiees as moderator so they can set the topic. Downside: responsibility of hosting and centralization. ## TODO - [ ] Make sure account to verify is the poster of the topic
yarmo added 2 commits 2 months ago
c5a1b2104d
Improve claim verification logic
Poster
Owner

After some more testing, it appears cross-instance room previews are the issue. I can successfully preview a room's topic on my homeserver using an access token from my homeserver.

However, that same access token cannot preview a matrix.org room's topic, the same M_FORBIDDEN error appears.

After some more testing, it appears cross-instance room previews are the issue. I can successfully preview a room's topic on my homeserver using an access token from my homeserver. However, that same access token cannot preview a matrix.org room's topic, the same `M_FORBIDDEN` error appears.
Poster
Owner

It appears this is the MSC we need to make this PR actually work:

https://github.com/matrix-org/matrix-spec-proposals/pull/2444

MSC2444 allows federated peeking. It appears this issue has been worked on since May 2017:

https://github.com/matrix-org/matrix-spec/issues/245

It appears this is the MSC we need to make this PR actually work: https://github.com/matrix-org/matrix-spec-proposals/pull/2444 MSC2444 allows federated peeking. It appears this issue has been worked on since May 2017: https://github.com/matrix-org/matrix-spec/issues/245
All checks were successful
continuous-integration/drone/push Build is passing
continuous-integration/drone/pr Build is passing
This pull request has changes conflicting with the target branch.
src/enums.js
src/claim.js
src/claimDefinitions/index.js
src/claimDefinitions/matrix.js
Sign in to join this conversation.
No reviewers
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: keyoxide/doipjs#26
Loading…
There is no content yet.