MIMI interim 4/23/2024

Chair slides

More interims coming to cover disco and other topics -- please contact
mimi-chairs@ietf.org if you want agenda time

MIMI Discovery - Jon Peterson

Still tenative discussion. Several candidate architectures exist.
Will discuss how to instantiate a discovery provider (DP).
Discuss how users relate to the discovery process.
We'll iterate over some strawmen to see what we do and do not like.

Consensus points from Brisbane October (slide 2)

• Assume multiplicity of MSPs
• MSPs assert mappings of SIIs to an MSP's users

• Senders want to dsicover SII->MSP mapping

  • Not all MSPs are trusted to do this!

• Twofold problem: authentication and distribution

Rohan Mahy: these considerations also apply within a MSP, not when
sender/receiver are on distinct MSPs

• We need better terms than SSI and SII that aren't homonyms
• Discovery acts on SIIs. You don't have a disco problem if you have
  an SSI in hand.

• Email addresses and telephone numbers are supported SSIs

  • E.164 helps with some jurisdictional concerns

• General support for DP as a singleton

Fundamentals of DPs

• Is a DP a logical singleton? If not, how do multiple DPs cooperate?

• Will MSPs run their own DP?

  • Are MSPs a natural boundary for sharding discovery?

• Are users aware of DPs?

Richard Barnes: Are DPs independent of MSPs? MSPs are the source of
truth for the mappings, ultimately. Simplest possible thing is for
exclusively MSPs to be DPs. Who are these people who aren't MSPs but
want to be DPs?

Potential DP models (slide 5)

• Are we concerned about bias in DPs? i.e., some DP could have a
  preference for routing disco requests to its favoured MSP.
  • Is this a problem in light of DMA? Should we anticipate
    requirements around gatekeepers in particular?

Richard: Also/more concerned about a DP asserting false mappings.

Monolithic singleton

• Might instantiate this to address concerns of bias and fairness
• MSPs are responsible for providing mappings to the monolith
• Could still be sharded by geographical or jurisdictional lines

Hierarchical resolvers

• Akin to DNS, but need not literally be DNS!
• Root resolver could delegate all the way down to MSPs
• Every DP must deal with root resolver, but less interaction between
  DPs

Federated

• DPs agree to federate with each other pairwise for business reasons
  out of scope of MIMI or anything

Tim Geoghegan: pairwise relationships in the federated case could create
a barrier to entry for smaller MSP/DPs akin to getting trusted into the
DKIM/DMARC ecosystem
Jon: You might end up with split views of SII mappings, unlike "loosely
coherent" DNS
Richard: All these models might be quite similar from a protocol point
of view. So can the WG focus on the protocol and defer the model
question to "the market"?
Jon: Sounds plausible, if we have detached signatures over identity
assertions/mappings (s.t. it doesn't matter which DP vended them to
users)

Considerations on DPs (slide 6)

• Is eliminating bias a requirement? Or is it required that all
  possible authenticated mappings be visible?

Jon: it's possible that there will be regulatory or privacy requirements
that force some DP to restrict what mappings it presents, suhc that we
can't require neutrality.
Femi Olumofin: DMA is concerned about smaller MSPs vs. gatekeepers. Key
consideration is smaller MSPs being able to find users on gatekeepers.
In federated arch, a user may get different mappings based on which DP
they talk to.
Tim: Would forbidding bias mean requiring consistency across all DPs?
That might be too hard of a technical requirement, especially when DPs
are independent.
Alissa Cooper: Focus on user experience is key, moreso than the DMA. Not
apparent that DMA even requires discovery. We've seen actual shipped DMA
solutions that don't make this nearly as seamless as MIMI envisions.
Gatekeepers may be incentivized to add friction to discovery. Giving
users a consistent view of mappings will yield the best user experience.

Giles Hogben: "fairness" cannot be enforced technically. That will exist
at a higher policy level. MIMI's job is to expose sufficient info to
allow policy layer to make fairness determiniations.
Jon: Telephony has examples of designs informed by fairness. The
monolith provides this.
Richard: But who runs the monolith, and how do we assure ourselves they
are fair?
Richard: To technically enforce neutrality, you'd have to do some fancy
PIR thing wherein you can prove the server doesn't know what query it's
answering.
Alissa: The gatekeeper can always apply a lot of bias in the client they
distribute (don't display mappings they don't like, introduce UX
friction).

