mimi - 19 Mar 2024

Rohan: When we say "discovery problem", this is short for "provider
discovery problem".

Vittorio: I'm not sure we agree SIIs need to be registered on the

Richard: We have a presumption that if you have an SSI, discovery is
unnecessary. The mimi protocol should start with SSIs.

Vittorio: I think we need to identify which characteristics of these
identifiers we need for them to be useful, to get to resolution on what
Discovery provides.

First Principles

Richard: The requester needs to get a notion of which MSP to talk to,
and what bits to give MSP to reference user.

Jim: I can see the difference b/t reachability information and SSIs.
Shouldn't we simplify by always using SSIs?

Harald: "If you can have or make an SSI, then you don't need B" -- This
means returning an SSI is all that matters.

Jon: Should the DP provide additional information needed to contact a
user beyond just their MSP?

Rohan: In favor of leaving additional information to interaction with

Sean: DKG says better to return key material

Richard: The security we need at this layer is SSI integrity. Securing
the other stuff is going to be harder. Crypto info and SSI-SII bindings
have very different lifetimes.

Ekr: Signing keys are long-lived, vs encryption keys which are shorter.
Practically, these seem coupled. Without a signature key, how do you
trust the binding?

Second Principles

Jon: Do people agree numbers are the most important? Should emails be

Vittorio: Numbers are most important. Indifferent about emails.

Ekr: I would argue for numbers. Maybe on emails. Are there services that
use emails in this way?

Richard: WebEx uses emails as SIIs. I don't think there is a risk of
causing people to need a phone number to use mimi, as people can always
use SSIs.

Ben: iMessage uses emails as SIIs as well.

Harald: Numbers are useful for identity because of number transfer
requirements. Emails can be independent as well. Emails should be
supported as well.

Bron: Would love to see email support as well.

Daniel: Support for email as well.

Tim: Another reason for email support: helps separate personal from
business communication.

Fundamentals of DP

Jon: Should DP be a logical singleton or is there reason to shard?

Ekr: Is there logically one thing or multiple things? Analogous to MSP,
a DP could be sharded by country code. But not gatekeeper MSPs.

Ben: Would love to be a logical singleton, but naive to think this is

Richard: We agree the ideal is being able to tell requester what all the
SSIs are.

Alissa: Some entities in the system will have to meet legal requirements
outside of protocol. Gives us flexibility, we don't have to solve every
jurisdictional problem in protocol.

Harald: DP has to be a logical singleton, in the same way phone numbers
are. System will have to be built from multiple providers.

Bron: Agreed with Harald. You also need a way to port SIIs. How much can
we say, to be a conforming DP, you need to provide an alias resolution

Vittorio: I do expect MSPs to run their own DP. Agreed we need a
singleton that's sharded internally.

Mimi Session 2 : Thursday March 21 9:30


Chairs, 5 minutes

Content format
Rohan Mahy, 30 minutes

MIMI architecture
Richard Barnes, 20 minutes

Richard Barnes, 65 minutes

At the end of the session, the group voted to adopt the current drafts
as working group documents.