Identity indirection (Extensible profiles as rooms) #19

New issue

Open

opened 2023-08-02 18:41:01 +02:00 by ckie · 2 comments

ckie commented 2023-08-02 18:41:01 +02:00

Copy link

Identity indirection (Extensible profiles as rooms)

Upstream:

• MSC1767: Extensible events
• MSC1769: Extensible profiles as rooms
• (tangential) MSC1228: Removing MXIDs from events

Related: #14, #18

Goals

• Separate a 'physical' homeserver user (MXID) from a user identity (MXID<->Profile is many-to-many (#14))
• Improve identity redact-ability: the user should be able to retroactively change their historical identity.
  • they transitioned
  • they're plural and two of their headmates mixed into one
  • they would like a more playful presentation outside of professional contexts
  • they would like a more playful presentation around their partner(s).
  • they're playing an RPG or a MUD or D&D campaign or something like that, idk.
• Net-negative technical debt; we'd like to explore & mow down hard-to-extend parts of the protocol as we develop Atoki.

Demo design (interdependencies not yet considered)

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The key word "SPLIT" represents a reference to a nonexistant proposal which the author(s) believe may bolster the current design problem. Italicized title-cased names MUST refer to pre-specified concepts as described in version 1.7 of the Matrix specification. Non-italicized title-cased names refer to a previously established context from another referenced proposal (Atoki discussion or Matrix Spec Proposal (MSC)) or the currently proposed design.

The following proposal is an exploratory draft and MUST NOT be implemented.

---

We specify an encrypted, signed Room Event field, profile_room, that MUST be attached (how?) to user-initiated Room Events which may concern room consumers (TBD) containing a Profile Room Reference.

When the profile_room Field is not specified, implementors MUST fall back to use of the m.room.member event as in the previous Specification.

(note: This can be contained to the instant messaging usecase more cleanly with a design alike to MSC1767; out-of-scope for this.)

Profile Room Reference

A Profile Room Reference is a Room Alias which MUST satisfy all of the following invariants:

• It's Room Alias MXID localpart SHOULD be a securely randomly-generated string.
  • If present: it MAY be a 18-character a-Z0-9 alphanumeric string and MUST be reasonably infeasible to enumerate. (TBD: Are room aliases actually considered unenumerable?)
• It MUST refer to a Room which, unless otherwise specified, MUST fulfill all of the following invariants, and is hereby named a Profile Room:
  • The referenced Room has a State Event of type m.room.create sent by the User now known as the Owning User.
  • The referenced Room has a State Event of type m.room.join_rules with a Event content of join_rule set to public.
  • The referenced Room SHOULD have a State Event of type m.room.power_levels prohibiting other users from sending any events other than m.room.member.
  • The referenced Room has a State Event of type m.room.history_visibility with a Event content of history_visibility set to shared or world_readable.
  • Exactly one of the following invariants:
    • The referenced Room is Unencrypted and fulfills the following:
      • has a State Event of type m.room.history_visibility with a Event content of history_visibility set to shared or world_readable.
    • The referenced Room is Encrypted and fulfills the following:
      • has a State Event of type m.room.history_visibility with a Event content of history_visibility set to shared. (TBD: Look at reasons to allow anything else, especially world_readable)
  • The referenced Room has a State Event of org.atoki.profile_room which MUST fulfill all of the following invariants:
    • It MUST NOT be assumed the Event Sender is the sole user of the identity.
    • Sending this State Event MUST require a Power Level of 100 by default unless otherwise specified by the User in the m.room.power_levels State Event.
    • SPLIT: It's State Event content MUST fulfill the following MSC1767 Extensible Event schema: (TBD: Incomplete, rough draft, pseudocode, should be split into its own section)

    {
        // MUST be supported:
        "org.atoki.display_name": String,
        / MUST be regarded to as standalone from Room Encryption:
        "org.atoki.avatar": Option<EncryptedFile | MxcUri>
    
        // MAY be supported:
        "org.atoki.profile_links": Array<{ 
            display_name: String,
            uri: ExternalUri,
            try_verify: boolean // rel=me verification?
        }>
        "org.atoki.profile_bio": ???, // (TBD: Depends on unwritten message AST spec, we'd like to reuse it for this)
        // TODO: think of some more
    }
    

To be done

• Fill in useful room encryption invariants, currently it's a pretty meaningless stub.
• Consider not creating rooms per-identity (there can be manymany >1000) and instead using state event keys. We cannot enforce one profile room per user because multiple MXID/physical users may want to administrate the same room. There may be multiple profile rooms and they may have multiple profiles.
• Write procedures for client-initiated profile resolution, profile creation, and modificaton.

# Identity indirection (Extensible profiles as rooms) *Upstream:* - [MSC1767: Extensible events](https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/msc1767/proposals/1767-extensible-events.md) - [MSC1769: Extensible profiles as rooms](https://github.com/matrix-org/matrix-spec-proposals/blob/matthew/msc1769/proposals/1769-extensible-profiles-as-rooms.md) - (tangential) [MSC1228: Removing MXIDs from events](https://github.com/matrix-org/matrix-spec-proposals/blob/rav/proposal/remove_mxids_from_events/proposals/1228-removing-mxids-from-events.md) *Related: #14, #18* ## Goals - Separate a 'physical' homeserver user (MXID) from a user identity (MXID<->Profile is many-to-many (#14)) - Improve identity redact-ability: the user should be able to retroactively change their historical identity. + they transitioned + they're plural and two of their headmates mixed into one + they would like a more playful presentation outside of professional contexts + they would like a more playful presentation around their partner(s). + they're playing an RPG or a MUD or D&D campaign or something like that, idk. - Net-negative technical debt; we'd like to explore & mow down hard-to-extend parts of the protocol as we develop Atoki. ## Demo design (interdependencies not yet considered) The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119). The key word "SPLIT" represents a reference to a nonexistant proposal which the author(s) believe may bolster the current design problem. Italicized title-cased names MUST refer to pre-specified concepts as described in version 1.7 of the [Matrix specification](https://spec.matrix.org/latest/). Non-italicized title-cased names refer to a previously established context from another referenced proposal (Atoki discussion or Matrix Spec Proposal (MSC)) or the currently proposed design. **The following proposal is an exploratory draft and MUST NOT be implemented.** ----- We specify an encrypted, signed Room Event field, `profile_room`, that MUST be attached (how?) to user-initiated Room Events [which may concern room consumers](#tbd) (TBD) containing a [Profile Room Reference](#profile-room-reference). When the `profile_room` Field is not specified, implementors MUST fall back to use of the `m.room.member` event as in the previous _Specification_. (note: This can be contained to the instant messaging usecase more cleanly with a design alike to MSC1767; out-of-scope for this.) ### Profile Room Reference A Profile Room Reference is a _Room Alias_ which MUST satisfy all of the following invariants: - It's _Room Alias_ _MXID_ _`localpart`_ SHOULD be a securely randomly-generated string. + If present: it MAY be a 18-character a-Z0-9 alphanumeric string and MUST be reasonably infeasible to enumerate. (TBD: Are room aliases actually considered unenumerable?) - It MUST refer to a _Room_ which, unless otherwise specified, MUST fulfill all of the following invariants, and is hereby named a Profile Room: <a name="profile-room"> - The referenced _Room_ has a _State Event_ of type `m.room.create` sent by the _User_ now known as the Owning User. - The referenced _Room_ has a _State Event_ of type `m.room.join_rules` with a _Event_ `content` of `join_rule` set to `public`. - The referenced _Room_ SHOULD have a _State Event_ of type `m.room.power_levels` prohibiting other users from sending any events other than `m.room.member`. - The referenced _Room_ has a _State Event_ of type `m.room.history_visibility` with a _Event_ `content` of `history_visibility` set to `shared` or `world_readable`. - Exactly one of the following invariants: + The referenced _Room_ is _Unencrypted_ and fulfills the following: + has a _State Event_ of type `m.room.history_visibility` with a _Event_ `content` of `history_visibility` set to `shared` or `world_readable`. + The referenced _Room_ is _Encrypted_ and fulfills the following: + has a _State Event_ of type `m.room.history_visibility` with a _Event_ `content` of `history_visibility` set to `shared`. (TBD: Look at reasons to allow anything else, especially `world_readable`) - **The referenced _Room_ has a _State Event_ of `org.atoki.profile_room` which MUST fulfill all of the following invariants:** + It MUST NOT be assumed the _Event_ _Sender_ is the sole user of the identity. + Sending this _State Event_ MUST require a _Power Level_ of `100` by default unless otherwise specified by the _User_ in the `m.room.power_levels` _State Event_. + SPLIT: It's _State Event `content`_ MUST fulfill the following _MSC1767 Extensible Event_ schema: (TBD: Incomplete, rough draft, pseudocode, should be split into its own section) ```ts { // MUST be supported: "org.atoki.display_name": String, / MUST be regarded to as standalone from Room Encryption: "org.atoki.avatar": Option<EncryptedFile | MxcUri> // MAY be supported: "org.atoki.profile_links": Array<{ display_name: String, uri: ExternalUri, try_verify: boolean // rel=me verification? }> "org.atoki.profile_bio": ???, // (TBD: Depends on unwritten message AST spec, we'd like to reuse it for this) // TODO: think of some more } ``` ## To be done - Fill in useful room encryption invariants, currently it's a pretty meaningless stub. - Consider not creating rooms per-identity (there can be manymany >1000) and instead using state event keys. We cannot enforce _one profile room per user_ because multiple MXID/physical users may want to administrate the same room. There may be multiple profile rooms and they may have multiple profiles. - Write procedures for client-initiated profile resolution, profile creation, and modificaton.

zocker.net commented 2023-08-15 11:25:52 +02:00

Copy link

I think such idea should also try to fulfill following goals:

• room profiles should (optionally) only be accessible to users which I want to share the profile with
  • I want to use my real name on Matrix, but I only want some users to see that.
  • Random room aliases do not suffice to make profiles secret enough, as rooms are discoverable by server operators.
• to save resources (rooms aren’t that cheap considering federation), I would pack all different profiles into one room
• avoid recipients of profiles being required to join a room (potentially you had that in mind as well, I would like to make that explicit as well)
  • this potentially opens up the social graph of users not being part of big, public rooms

I have already explained briefly how to implement that in my comment here: #18 (comment)

However, I would avoid using room encryption for profile encryption, as MegOLM or MLS (the algorithms for room encryption) require all recipients to be member of that room, increasing the complexity for the encryption (and publishing the social graph of users). My idea was to use a symmetric key encryption similar to how files are encrypted. However, the encrypted content gets stored in the profile room, while the key gets attached wherever the profile is used.

I maybe can find sometime at the weekend to adapt your demo design to incorporate my ideas in a proper demo design. (As always, any constructive feedback is appreciated)

I think such idea should also try to fulfill following goals: - room profiles should (optionally) only be accessible to users which I want to share the profile with - I want to use my real name on Matrix, but I only want some users to see that. - Random room aliases do not suffice to make profiles secret enough, as rooms are discoverable by server operators. - to save resources (rooms aren’t that cheap considering federation), I would pack all different profiles into one room - avoid recipients of profiles being required to join a room (potentially you had that in mind as well, I would like to make that explicit as well) - this potentially opens up the social graph of users not being part of big, public rooms I have already explained briefly how to implement that in my comment here: https://git.atoki.org/Atoki/discussion/issues/18#issuecomment-39 However, I would avoid using room encryption for profile encryption, as MegOLM or MLS (the algorithms for room encryption) require all recipients to be member of that room, increasing the complexity for the encryption (and publishing the social graph of users). My idea was to use a symmetric key encryption similar to how files are encrypted. However, the encrypted content gets stored in the profile room, while the key gets attached wherever the profile is used. I maybe can find sometime at the weekend to adapt your demo design to incorporate my ideas in a proper demo design. (As always, any constructive feedback is appreciated)

ckie commented 2023-08-16 04:28:24 +02:00

Author

Copy link

I think such idea should also try to fulfill following goals:

hi! (:

---

• room profiles should (optionally) only be accessible to users which I want to share the profile with
  • I want to use my real name on Matrix, but I only want some users to see that.

yeah! we thought of this while writing this line:

• It's Room Alias MXID localpart SHOULD be a securely randomly-generated string.

but it seems it slipped the requirements|goals section, thank you for bringing it back (:

---

• Random room aliases do not suffice to make profiles secret enough, as rooms are discoverable by server operators.

this appears to be a subset of the greater opaque (client side processing only) vs. transparent (MITM, but server can help us with compute if we trust it) problem.

i think it is up to the user's threat/convenience model, hence the dual-path encrypted/unencrypted profile rooms.

• to save resources (rooms aren’t that cheap considering federation), I would pack all different profiles into one room

mhm, that was added to the appendix ("to be done") a while ago after a friend (->artemis) pointed it out <3

---

• avoid recipients of profiles being required to join a room (potentially you had that in mind as well, I would like to make that explicit as well)
  • this potentially opens up the social graph of users not being part of big, public rooms

i did not consider how these two points overlap with the encryption codepath! excellent

I have already explained briefly how to implement that in my comment here: #18 (comment)

<forked into a comment there (link TBD)>

---

However, I would avoid using room encryption for profile encryption, as MegOLM or MLS (the algorithms for room encryption) require all recipients to be member of that room, increasing the complexity for the encryption (and publishing the social graph of users). My idea was to use a symmetric key encryption similar to how files are encrypted. However, the encrypted content gets stored in the profile room, while the key gets attached wherever the profile is used.

i love this bit too, but why symmetric? that seems quite odd. ed25519 keys are pretty small, but i wonder if post-quantum public keys are significantly longer.

I maybe can find sometime at the weekend to adapt your demo design to incorporate my ideas in a proper demo design. (As always, any constructive feedback is appreciated)

> I think such idea should also try to fulfill following goals: hi! (: --- > - room profiles should (optionally) only be accessible to users which I want to share the profile with > - I want to use my real name on Matrix, but I only want some users to see that. yeah! we thought of this while writing this line: > > - It's _Room Alias_ _MXID_ _`localpart`_ SHOULD be a securely randomly-generated string. but it seems it slipped the requirements|goals section, thank you for bringing it back (: --- > - Random room aliases do not suffice to make profiles secret enough, as rooms are discoverable by server operators. this appears to be a subset of the greater opaque (client side processing only) vs. transparent (MITM, but server can help us with compute if we trust it) problem. i think it is up to the user's threat/convenience model, hence the dual-path encrypted/unencrypted profile rooms. > - to save resources (rooms aren’t that cheap considering federation), I would pack all different profiles into one room mhm, that was added to the appendix ("to be done") a while ago after a friend (->artemis) pointed it out <3 --- > - avoid recipients of profiles being required to join a room (potentially you had that in mind as well, I would like to make that explicit as well) > - this potentially opens up the social graph of users not being part of big, public rooms i did not consider how these two points overlap with the encryption codepath! excellent > > I have already explained briefly how to implement that in my comment here: https://git.atoki.org/Atoki/discussion/issues/18#issuecomment-39 &lt;forked into a comment there (link TBD)&gt; --- > > However, I would avoid using room encryption for profile encryption, as MegOLM or MLS (the algorithms for room encryption) require all recipients to be member of that room, increasing the complexity for the encryption (and publishing the social graph of users). My idea was to use a symmetric key encryption similar to how files are encrypted. However, the encrypted content gets stored in the profile room, while the key gets attached wherever the profile is used. i love this bit too, but why symmetric? that seems quite odd. ed25519 keys are pretty small, but i wonder if post-quantum public keys are significantly longer. > > I maybe can find sometime at the weekend to adapt your demo design to incorporate my ideas in a proper demo design. (As always, any constructive feedback is appreciated)

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

master

No results found.

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Atoki/discussion#19

No description provided.