Skip to main content

Minutes interim-2023-mimi-09: Wed 19:00
minutes-interim-2023-mimi-09-202309131900-00

Meeting Minutes More Instant Messaging Interoperability (mimi) WG
Date and time 2023-09-13 19:00
Title Minutes interim-2023-mimi-09: Wed 19:00
State Active
Other versions markdown
Last updated 2023-09-13

minutes-interim-2023-mimi-09-202309131900-00

MIMI Interim
2023-09-13

Jonathan Rosenberg -- Overall Requirements

S1: Two tier protocol with app providers with discovery providers

JDR: Is this the right architecture
EKR: I don't know? Whether this is the right architecture depends on
some questions that I don't know the answer to.
Rohan: I don't think this problem is very important, so I'm happy to
defer it
Giles Hogben: Broadly agree that those are the actors in this system.
They don't necessarily connect in the way those lines suggest they
connect. For instance, the user could connect directly to the discovery
provider.
JDR: Need to decide on an architecture to design the system. I don't
think that the user contacting the DS directly will work.
Giles: Whether the solution is impractical or not, this session is about
requirements
Vittorio Bertola: Requirements first then architecture
EKR: This implicitly assumes a bunch of requirements. In particular,
you're assuming that the mapping table ought to be secret, but is that
in fact the case. Maybe move ahead from the architecture.
Rohan: Keybase had a public database.

Skipping to Slide 5.
EKR: Key point here is that these last people are untrusted. If I can
spin up a linux box and become part of the system, then I can exfil the
entire database.
JDR: We need to worry about spam, even from bigger providers.
EKR: Agree about spam, but it's not clear to me that's done by
concealing the database. Email spam suppression works even if your email
address is public.
Alissa Cooper: This is fundamentally directed towards DMA, but DMA is
largely going to be bilateral arrangements. So do we need to really
worry about the the on-prem use cases.
JDR: Is trustability really solved by having the gatekeepers do
selection. But even if we remove consumer on-prem, we're still going to
see a lot of application providers for cost reasons.
AC: You're fine if consumer on-prem doesn't work
GH: I don't think bilateral or federated multiparty agreements are the
only way to ensure trust. If you wanted to include the last two, you
could have two disjoint federations where the trust is established
differently.
JDR: [...]
VB: Should design this in the most flexible way we can. Analogy to
e-mail
EKR: Identity is more important than privacy of the database

Slide 6.
AC: People are assuming that the database/discovery mechanism is
populated because people have to, not because they want to.
EKR: [...] I think we probably have to live with sort of trusting the
big providers.
GH: Every major messaging provider already makes their database public
and the only protection is rate limiting.
JDR: You can't enumerate
GH: Obviously I can brute force the database.
JDR: I think it's critical to keep a lot of the databae private because
it's business sensitive information.
The only thing you should be able to do is a lookup that is appropriate
for your use case.
GH: The privacy requirements in the mapping database aren't important,
but what is important is the privacy of the lookup query itself. That
leaks your communication graph.

ekr:

EKR first enumerated the overall context, similar to what Jonathan
covered - we have SIIs, we need to map them.

EKR then hypothesized a potential solution - a system in which Alice
gets a cert that asserts ownership of her number, downloaded to her
client, and then uploads it to a global directory. So - lets think about
it as - what sucks about this?

The main problem is security of this SII to SSI mapping. Who is allowed
to record a mapping? Three answers - the discovery service assets it.
The app provider assets it. Or, the user asserts it. An assumption we're
making - phone network correctly routes to phone numbers. Richard points
out that security means integrity.

Jonathan asserts that - the app provider cannot assert it in most cases,
only for a small number of gatekeepers. Jonathan and ekr went back and
forth about, how it would work for the non-gatekeeper case. Giles
suggests the discovery providers are the app providers, and we just
audit them. Basel says - MIMI doesnt need to solve the discovery
problem. Richard Barnes says, there will be certificate authorities -
so, who are they. Richard disagrees with Basel, says we do need to solve
this problem. Jonathan argues that, we cannot trust the APs - there are
too many. Basel says - its not an interop thing, its already an existing
problem. Ekr argues, the difference is that this is an open system, not
a closed system. Basel says, we want to be able to solve this within
those networks and across them.

Rohan Mahy states that, we dont need a way to discover identities on the
internet. This is different from solving it in a bilateral arrangement.
Richard said he was focused on the integrity part of that. Richard says
- we are converging around this idea of an authority. But, he doesnt
like the idea of "discovery" as a role. The critical thing is that we
have authorities here. The important part is the authority, not the
distribution of information. And the authority needs to be centralized.

Giles Hogben

Slide 3
Functional requirements.
A lot of back and forth about what exactly is being concealed. Is it the
pair of lookup and target? Just one or the other?

