Re: [Mimi] Another discovery strawman

[Richard Barnes <[e-mail]>]

I think we're talking past each other a little bit here.  Let me try to
reset context from the top.

IIUC the following properties of the MIMI ecosystem are pretty well
established:
* Each user will have an SSI with each application they use
* Each SSI may be mapped to one or more SIIs
* The SSIs will have some encoding that represents both the user and the
application provider
* The SIIs may be of many types, e.g., E.164 addresses or email addresses
where the domain is not the application provider
* ... but what makes an SII an SII is that it does *not* indicate an
application provider, since it is service==provider-independent
* Resolving an SSI is straightforward; you just ask the application
provider indicated in the SSI for information about the user
* Resolving an SII is the "discovery" problem

Vittorio's draft confuses SSI resolution and SII resolution, and in any
case, the DNS isn't good for either.  For SSIs, as noted elsewhere in the
thread, it blurs the distinction between provider and user, and provides a
mediocre, 1980s-grade query interface.   For SIIs, in addition to the above
weaknesses, it would require mapping any SII namespace into the DNS, which
has already been tried for both E.164 numbers (ENUM, RFC 3761) and email
addresses (e.g., SMIMEA, RFC 8162), and failed to achieve traction in
either case.

So unless you really want to argue that DNS is a better query interface for
resolving (user, domain) identifiers than say WebFinger or some .well-known
thing, I don't think there's really a role for DNS to play here.  (Other
than serving boring old A records)

--Richard


On Fri, Sep 15, 2023 at 9:26 AM Eric Rescorla <[e-mail]> wrote:

>
>
> On Fri, Sep 15, 2023 at 5:38 AM Andrew Newton <[e-mail]> wrote:
>
>> On Thu, Sep 14, 2023 at 7:48 PM Eric Rescorla <[e-mail]> wrote:
>> >
>> >
>> >
>> > On Thu, Sep 14, 2023 at 9:57 AM Andrew Newton <[e-mail]> wrote:
>> >>
>> >> You had me until the "no CDNs" part. :) It does strike me that
>> >> WebFinger might be more appropriate than a new DNS RR for this use
>> >> case. That said, the attractiveness of this solution is that it
>> >> doesn't rely on "hope".
>> >
>> >
>> > In what way doesn't it rely on hope? It starts from the premise that
>> we're not going to use the main type of identifier (E.164 numbers) that are
>> used for the vast majority of messaging users.
>>
>> Users MAY have phone numbers, but they use contact lists.
>
>
> And those contact lists contain phone E.164 numbers.
>
>
> I agree that
>> if an SII can be ANY identifier then the DNS solution has issues, but
>> it is not clear (at least to me) that such a requirement exists.
>>
>
> Well, I'm not sure what would persuade you, but as the situation currently
> stands, a large fraction of the accounts with the current gatekeepers use
> E.164 identifiers, by which I mean that they are not only what people use
> to authenticate to the gatekeeper but how they address each other.
> It's hard to see how we can have a viable system that those gatekeepers
> adopt if we require them to change that.
>
> -Ekr
>
>
>
>