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
platform.
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.
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
MSP
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?
Jon: Do people agree numbers are the most important? Should emails be
included?
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.
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
achievable.
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
service?
Vittorio: I do expect MSPs to run their own DP. Agreed we need a
singleton that's sharded internally.
Administrivia
Chairs, 5 minutes
Content format
Rohan Mahy, 30 minutes
https://datatracker.ietf.org/doc/draft-ietf-mimi-content/02/
Reviewed proposed changes to the content format, including removing
explicit message IDs and timestamps. There was discussion of how to
best represent the order of messages.
An issue was raised about potential privacy and security risks of
external attachments. Additional policies may be needed to control
acceptable attachment types.
Options for encoding the message format were debated, including TLS
presentation language, CBOR, and defining a new format. Most seemed
to lean towards TLS or CBOR for standardization and extensibility.
A vote was taken on whether to use TLS presentation language or CBOR
for the encoding, which was split and apparently gamed in the last
seconds. The speaker suggested trying TLS syntax first while
examples are shown in CBOR.
Ensuring messages and mentions are securely tied to senders to
prevent tampering was also discussed.
MIMI architecture
Richard Barnes, 20 minutes
https://datatracker.ietf.org/doc/draft-barnes-mimi-arch/03/
mimi-protocol
Richard Barnes, 65 minutes
https://datatracker.ietf.org/doc/draft-ralston-mimi-protocol/02/
The proposed architecture of having rooms hosted at a central hub
server, with clients routing messages through the hub. This is
intended to be the basic unit of functionality.
Clarifying the hierarchy between users as participants at the policy
level, and devices as participants at a lower MLS level. Whether an
inactive user without devices joined is still considered a
participant.
Ensuring consistency across the system by having the MLS group
state, authorization policies, and participant lists all confirmed
together through the MLS key schedule.
Considering privacy aspects and whether pseudonyms could be used
while still allowing things like spam prevention, but acknowledging
pseudonyms would significantly complicate the protocol.
Mark Thompson then provided more details on the architecture
document and proposed protocol that was outlined in more depth.
At the end of the session, the group voted to adopt the current drafts
as working group documents.