Some pseudonymous privacy flows for More Instant Messaging Interoperability (MIMI)
draft-mahy-mimi-pseudonyms-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Rohan Mahy | ||
| Last updated | 2024-08-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mahy-mimi-pseudonyms-00
More Instant Messaging Interoperability R. Mahy
Internet-Draft Rohan Mahy Consulting Services
Intended status: Informational 18 August 2024
Expires: 19 February 2025
Some pseudonymous privacy flows for More Instant Messaging
Interoperability (MIMI)
draft-mahy-mimi-pseudonyms-00
Abstract
The MIMI protocol has a baseline level of metadata privacy, which can
be made more private through the optional use of per-room pseudonyms.
This document describes three of many possible flows that use
pseudonyms for enhanced privacy. It also discusses some ways that
spam and abuse prevention mechanisms can work in conjunction with
pseudonyms.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://rohanmahy.github.io/mimi-pseudonyms/draft-mahy-mimi-
pseudonyms.html. Status information for this document may be found
at https://datatracker.ietf.org/doc/draft-mahy-mimi-pseudonyms/.
Discussion of this document takes place on the More Instant Messaging
Interoperability Working Group mailing list (mailto:mimi@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/mimi/.
Subscribe at https://www.ietf.org/mailman/listinfo/mimi/.
Source for this draft and an issue tracker can be found at
https://github.com/rohanmahy/mimi-pseudonyms.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Mahy Expires 19 February 2025 [Page 1]
Internet-Draft MIMI pseudonym privacy flows August 2024
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 February 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Example flows . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Connection flow . . . . . . . . . . . . . . . . . . . . . 4
3.2. Join link flow . . . . . . . . . . . . . . . . . . . . . 7
3.3. Knock flow . . . . . . . . . . . . . . . . . . . . . . . 9
4. Disclosing additional identity properties in an application
message . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Generic MLS Credential . . . . . . . . . . . . . . . . . 12
4.2. Selective Disclosure JSON Web Tokens . . . . . . . . . . 12
4.3. Selective Disclosure CBOR Web Tokens . . . . . . . . . . 12
5. Spam and Abuse prevention . . . . . . . . . . . . . . . . . . 13
5.1. Detection signals . . . . . . . . . . . . . . . . . . . . 13
5.2. Remedies . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Correlating anti-abuse actions across multiple
pseudonyms . . . . . . . . . . . . . . . . . . . . . . . 14
6. Implications with explicit consent mechanism . . . . . . . . 15
7. Other mechanism needed . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
Mahy Expires 19 February 2025 [Page 2]
Internet-Draft MIMI pseudonym privacy flows August 2024
1. Introduction
The More Instant Messaging Interoperability (MIMI) protocol
[I-D.ietf-mimi-protocol] defines a baseline mechanism of metadata
privacy with the following properties. Each local provider can know
which of its users are a participant in any given room, and the
domain of the hub. The hub provider knows the list of participants
for each room that it manages. Local/follower providers do not learn
the identity (or even the domain of) participants from other
providers as those users send handshakes and application messages,
unless the provider happens to also be the hub for the room.
There is also consensus that user can join rooms using a unique
pseudonym per room. The MIMI endpoints provided by the hub operate
equally well on pseudonyms as on "real" identities. However, there
are operational implications related to authorization, consent,
KeyPackage availability, credentials, spam/abuse mitigation, and
disclosure of the user's "real" identity. As a result there are
several possible ways of using pseudonyms that are compatible with
MIMI. This document describes three specific flows. Other flows and
other metadata privacy mechanisms are possible, some of which also
use pseudonyms, for example
[I-D.kohbrok-mimi-metadata-minimalization].
The flows described here include a connection-oriented flow, an out-
of-band join link flow, and a knock flow. A very high level summary
of each flow follows.
Connection flow:
* Each party obtains (typically single-use) pseudonyms
* Alice finds Bob, and connects with him from one of her pseudonyms
* Alice reveals her actual identity to Bob inside an end-to-end
encrypted channel, and provides a second pseudonym
* Bob connects to Alice from one of his pseudonyms to Alice's second
pseudonym.
Since the last step is based on a human delay which could vary from
seconds to years, the timing would be difficult to correlate between
a pair of providers with a large volume of traffic. If either
provider has a very small number of users, either provider could use
traffic analysis to associate the second room with Bob.
Out-of-band link flow:
Mahy Expires 19 February 2025 [Page 3]
Internet-Draft MIMI pseudonym privacy flows August 2024
* create a room link
* distribute the link out-of-band
* get the GroupInfo using the link
* join the room
* optionally reveal the "real" identity inside the room
Knock flow:
* a new users Cathy wants to join an established room. she uses a
pseudonym to externally join the associated "knock" room.
* Cathy provides a second pseudonym and KeyPackage inside the "knock
room", and immediately leaves the room
* later, an administrator of the room decides to add Cathy to the
room using the KeyPackage provided by Cathy.
This flow is substantially similar to the connection flow, except
that Cathy immediately leaves the "knock room", and the administrator
adds Cathy to an existing room (vs. Bob creating a new room).
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses MIMI terms defined in [I-D.ietf-mimi-arch] and
[I-D.ietf-mimi-protocol]. MIMI uses the Messaging Layer Security
(MLS) protocol extensively; the document uses several MLS terms
defined in [RFC9420].
3. Example flows
3.1. Connection flow
Initially Alice and Bob both request a number of pseudonyms (and
associated MLS credentials). They may upload KeyPackages for these
pseudonyms.
Mahy Expires 19 February 2025 [Page 4]
Internet-Draft MIMI pseudonym privacy flows August 2024
ClientA1 ServerA ServerB ClientB*
| | | |
| Request | | Request |
| pseudonyms | | pseudonyms |
+~~~~~~~~~~~~~~>| |<~~~~~~~~~~~~~~+
|<~~~~~~~~~~~~~~+ +~~~~~~~~~~~~~~>|
| | | |
| Store KPs | | Store KPs |
+~~~~~~~~~~~~~~>| |<~~~~~~~~~~~~~~+
| | | |
| ... | time passes | ... |
| | | |
Alice decides to connect to Bob. She creates a room in which to
bootstrap her private connection with Bob. She uses one of her
pseudonyms as her identifier in the new room. Alice searches for Bob
using his handle identifier. She requests KeyPackages for Bob's real
identity. Note that she may need consent to fetch his KeyPackages
(not shown), or Bob may grant blanket consent for connection rooms.
Alice adds Bob and Welcomes him to the new temporary room.
Alice now sends Bob an application message revealing her actual
identity, another of her pseudonyms, and optionally a list of her
KeyPackages from that pseudonym. In all likelihood, the user Bob
would not be presented with any indication that Alice wants to
connect until this point.
Mahy Expires 19 February 2025 [Page 5]
Internet-Draft MIMI pseudonym privacy flows August 2024
ClientA1 ServerA ServerB ClientB*
| | | |
| Create room | | |
+~~~~~~~~~~~~~~>| | |
| Add Alice's | | |
| other clients | | |
+~~~~~~~~~~~~~~>| | |
| | /idQuery | |
| +-------------->| |
| | 200 OK | |
| |<--------------+ |
| Request KPs | | |
+~~~~~~~~~~~~~~>| /keyMaterial | |
| +-------------->| |
| | 200 OK | |
| connect KPs |<--------------+ |
|<~~~~~~~~~~~~~~+ | |
| | | |
| Commit, etc. | | |
+~~~~~~~~~~~~~~>| | |
| Accepted | /notify | |
|<~~~~~~~~~~~~~~+-------------->| |
| | 200 OK | Welcome, Tree |
| Message |<--------------+~~~~~~~~~~~~~~>|
+~~~~~~~~~~~~~~>| | |
| | /notify | |
| +-------------->| |
| | 200 OK | |
| |<--------------+ |
| | | AliceID, KPs |
| | +~~~~~~~~~~~~~~>|
| | | |
| ... | time passes | ... |
| | | |
At some point, Bob accepts Alice's connection request. Bob creates a
new room using one of his pseudonyms. Bob adds Alice's clients to
the room using the provided KeyPackages. Bob can also add the rest
of his clients at the same time, assuming that Bob has a way to get
KeyPackages securely among his clients. Bob then sends a message to
Alice. The hub sees a room between two pseudonyms.
Mahy Expires 19 February 2025 [Page 6]
Internet-Draft MIMI pseudonym privacy flows August 2024
ClientA1 ServerA ServerB ClientB*
| | | |
| | | | Bob
| | | Create room | accepts
| | |<~~~~~~~~~~~~~~+
| | | |
| | | Commit, etc. |
| | |<~~~~~~~~~~~~~~+
| | /notify | |
| Welcome, Tree |<--------------+ |
|<~~~~~~~~~~~~~~+ | Message |
| | /notify |<~~~~~~~~~~~~~~+
| Message |<--------------+ |
|<~~~~~~~~~~~~~~+ | |
| | | |
Alice eventually destroys the bootstrap room, for example after a
random delay (not shown).
Alice and Bob can add each other to additional rooms by sending an
application message with a join link, as shown in the next flow.
The connection flow may be useful when the sender wants to initially
establish connectivity but does not have an out-of-band or third-
party channel to the receiver. On providers with a low volume of
flows or when relatively few flows use pseudonyms, this flow is
vulnerable to timing analysis. Between a pair of providers with
large volumes of new rooms using pseudonyms, this approach can be
very effective. This flow has the advantage that the initiator can
validate the real identity of the receiver before establishing any
type of communication. This may be useful when contacting a known
journalist, law-enforcement agent, rights-advocacy group, or
ombudsperson.
3.2. Join link flow
The join link flow is useful when two parties meet in person, have
another communications channel (possibly a different MIMI room), or
each is introduced via a trusted third-party over separate (typically
secure) communications channels.
This flow begins with Alice creating a new room from one of her
pseudonyms, adding her own clients to it, and the creating a join
link. Alice needs to have permissions to create a join link for this
step. Alice then sends the join link out-of-band to Bob. This could
include showing a QR code to Bob, or sending it to a trusted third-
party to give to Bob.
Mahy Expires 19 February 2025 [Page 7]
Internet-Draft MIMI pseudonym privacy flows August 2024
ClientA1 ServerA ServerB ClientB*
| | | |
| Create room | | |
+~~~~~~~~~~~~~~>| | |
| Add Alice's | | |
| other clients | | |
+~~~~~~~~~~~~~~>| | |
| Create join | | |
| link | | |
+~~~~~~~~~~~~~~>| | |
| | Send join | |
| | link OOB | |
+==============================================>|
| | | |
| ... | time passes | ... |
| | | |
Once Bob receives the join link, he fetches the GroupInfo for the
room and validates it, then joins the room.
As in the previous flow, Bob needs to collect KeyPackages from his
other clients and add them to the room (not shown).
Bob can also then reveal his actual identity to the other
participants of the room in an application message.
ClientA1 ServerA ServerB ClientB*
| | | |
| | | | Bob uses
| | | Use join link | join link
| | |<~~~~~~~~~~~~~~+
| | /groupInfo | |
| |<--------------+ |
| | OK GroupInfo | |
| |-------------->+ GroupInfo |
| | +~~~~~~~~~~~~~~>|
| | | Commit, etc. |
| | |<~~~~~~~~~~~~~~+
| | /notify | |
| Commit |<--------------+ |
|<~~~~~~~~~~~~~~+ | Message |
| | | Bob real ID |
| Message | /notify |<~~~~~~~~~~~~~~+
| Bob real ID |<--------------+ |
|<~~~~~~~~~~~~~~+ | |
| | | |
Mahy Expires 19 February 2025 [Page 8]
Internet-Draft MIMI pseudonym privacy flows August 2024
This powerful flow is only possibly when Alice and Bob have an out-
of-band channel, and when Alice has permissions to create a join link
in the target room. Note that if a malicious third-party is used,
the parties can still authenticate each other if they disclose their
actual identities inside the target room, but they would lose any
metadata privacy properties they had.
3.3. Knock flow
A new user Cathy is aware of a room that she wants to join. Likely
there is web page for the room with instructions for joining. The
page includes a related "knock room" which contains the moderators or
administrators of the target room. The "knock room" can be joined by
anyone, but by default each joiner can send one message to the admins
while regular users never receive application messages sent to the
group (although the client has the keying material needed to decrypt
the ciphertext if they receive it.)
Cathy sends a message with her KeyPackages for one of her pseudonyms.
She then leaves the "knock room".
Mahy Expires 19 February 2025 [Page 9]
Internet-Draft MIMI pseudonym privacy flows August 2024
ClientA1 ServerA ServerC ClientC*
| | | |
| | | | Cathy finds
| | | | "knock room"
| | | get GroupInfo |
| | |<~~~~~~~~~~~~~~+
| | /groupInfo | |
| |<--------------+ |
| | OK GroupInfo | |
| |-------------->+ GroupInfo |
| | +~~~~~~~~~~~~~~>|
| | | Commit, etc. |
| | |<~~~~~~~~~~~~~~+
| | /notify | |
| Commit |<--------------+ |
|<~~~~~~~~~~~~~~+ | App Message: |
| | | "Knock" |
| App Message: | | Real ID, KPs |
| "Knock" | /notify |<~~~~~~~~~~~~~~+
| Real ID, KPs |<--------------+ |
|<~~~~~~~~~~~~~~+ | Remove |
| | | Proposals | Cathy removes
| | |<~~~~~~~~~~~~~~+ herself
| Remove |<--------------+ |
|<~~~~~~~~~~~~~~+ | |
| | | |
| ... | time passes | ... |
| | | |
An administrator of the target room decides to add Cathy using the
KeyPackages she provided in the (related) "knock room".
ClientA1 ServerA ServerC ClientC*
| | | |
| Commit, etc. | | |
+~~~~~~~~~~~~~~>| | |
| Accepted | /notify | |
|<~~~~~~~~~~~~~~+-------------->| |
| | 200 OK | Welcome, Tree |
| |<--------------+~~~~~~~~~~~~~~>|
| | | |
This flow is ideal for joining an established affinity group. For
example, this method could be used by members of marginalized
communities. The perspective joiner needs to believe that the "knock
room" contains only moderators who will treat their join request in
confidence and not "out" them.
Mahy Expires 19 February 2025 [Page 10]
Internet-Draft MIMI pseudonym privacy flows August 2024
4. Disclosing additional identity properties in an application message
The concept of pseudonyms is of limited utility if the subject of the
pseudonym cannot disclose additional "real" identity properties as it
wishes. In the connection flow, Alice reveals her "real" identity
only to Bob; in the join link flow, Bob reveals aspects of his "real"
identity to the room; in the knock flow, Cathy reveals aspects of her
"real" identity to the moderators of her target room, and depending
on the policy of the target room she might reveal a different aspect
of her identity inside the target room.
The properties needed for safe and appropriate identity disclosure
include:
* The disclosure MUST be consistent with the room policy, which may
require disclosure of some elements, allow some elements to be
optionally disclosed, and may even forbid disclosure of other
elements. For example, a sexually explicit room might require
participants to disclose that they are at least a certain age, and
forbid the disclosure of postal addresses and family names.
* The issuer / authority MUST be known to every participant of the
room and trusted for the purpose of making identity assertions for
the domain(s) of the provider of the subject user.
* The signature key of the subject client in its MLS LeafNode MUST
be the same as the public key in the identity assertion.
* Whatever identity construction is used MUST be valid according the
rules for that construction.
* The presentation of the identity assertion MUST bind the
presentation to possession of the identity's private key (key
binding).
* The key binding SHOULD be scoped to a narrow and relevant audience
(for example the target room), and include other mechanisms to
prevent replay/ copy and paste attacks.
This document assumes that these disclosures happen to participants
of a room inside an application message, directly using an
appropriate media type (not necessarily inside a MIMI content
message). The next three subsections describe three such mechanisms.
Mahy Expires 19 February 2025 [Page 11]
Internet-Draft MIMI pseudonym privacy flows August 2024
4.1. Generic MLS Credential
MIMI describes its use with the MLS protocol [RFC9420]. If a new
media type application/mls-credential was defined, clients could send
the MLS Credential struct (possibly with the credential name as a
media type parameter.) The MLS struct is reproduced here:
struct {
CredentialType credential_type;
select (Credential.credential_type) {
case basic:
opaque identity<V>;
case x509:
Certificate certificates<V>;
};
} Credential;
For example, the client's MLS LeafNode could contain an MLS
Credential with an X.509 certificate with a subjectAltName URI that
corresponds to the pseudonym address of the client. The client could
then disclose to the room a different X.509 certificate with the same
issuer and public key which also reveals the "real" display name, and
email address of the user.
OpenID Connect UserInfo Verifiable Credentials (VCs) are another
proposed MLS Credential type [I-D.barnes-mls-addl-creds] with more
natural claims semantics.
4.2. Selective Disclosure JSON Web Tokens
While the use of JSON Web Tokens (JWT) [RFC7519] is widespread, most
uses do not require the holder/presenter to prove possession of a
private key as in [RFC9449]. Selective disclosure JWT (SD-JWT)
[I-D.ietf-oauth-selective-disclosure-jwt] describes both a way to
selectively disclose claims, it also include an optional presenter
key binding mechanism. The format uses the media type application/
sd+jwt.
This format could be used directly in MIMI with an appropriate
profile.
4.3. Selective Disclosure CBOR Web Tokens
Likewise, there are Selective Disclosure CBOR Web Tokens (SD-CWT)
[I-D.prorock-spice-cose-sd-cwt]. SD-CWT uses the media type
application/sd+cwt, and requires the use of its key binding mechanism
in presentations.
Mahy Expires 19 February 2025 [Page 12]
Internet-Draft MIMI pseudonym privacy flows August 2024
5. Spam and Abuse prevention
MIMI has a requirement to be able to prevent spam and other forms of
abuse. When using pseudonymous identities, there is naturally
concern that an account with many pseudonyms could be used to violate
room policy in the same room repeatedly or in multiple rooms with
impunity. This section explores some implementation options to
prevent this.
In a multi-provider messaging system, the hub provider is the only
provider that knows the room policy and therefore the only provider
that can decide if the policy is being violated. The local provider
will need to eventually cooperate with the hub provider in order to
prevent the same bad actor from violating policy repeatedly with
different pseudonyms.
5.1. Detection signals
There are several signals used for detection of spam or abuse. In
theory, an explicit abuse report should be a very strong signal of
abuse. However, an abuse report could be sent accidentally; it could
be the result of a misunderstanding about the policy in a room; or it
could have been sent maliciously. A report might be incorrectly
processed by an algorithm, or it might need to wait for a human
moderator to process it.
A ban or kick by a moderator or administrator of a group could also
be a strong signal, but an administrator might maliciously act
against someone they disagree with rather than someone who actually
violated policy. Since the motivation for the ban or kick is not
shared with the hub, the claim is also impossible to validate.
The hub may also use the rate or pattern of joining groups or sending
messages for one of its own users as an indicator of how spammy that
user is, but for users based on other providers it has no way to
correlate that information across pseudonyms.
5.2. Remedies
Once the hub suspects that a user has violated its policies, it has a
number of possible remedies. Some of these remedies require
cooperation with the local provider of that user.
Actions the hub can take independently:
* prevent the user from sending messages in a room
* remove the user from a room (kick)
Mahy Expires 19 February 2025 [Page 13]
Internet-Draft MIMI pseudonym privacy flows August 2024
* ban the user from a room (temporarily)
* ban the user from a room (permanently)
Actions requiring cooperation of the user's local provider
* suspend the account of the user
* suspend the account of the user and remove the user (including all
pseudonyms) from all rooms
* completely delete the account of the user
* suspend the account and any accounts deemed "related" (ex: used
the same email address or phone number)
* delete the account and any "related" accounts
Specifying an interface for reporting suspected abusive identities
from one provider to another is currently out-of-scope of the MIMI
charter and likely to be defined between providers or by a more
focussed standards developing organization, such as the Messaging
Anti-Abuse Working Group (M3AAWG).
5.3. Correlating anti-abuse actions across multiple pseudonyms
It is possible that the local provider for a user can lookup the
account associated with a specific user identity. This may be
straightforward, or the provider might implement a scheme where this
lookup is possible but requires extra technical or operational steps
and leaves evidence of the inquiry. This would be the moral
equivalent of breaking the pane of glass in some manual fire alarms.
In other implementations, perhaps no direct lookup is possible during
normal operation of the system, but an API could suspend of delete
the account associated with a particular pseudonym.
For some providers it may be operationally acceptable that only a
small number of pseudonyms can be created for a particular account.
There are also mechanisms such as searchable encryption and
homomorphic encryption, which allow searching for all the pseudonyms
with the same account id with a combined spam factor over a certain
threshold. Alternatively, a provider may use similar encryption
mechanisms but require a positive reputation threshold in order to
allow new pseudonyms to be created.
Mahy Expires 19 February 2025 [Page 14]
Internet-Draft MIMI pseudonym privacy flows August 2024
6. Implications with explicit consent mechanism
In many of the flows in this document, one user provides another with
a KeyPackage. In many cases the KeyPackages will be valid for
several weeks or months and most new rendezvous will be realized
during that time. However if a KeyPackage expires, the other party
may need explicit consent to fetch a new KeyPackage to replace the
expired one.
7. Other mechanism needed
This document describes some flows for effective, selectively
pseudonymous privacy. Use in a MIMI system requires a small amount
of additional specification and implementation. The author has
attempted to list this items according to whether they are in-scope
according to the MIMI charter.
Out of scope:
* A way for clients to obtain pseudonyms from their own providers
* Rate limiting pseudonym creation on a local provider
* Correlating pseudonyms with an account on a local provider (may or
may not be possible or necessary)
* A way for a client to obtain a join link from its provider
Assumed in scope:
* A way to indicate a KeyPackage is only valid for initial
connections
* A way for MIMI entities to recognize pseudonyms
* A way to examine the room policy about pseudonyms (required,
optional, forbidden), and if certain claims/elements are required,
optional, or forbidden.
* A format or convention to wrap additional credentials, or
disclosures of selective disclosure credentials inside a room,
along with KeyPackages, etc.
* Conventions for use of existing authorization and consent
primitives
* Conventions to make KeyPackages available appropriately
Mahy Expires 19 February 2025 [Page 15]
Internet-Draft MIMI pseudonym privacy flows August 2024
8. Security Considerations
TODO Security
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
[I-D.ietf-mimi-protocol]
Barnes, R., Hodgson, M., Kohbrok, K., Mahy, R., Ralston,
T., and R. Robert, "More Instant Messaging
Interoperability (MIMI) using HTTPS and MLS", Work in
Progress, Internet-Draft, draft-ietf-mimi-protocol-01, 8
July 2024, <https://datatracker.ietf.org/doc/html/draft-
ietf-mimi-protocol-01>.
[I-D.ietf-oauth-selective-disclosure-jwt]
Fett, D., Yasuda, K., and B. Campbell, "Selective
Disclosure for JWTs (SD-JWT)", Work in Progress, Internet-
Draft, draft-ietf-oauth-selective-disclosure-jwt-10, 8
July 2024, <https://datatracker.ietf.org/doc/html/draft-
ietf-oauth-selective-disclosure-jwt-10>.
[I-D.prorock-spice-cose-sd-cwt]
Prorock, M., Steele, O., and H. Birkholz, "Selective
Disclosure CWTs (SD-CWT)", Work in Progress, Internet-
Draft, draft-prorock-spice-cose-sd-cwt-01, 17 June 2024,
<https://datatracker.ietf.org/doc/html/draft-prorock-
spice-cose-sd-cwt-01>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
Omara, E., and K. Cohn-Gordon, "The Messaging Layer
Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.
Mahy Expires 19 February 2025 [Page 16]
Internet-Draft MIMI pseudonym privacy flows August 2024
10.2. Informative References
[I-D.barnes-mls-addl-creds]
Barnes, R. and S. Nandakumar, "Additional MLS
Credentials", Work in Progress, Internet-Draft, draft-
barnes-mls-addl-creds-01, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-barnes-mls-
addl-creds-01>.
[I-D.ietf-mimi-arch]
Barnes, R., "An Architecture for More Instant Messaging
Interoperability (MIMI)", Work in Progress, Internet-
Draft, draft-ietf-mimi-arch-00, 2 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-mimi-
arch-00>.
[I-D.kohbrok-mimi-metadata-minimalization]
Kohbrok, K. and R. Robert, "MIMI Metadata Minimalization
(MIMIMI)", Work in Progress, Internet-Draft, draft-
kohbrok-mimi-metadata-minimalization-00, 5 April 2024,
<https://datatracker.ietf.org/doc/html/draft-kohbrok-mimi-
metadata-minimalization-00>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.
Acknowledgments
TODO acknowledge.
Author's Address
Rohan Mahy
Rohan Mahy Consulting Services
Email: rohan.ietf@gmail.com
Mahy Expires 19 February 2025 [Page 17]