MIMI Discovery 5/22

Jon Peterson leading a discussion on discovery requirements.

Slide 2: Consensus points: the basics

• We've been doing requirements since Brisbane. Goal is to work toward
  a requirements draft.
• Discovery providers (DPs) are probably operated by Messaging
  Service Providers (MSPs) but not necessarily
• Authenticated Mappings shows relationship between identifiers and
  MSPs where those identifiers are available. Relying parties trust
  the signatures on the mappings. Mappings may be distributed by some
  party besides the signer.

• Proposal: Instead of SII, let's say Cross-Platform Identifier (CPI).
  Let's keep SSI.

  • Rohan Mahy: Supports the name change
  • ekr: maybe global vs. local is the right way to distinguish?
  • Tim Geoghegan: awkward that one uses "platform" and the other
    uses "service", consistency would be nice
  • Jon: we just need something better. Let's do CPI and PSI
    (because implication that we're psychics is fun).

• Important note: Discovery is not a DMA requirement!

Slide 3: Consensus Points

• Discovery problem implies the authentication and distribution
  problems
• Discovery acts on CPIs: if you have an SSI, you don't need
  discovery.
• WG has slight preference for "singleton" DP, operated by an MSP
  • But protocol should be neutral on the architecture
  • Unclear what if anything we can do about "fairness" in discovery

Slide 4: Receiver Prefrences

• Less weight on sender preferences
• Desire to keep this simple because we lack confidence on how well
  we'll do this
• For the queue: how do receivers express preferences? How are
  preferences enforced?
  • ekr: some of this is a client-MSP interaction, which is not
    in-charter for MIMI.
  • Jon: the object in the authenticated mapping could include any
    metadata we want, including these preferences.
  • Tim: the representation of the preferences has to be described
    by MIMI.
  • Femi Olumofin: What if receiver has presence in multiple MSPs
    and/or multiple DPs? In that setting, global preferences are
    difficult. Also brings privacy challenges.
  • Jonathan Lennox: If preferences are attached to the mapping,
    then what two mappings for some CPI disagree?
  • Tim: If the receiver preferences are inside the authed mapping,
    this allows MSP/DP to forge user preferences which seems bad.
  • ekr: If we have Authentication Providers that are distinct from
    MSPs (not obvious) then MSPs may not be able to forge user
    preferences.

Slide 5: User and Social Graph Privacy

• Are mappings (whether some CPI is resident at an MSP) aggregated at
  DPs private? Are those sensitive?

  • Travis Ralston: Yes.

  • ekr: Sure, they're sensitive, but what could we do about it?

    • Is there anything we can really do to stop big MSPs from
      eventually ending up with the whole database of mappings?

  • Jon: >=1 gatekeeper has asserted that they already don't treat
    this as sensitive information.

  • Daniel Gillmor: This architecture sounds a lot like current
    mobile phone network, which is highly susceptible to privacy
    violations.
  • Rohan: Agree with dkg. Hope that mimi-protocol allows
    side-stepping this problem completely by always using CPIs.
    mimi-protocol should be workable without involving discovery
    providers at all.

• Should/must users consent to creation of mappings?

  • Clearly we don't want to allow MSPs to just assert some CPI is
    on their provider
  • Travis: Don't think MIMI should solve this. Leave it up to the
    MSP/DP to decide if they'll publish whole user databases or
    obtain user consent.
  • ekr: Would be very hard to write a technical requirement. Would
    be nice to have a digital signature from a user, but requires
    some independent identity infra. Let's design something
    consistent or compatible with e2e properties, but unclear how to
    mandate them.
  • Jonathan L.: (not sure, something about ACME, sorry Jonathan)
  • dkg: The only arch that can mandate user consent is one where
    some long term user-held key is involved, meaning something
    related to MLS. Otherwise MSPs can always forge consent.
    • There's no cryptographic material attached to a CPI and so
      no way to verify that some attestation of consent came from
      the real user.

• Spam prevention: CPIs like phone numbers are the "front door"
  spammers can knock on. Do DPs have a spam prevention obligation?

  • ekr: This requirement has always been kinda misguided.
  • Travis: We should have some guidance here like rate limiting,
    but no strong requirements. Charter also complicates this,
    because much of this is internal to an MSP.
  • Jon: Yeah, this is a post-discovery problem.

• Do we protect discovery from data collection threats?

  • Jon: Should mitigate correlation threat. Could use IP blinding
    or the like.
  • Femi: We should either have a requirement that the content of
    the query be protected or the client IP is protected.
  • Tim: OHTTP is cool, but that's an additional trusted party in
    the protocol. What's the threat model for collusion with this
    multiplicity of actors (blinder, MSP, DP)?
  • ekr: Nobody should ever learn who is doing the query. But
    ultimately parties will connect and learn about each other.

  • dkg: Should enumerate who the parties involved are.

    • Recipient needs to know who Sender is
    • But nobody else should learn that R and S connected as this
      leaks the social graph
    • In particular, R's MSP shouldn't learn about S (but maybe
      not doable?)
    • Definitely don't leak this during lookup
    • Might be a tradeoff between protecting the social graph and
      protecting CPI->MSP mapping.

  • ekr: PIR has some bandwidth constraints to it.

  • Giles Hogben:

    • re: tradeoff identified by dkg: You can combine IP blinding
      with anonymous credentials to protect against large-scale
      scraping.
    • re: PIR bandwidth: should be tractable in PIR schemes being
      looked at.

  • Jon: requirement should be either hiding IP address of querier
    from MSP/DP or hiding the data the MSP is requesting?

    • ekr: agree

Slide 6: Discovery and MIMI identity

• What about rogue MSPs advertising false mappings?
• Who is trusted to advertise mappings? To claim CPIs?

• Do we need a neutral service(s) to prove mappings?

  • ekr: If the CPI is routable in some other system (i.e. phone #
    or email), then user is involved b/c provider doesn't control
    traffic to the CPI (WhatsApp can't read my email).

  • dkg: Am not arguing for there to be one true identity for a user
    across all possible MSPs.

    • if I am trying to map a CPI to those distinct MIMI
      identities, each identity ought to be involved.

  • Giles: Not clear why user consent is in the protocol.

    • Jon: signed mapping would include affirmation of user
      consent.
      • We must acknowledge that there will be gatekeepers that
        publish existing mappings into MIMI with little more
        than a prompt to user, if that.
      • UX would establish consent from user.

  • Alissa Cooper: Does user provide consent on per-MSP basis or
    per-CA basis?

    • Jon: Per-MSP since mapping is CPI->MSP.

  • Travis: How much trust is delegated to the ID prover? How/why do
    clients or others trust ID provers?

  • dkg: Unhappily agree with CA analogy. How does expiry work?

    • Jon: Yeah there are operability problems here.

  • ekr: Agree with dkg on CA analogy.

    • Responding to Alissa: Model should be that user holds a key
      and consents to creation of a binding to it. That binding
      asserts a relationship to an MSP.

  • Tim: Running anything analogous to a CA is expensive and really
    hard. Must make sure that ID prover involvement is relatively
    infrequent (i.e. can't be every time someone looks up a user) or
    running an ID prover will be too hard.

    • Jon: Probably this only needs to happen when some user opts
      into publishing themselves into MIMI.

  • Jonathan: Abandoning an MSP (i.e. I stop using Signal) presents
    challenges for validity period of mappings.

    • An obsolete mapping could still be out there in MIMI-realm
      but messages get dropped because the specific MSP no longer
      has that user.

Slide 7 (skipped)

Slide 8: Path forward

• Jon, Femi, Giles (others?) plan to write a new disco requirements
  doc for IETF 120