• Authenticated TN (telephone numbers?) mappings
  • Authorities for phone numbers are all over the place, and
    lookups can cost money!

Alissa: Question for the WG: Should different users get approx.
consistent answers to the same query?
Richard: Yes, approximately.
Richard: Let's assume mappings are authenticated s.t. you can't assert
false mappings. Remaining consideration is to prevent suppression of
authentic mappings.
Giles: This problem is much easier to solve at the policy/regulatory
level than at the technical/protocol level. There will always be gray
areas.

Query/Response Fundamentals (slide 7)

• Where/when does discovery happen?
  • When a message is actually sent? Or can you separately "add a
    contact"?

Alissa: Ideally we'd have building blocks that support both of these.
Need to assume both of these modes are of interest.
Rohan: We have a connection oriented consent model in a draft I wrote.

Tim: Objective of discovery is to enable users across MSPs to establish
an MLS protected channel, so it doesn't quite matter whether you'll use
that to exchange text messages or contact cards. MIMI's job is the same.

• What if there are multiple mappings for one SII? Who picks a winner?

Richard: This should be considered in light of consent: if the recipient
consents, they can also use that to indicate which MSP they want to be
contacted on.
Alissa: More user research could be helpful.
Giles: There was a proposal in the past where we'd allow a user to
indicate which mapping is the one it prefers.
Jon: How rich does this negotiation become? Do we need a while
offer/answer protocol?
Giles: We can't technically enforce a fair UX. All we can do is design a
protocol that provides applications enough information to make fairness
possible.
Tim: How do we break ties between MSPs, each asserting they're the
preferred mapping? Can an MSP lie?
Giles: We had a way to solve this, but we do have to deal with users
changing their preferred mapping.

Users and DPs (slide 8)

• Do users or MSPs do discovery?

Rohan: Want to cover the case where I publish an address where my
stockbroker business can be reached. But I don't want to get personal
messages there. Want to empower users to route distinctly between
someone's personal and business identities.
Rohan: This means maybe I want an SSI that opts out of discovery, can
only be reached directly by the SSI. Or maybe we need to attach hints to
mappings so a client can display annotations, metadata about a mapping.

Tim: To Rohan: are the business and personal identifiers distinct SSIs?

Rohan: They're not different SIIs, but go to distinct SSIs.
Tim: Having users directly hit every DP ("user driven") is a huge
availability burden for non-gatekeepers.

Considerations on User/DP (slide 9)

• What are scale requirements for DPs? Billions of devices or 100s,
  1000s of MSPs?
• How much user control do we allow? Preference bit? Ordering of MSPs?
• What are privacy implications of revealing client IP or requests to
  either MSP or DPs?

Giles: IP blinding (a la OHTTP) helps a lot here
Giles: MSP gets the sender information anyway
Tim: Threat model has to assume that DP and MSP are colluding.
Alissa: The privacy properties of discovery need to account for metadata
privacy discussions we're having. In particular, discovery should not
leak information s.t. metadata privacy protections elsewhere are
undermined.
Jon: re: users interacting directly with DPs: in the case where DP is
federated, what if an MSP encounters a mapping outside of the federation
the MSP is a member of?

Sender and Receiver Preferences (slide 10)

• Do we need protocol level affordances for users to express
  preferences related to discovery?
  • e.g. preferred service to receive messages on

Jon: Is the job of discovery to find the intersection of services that
sender and receiver both support and select one?
Giles: That's not discovery's job.
Rohan: That's not discovery's job. Also -- the DMA has no discovery
requirement!
Giles: I'm actively opposed to discovery finding intersections of
supported services. This would incentivise users to install the most
popular apps, which is the opposite of what MIMI wants to do.
Alissa: Let's start with a very simple capability advertising system.
Alissa: Let's talk about categories of preferences. Sender gets to
choose sending MSP by choosing which app to run. Sender might define a
list of forbidden MSPs, but this seems low priority. Let's instead focus
on the receiver, the party that isn't online when a message is being
sent.