[Mimi] Re: Call for adoption: draft-interop-mimi-discovery-requirements-01

[Eric Rescorla <[e-mail]>]

BLUF
I don't think this is ready.  I recognize that this is just a starting
point and the authors have put in a fair amount of work here, but I
think this does need to be somewhat closer to the right thing before
we adopt it.


I share many of Richard's reservations about the document structure.
More broadly, I just think much of the document is at the wrong
altitude, addressing specific implementation techniques (in some
cases rooted in some IMO misguided architectural ideas) rather
than focusing on the actual externally visible requirements.

For example in S 6.1.

   3.  The client, MSP, and DP must collaborate to generate a verifiable
       representation of the CSI-to-MSP mapping (e.g., using a threshold
       signature).  The can then be shared with any DP and verifiable by
       clients.

This is a specific attempt to implement some binding properties, but what
are those properties actually? I believe it's that:

- There is a user who has been assigned a given CSI
- That user also has an account at the given MSP [and something
  about the MSP knowing about the CSI].

Note that it's somewhat hard to precisely state these because in some
designs the CSI -> SSI mapping is actually only attested to by the
MSP. (As an aside, it would actualy be nice if the document came down
on if tht's OK).

In any case, it's not clear that the client, MSP, and DP need to
collaborate in order to generate a verifiable representation, and
it's odd to mention something as detailed as threshold signatures
here. Similarly, it's not clear that a "proof of possession"
(see S 6) is quite what is needed here; I would typically not think
of OAuth as PoP.

Many of the rest of the requirements are also too detailed. For
instance S 7.1. is a sketch of a design for a system, rather than
really a set of requirements.

   3.  The total length of tags should be limited within the protocol.

   4.  If a CSI's set of mappings lacks a default mapping or multiple
       mappings have the "Default" tag, the recipient can choose any of
       the mappings for communication.


On the other hand, privacy has been the topic of a lot of discussion,
but the text here is fairly sketchy:

   Discovered mappings must be verifiable to ensure they are accurate.
   Crucially, discovery must prioritize user privacy, allowing users to
   control their discoverability, and it must integrate well with end-
   to-end encryption and other MIMI protocols.

OOTH S 8.4. doesn't talk about concealing mappings at all, so are
they public or not?


I think this document would benefit from being a lot shorter and
just focusing on the actual high level requirements of the system
rather than trying to get into how they are implemented. I would
suggest going back to Richard's sketched split authentication/discovery
architecture and trying to frame requirements with that as a reference.
I'd like to see that or something else happen before adoption. Otherwise,
I fear that there will be an implicit presumption that this structure
is correct and it will be hard to fix later.



On Thu, Sep 26, 2024 at 11:19 AM Richard Barnes <[e-mail]> wrote:

> Hi all,
>
> I have reviewed this document.  I think it's a reasonable starting point,
> though I have some reservations about its structure and content.  Comments
> below.
>
> --Richard
>
> Traditionally, the Terminology section goes after the Introduction.  It's
> a little abrupt  to land right there after the abstract.
>
> "A Cross-Service Identifier (CSI) is a globally unique identifier..." -
> The "globally unique" seems aspirational here, and should probably be
> deleted.  It seems like you could definitely have cases where the same CSI
> is bound to completely unrelated SSIs, for example:
> 1. Alice is assigned a given E.164 number
> 2. Alice registers the number with Service A
> 3. Alice surrenders the number and it is reassigned to Bob
> 4. Bob registers the number with Service B
>
> This document is very agnostic about what the CSIs are, but practically
> speaking, we're only talking about email addresses and phone numbers.
> Would there be benefit to specializing to those two?  Even if we also have
> a section about what would have to be done to accommodate a new identifier
> type.
>
> There are a few instances where more plurals are needed, for example,
> "learn the messaging service provider that the user is using" -- the user
> could be registered to multiple MSPs with the same CSI.
>
> While I appreciate the desire to capture the WG discussions about
> architectural models, these seem out of place in a requirements document,
> except possibly for building intuition about possible models.  I would
> probably move Section 4 to an appendix or delete it.
>
> It would be helpful to have a more fleshed-out model of the system, in a
> more abstract way than Section 4 provides.  Roughly:
> * MSPs make DPs aware of authenticated SSI->CSI mappings
> * Clients/MSPs request SSI->CSI mappings from a DP (possibly different
> from the DP in the previous step)
>
> In prior discussions we had made a distinction between entities who are
> trusted to *authenticate* mappings and those who *distribute* the
> mappings.  This document seems to assign both of those roles to a DP.  It
> seems worthwhile to separate them, since it seems plausible that there
> could be a system where the two roles are played by different entities,
> much like CAs and web servers in HTTPS.
>
> The requirements in Section 5 are a mix of requirements on the discovery
> protocol, over which this WG has full control, and requirements on the
> actors in the system outside the protocol, about which we can only be
> advisory.  It would be good to separate these out, and ideally focus on the
> former.
>
> The privacy requirements in section 8.4 seem very underdeveloped compared
> to what has been discussed in the working group.  In part, I suspect,
> because of the lack of a model of who does what here makes it hard to talk
> about who can be denied which information.
>
>
>
>
> On Wed, Sep 18, 2024 at 12:40 PM Alissa Cooper <[e-mail]> wrote:
>
>> We are issuing a WG adoption call for MIMI Discovery Requirements,
>> draft-interop-mimi-discovery-requirements-01 [1]. This document would be
>> the starting point for the WG to fulfill its "user discovery requirements
>> document” milestone. [2] Please respond to the list by the end of your day
>> on Wednesday, September 25 to indicate if you support or oppose WG adoption
>> of this draft.
>>
>> Thanks,
>> Alissa
>>
>> [1]
>> https://www.ietf.org/archive/id/draft-interop-mimi-discovery-requirements-01.html
>> [2] https://datatracker.ietf.org/group/mimi/about/
>> --
>> Mimi mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
> --
> Mimi mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>