Slide 4
EKR: Are we really trying to conceal the database at all? It seems like
rate limiting is problematic and restricts the design space.
GH: I do think we should allow for some kind of rate limiting
JDR: Two classes of solutions (1) there is a lookup operation and (2)
where we distribute the database. One of the big differences is if they
protect against enumerations.
GH: A third solution where you don't have a central database and each SP
is responsible for queries on their own shared.
JDR: I believe there is a requirement that it is not possible for a
consumer or app provider to get a full copy of this database. This is a
goal of the design.
GH: I'm fine with that.
JDR: Does anyone disagree?
RLB: If you are in an open system, then anyone can spin up their own
node and pull down a piece of the datbaase
GH: The owner of the data should be in control of the rate limiting

Vittorio Bertola

AC: What do people think about a new identifier spacE?
JDR: I don't really believe in it
EKR: This has to support E.164 but I don't think this precludes a new
identifier space.
GH: You can always make a new id space with a service id + an SSI

Giles (alternate notes):

What is the user journey we are trying to support here? It is NOT that
you want to look up a contact. It is - I want to send a message. And to
do that, I need their public key, there is no way around that. And, I
need to know, where to send it.

Second requirement, I might use the same identity on multiple services.
I want to be able to specify on which client I want to receive messages
on. Third: the identifiers need to be globally unique. Fouurth, there
should be a way to verify the association between identifier and public
key. Some kind of standardization around verification of the
association.

Privacy requirements - privacy of the social graph is super important.
Resolver services should not learn the PN/UserID that is beign queried
for. SImilarly, the querying users identity should not be passed on to
other discovery services. Resolver service should not learn the exact
timing of when the message is sent.

Richard asks - social graph refers to both querying and receiving. Does
just revealing that, "someone is querying for Giles" is something we
want to prevent against. There is "someone is asking for Giles" and the
other is "Richard is asking for someone". Which do we want to protect?

EKR - it is not a goal to conceal from the application provider. So, if
I'm on Whatsapp, and the other person is on iMesage, we are not trying
to prevent iMessage and WhatsApp from learning the graph. Giles agrees.

Jonathan asks - is your requirement that the discovery provider return
the cert? Giles says - no - they just discover where to go, to get it.

Jonathan asks about why this is not a conflict, if you think the app
providers and discovery providers are the same, dont the app providers
(and thus teh discovery providers) know the social graph anyway? Giles
said - no - because OTHER providers are there, and we dont want them to
see the social graph.

Alissa says - we should state this as requirements about, there is a
matrix of, who sees what information at query time.

Rohan says, the user could do the lookup themselves, you dont need to
put it in the app.

Giles went through non-requirements. He said, it is a non-requirement to
hide service reachability. Hiding the userIDs or public keys is a
non-goal, hiding of userIDs or publc keys. Nor, looking up contact by
name.

EKR pushes on point one - "hiding service reachability". There are two
forms of public - one is whether you alllow only queries, or do you want
to prevent scraping. He thinks scraping is outside of the scope.

Jonathan says - he does think its a requirement that we prevent it from
being trivial for someone to get a full copy of the database. Giles
basically agrees with the requirement. Richard says - we can have an
open query interface, without it degrading into a system where the
database is public. Giles says - the owner of the data, is in control of
the rate limiting.

Alissa says - we should take it to the list.

Vittorio (alternate notes)

Need to convert a user identifier that is service independent and user
firendly, into one or more machine friendly, service dependent
identifiers. So - its multiple 1-to-many non-exclusive unidirectional
relations. Vittorio says, we should not map existing identifiers, we
should have a new MIMI dependent identifier.

Vittorio says - he doesnt want to be forced to be reachable by an
external identifier and must be by user consent. This implies we need
MIMI-specific user identifiers. MIMI specific identifiers should be
simple, human friendly. Users and providers can create, own and manage
these identifiers.

Should be decentralized, security, privacy, any number of discovery
providers, uses open standards.

Should not create IP ownership issues, does not pose legal and
regulatory issues, and is compatible with data protection regimes.

He says we do need something like the discovery services we've been
discussing, for the existing identifier. Its just - another thing users
can use if they want, not ruling out the phone numbers and email
addresses.

Alissa asks for opinions from others. Jonathan states he doesnt think we
need this - it is too late to introduce a new identifier. EKR says he
largely agrees with Jonathan, but notes the current designs dont make it
impossible to support other identifiers. Giles says, we dont need
anything new. Jonathan Lennox says - some of the architectures have
assumed these are routable, not just unique, to confirm that they are
not lying. So, its not clear they will work for a new identifier that is
not routable.

Alissa asks for discussion to continue on the list, since the next
interim is on the design team. Maybe topics on - rate limting and
scraping the database. Would be nice to have a consolidated list of
these requirements, even if some of them have an option space. Be good
to get to a single view.

Yet another doodle coming for interims in October, more European
friendly time.