[Mimi] Re: Call for adoption: draft-interop-mimi-discovery-requirements-01
Femi Olumofin <fgolu@google.com> Mon, 30 September 2024 20:13 UTC
Return-Path: <fgolu@google.com>
X-Original-To: mimi@ietfa.amsl.com
Delivered-To: mimi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6FCC1D6FD6 for <mimi@ietfa.amsl.com>; Mon, 30 Sep 2024 13:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfbX1pp_33EO for <mimi@ietfa.amsl.com>; Mon, 30 Sep 2024 13:13:26 -0700 (PDT)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0FDC1D876C for <mimi@ietf.org>; Mon, 30 Sep 2024 13:13:26 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-718d606726cso3405848b3a.3 for <mimi@ietf.org>; Mon, 30 Sep 2024 13:13:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1727727206; x=1728332006; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=KVP11r7XxVGQ3IZdi3XnUEqikpyZ1l/VrY/gT93PnbE=; b=SJImAMcOihYe8MD9SqPNluiGW7CY3SPSoWsfBMZe0n47NxnmQvMmigelcdYpoyA5tr Cl1tl905PQL3nIc5vmIT6Of+XuvgbQUreJnq8nLPkUSMS5nzSZiifVFBIz66znXocvQR i0R5AdrXxID2qKNLXg7Xpgdd1klzVNFXTJSfYlkGZv9VOHjOJl+fxKCdC7qfD2zWY7Gm lg0qCCuah50fqKNxvAy5e/vPlaY7qHtfBTW7XrHI3AkPhgB4tM4dB33+2nWyXy8++2ZQ KRzYwquzowxlLU/OaP7YiHQf1RQYV6pozMo+NbEt6/wfBGuFzdzZ6gXn1P/2oaqwUKqS Msew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727727206; x=1728332006; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=KVP11r7XxVGQ3IZdi3XnUEqikpyZ1l/VrY/gT93PnbE=; b=MvVDfSyq1h6nOAenP0b1V1n7Fisb0VCSi2HsF77j/gvmAo0+UleT9OtJJdecSXqXV/ mRru2b4WHRWe6y7LsGCHQK6AR2L5cz6Pewxts6C2htUm2pMPs7gd7lLMxUoJkkxIBvIC PcCWqpcsyhhD7J2NttjXOEdhvMIiBVmTX9RtvLxecV/tv7fJ6wseKtnYJzQvPlknt7ZU TWoJUb1JbF7KVKflzDnaF7oTjZuaF37DQBizjvSQIkxz2UX5HLW2pRZbiHgEG1Itu8VR 5nB3/TpAUkPGpQeLuRlMQT02V8oFCAN8PQopO8wnbZ5lxUjZcnD+xnqC+5dq/7ztJB0w 9Z7w==
X-Gm-Message-State: AOJu0YzomcNIuJHW4AKLVcUdFbU3Sk23/Hv0lq9InqlpK5TA1Xm3v9L1 cdB4Gau00CVdikZ4UfPo1vQcHEqOf4LtfYuy6ABSGkr67vbE9Yb/wY9ZqLV8AAHHy1YoIb+bmJI 0XzGwUQdV66YvguFC2K2/UTj96pT0be6LMttPASyser2ltNl87+BfAdI=
X-Google-Smtp-Source: AGHT+IEYfdC6EfKUISi7PEUxS/oyrOdIDcNsoIccEEqkf5EiGSM+5yLosSD1u/W9h7Y/qgSvbt86I46MqMKk1weci44=
X-Received: by 2002:a05:6a00:4f86:b0:710:50c8:ddcb with SMTP id d2e1a72fcca58-71b25f0a920mr14930046b3a.5.1727727205548; Mon, 30 Sep 2024 13:13:25 -0700 (PDT)
MIME-Version: 1.0
From: Femi Olumofin <fgolu@google.com>
Date: Mon, 30 Sep 2024 13:13:11 -0700
Message-ID: <CA+p_kVuQEBJz2oH0gQHjN2r0Toz6fahmF0_YvFwrXmpsU+pA2A@mail.gmail.com>
To: mimi@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005c1eb006235bd6a6"
Message-ID-Hash: TWP2DDG44DHVUUSB6ZMLG7SX66JCIMYG
X-Message-ID-Hash: TWP2DDG44DHVUUSB6ZMLG7SX66JCIMYG
X-MailFrom: fgolu@google.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Mimi] Re: Call for adoption: draft-interop-mimi-discovery-requirements-01
List-Id: More Instant Messaging Interoperability <mimi.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mimi/LvfLMw9Jbc7ppw9qkkqEts2GD64>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mimi>
List-Help: <mailto:mimi-request@ietf.org?subject=help>
List-Owner: <mailto:mimi-owner@ietf.org>
List-Post: <mailto:mimi@ietf.org>
List-Subscribe: <mailto:mimi-join@ietf.org>
List-Unsubscribe: <mailto:mimi-leave@ietf.org>
Hi Richard, Thank you for your comments. Please see my response below. Thanks, Femi --- > >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. We placed the terminology section before the introduction to improve readability. It seems awkward to use terms that are not yet defined, forcing readers to jump ahead to figure out what they mean. Is the placement a matter of personal preference or a requirement? >"A Cross-Service Identifier (CSI) is a globally unique identifier..." - The >"globally unique" seems aspirational here, and should probably be deleted. It isn't aspirational but required. Would it be mere aspiration for phone numbers and email addresses to be globally unique, for example? We take global uniqueness as a requirement. >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 Yes, the same CSI can be bound to multiple SSIs. However, we want to avoid the scenario you described, given that all mappings of the same CSI to multiple SSIs should be for a single user, Alice. BTW, we covered this during the IETF 120 session (check the deck). >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. The draft includes phone numbers and email addresses as examples of identifiers in several sections, including the abstract, terminology, introduction, authentication mappings requirements, and discovery protocol requirements. Section 8.1 also discusses suitable properties for identifiers in general (your new identifier mention). I'm having trouble understanding the specific issues you're raising about this. >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. This is a reference to the Introduction section, which appears before the problem statement is introduced. We intentionally simplified it there, with the "plurality" details explained in the Problem Statement section. >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. This is meant to help users build an intuition for the possible models. Moving the content to the appendix seems to defeat that goal, but I'm open to doing what works best. >It would be helpful to have a more fleshed-out model of the system, in a >more abstract way than Section 4 provides. Roughly: This feedback appears contradictory to your earlier comment that discussion about architectural models should be deleted or moved to the appendix. Here, you are asking for "a more fleshed-out model of the system". What exactly is the feedback? >* MSPs make DPs aware of authenticated SSI->CSI mappings The statement is incorrect. It is the DPs that authenticate mappings, which are then looked up by MSPs. >"* Clients/MSPs request SSI->CSI mappings from a DP (possibly different from >the DP in the previous step) I'm not sure exactly what you meant here because the details you outlined are already explained in the draft: "Note that once a mapping is created, it can be distributed by any DP, and it should include metadata for clients that receive it to verify its authenticity." And captured in Requirement #3 "Client, MSP, and DP must collaborate to generate a verifiable representation of the CSI-to-MSP mapping. This can then be shared with any DP and verifiable by clients". >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. Separation of concerns is desirable and appropriate in the CA-web server role separation. However, it seems unnecessary to have an artificial separation here simply because the same DP could collaboratively authenticate mappings and also distribute those mappings or mappings from other DPs. >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. We grouped the requirements into authenticating mappings, discovery protocol, operational, and security categories. When you say "requirements on the actors in the system", are you referring to those in the operational category? We would appreciate specifics to help us identify requirements that should be reclassified or removed. >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. Can you be specific about the additional privacy requirements that must be added? The stated requirements are the minimum bar.
- [Mimi] Re: Call for adoption: draft-interop-mimi-… Richard Barnes
- [Mimi] Re: Call for adoption: draft-interop-mimi-… Eric Rescorla
- [Mimi] Re: Call for adoption: draft-interop-mimi-… Femi Olumofin
- [Mimi] Call for adoption: draft-interop-mimi-disc… Alissa Cooper
- [Mimi] Re: Call for adoption: draft-interop-mimi-… Jonathan Rosenberg
- [Mimi] Re: Call for adoption: draft-interop-mimi-… Eric Rescorla