Skip to content

MSC3879: Trusted key forwards#3879

Open
uhoreg wants to merge 3 commits intomatrix-org:mainfrom
uhoreg:trusted_key_forwards
Open

MSC3879: Trusted key forwards#3879
uhoreg wants to merge 3 commits intomatrix-org:mainfrom
uhoreg:trusted_key_forwards

Conversation

@uhoreg
Copy link
Copy Markdown
Member

@uhoreg uhoreg commented Sep 5, 2022

@uhoreg uhoreg changed the title MSCxxxx: Trusted key forwards MSC3879: Trusted key forwards Sep 5, 2022
@uhoreg uhoreg marked this pull request as ready for review September 5, 2022 16:05
@uhoreg uhoreg added e2e proposal A matrix spec change proposal kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Sep 5, 2022
Comment thread proposals/3879-trusted-key-forwards.md Outdated
Comment thread proposals/3879-trusted-key-forwards.md Outdated
Comment thread proposals/3879-trusted-key-forwards.md Outdated
Comment thread proposals/3879-trusted-key-forwards.md Outdated
Co-authored-by: Denis Kasak <dkasak@termina.org.uk>
that the events encrypted with this session cannot be trusted, which causes
confusion for users.

We propose adding a flag to the `m.forwarded_room_key` event to indicate
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Maybe clarify that it's added to the event content

@@ -0,0 +1,75 @@
# MSC3879: Trusted key forwards
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

As mentioned elsewhere, the term "trusted" isn't a great term to use. It is used to mean various things in various places. We'll probably switch to another term.

The basic premise of this MSC is to provide a method for the key forwarder to indicate whether it believes that the room key was actually sent by the given sender_key. It is still up to the recipient of the key forward to determine whether the sender_key is "trusted" (e.g. by checking whether they have been verified)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

As mentioned elsewhere, the term "trusted" isn't a great term to use. It is used to mean various things in various places. We'll probably switch to another term.

My objection to "trusted" isn't particularly about the term itself, but rather that it tends to get used without any additional context (what does it mean for a device to be "trusted"?). Provided it's clear from the context what we actually mean by "trusted", it's fine.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I think that "authenticated" would be a better term than "trusted". I used "authenticated" for MSC4048, and I think we should use it here too. In either case, both should use the same name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

e2e kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants