]> Rohan Mahy Consulting Services

rohan.ietf@gmail.com

Applications and Real-Time More Instant Messaging Interoperability identity This document explores the problem space in instant messaging (IM) identity interoperability when using end-to-end encryption, for example with the MLS (Message Layer Security) Protocol. It also describes naming schemes for different types of IM identifiers. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the More Instant Messaging Interoperability Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The IETF began standardization work on interoperable Instant Messaging in the late 1990s, but since that period, the typical feature set of these systems has expanded widely and was largely driven by the industry without much standardization or interoperability. The More Instant Messaging Interop (MIMI) Working Group (see ) was chartered to develop protocols for IM interoperability using end-to-end encryption with the MLS protocol and architecture (). The largest and most widely deployed Instant Messaging (IM) systems support end-to-end message encryption using a variant of the Double Ratchet protocol popularized by Signal and the companion X3DH key agreement protocol. Many vendors have also implemented MLS for IM. These protocols provide confidentiality of sessions (with Double Ratchet) and groups (with MLS) once the participants in a conversation have been identified. However, the current state of most systems require the end user to manually verify key fingerprints or blindly trust their instant messaging service not to add and remove participants from their conversations. This problem is exacerbated when these systems federate or try to interoperate. Even systems that have some type of Key Transparency are essentially Trust On First Use (TOFU). While some single vendor solutions exist, clearly an interoperable mechanism for IM identity is needed. This document builds on the roles described in . First this document attempts to articulate a clear description and semantics of different identifiers used in IM systems. Next the document provides an example of how to represent those identifiers in a common way. Then the document discusses different trust approaches. Finally the document surveys various cryptographic methods of making and verifying assertions about these identifiers. Arguably, as with email, the success of XMPP was partially due to the ease of communicating among XMPP users in different domains with different XMPP servers, and a single standardized address format for all XMPP users. The goal of this document is to explore the problem space, so that the IETF community can write a consensus requirements document and framework.

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 when, and only when, they appear in all capitals, as shown here.

Types of Identifiers IM systems have a number of types of identifiers. Few (or perhaps no) systems use every type of identifier described here. Not every configuration of the same application necessarily use the same list of identifiers.

Domain identifier:

A bare domain name is often used for discovery of a specific IM service such as example.com or im.example.com. Many proprietary IM systems operate in a single domain and have no concept of domains or federation.

Handle identifier:

A handle is an identifier which represents a user or service. A handle is usually intended for external sharing (for example it could appear on or in a paper or electronic business card). IM systems could have handles which are unscoped (don't contain a domain) or scoped (contain a domain). Unscoped handles are often prefixed with a commercial at-sign ("@"). Handles in some services are mutable. For example, @alice_smith could become @alice_jones or @alex_smith after change of marital status or gender transition.

Protocol	Identifier Address	Example
Jabber/XMPP	Bare JID	juliet@example.com
SIP	Address of Record (AOR)	sip:juliet@example.com
IRC	nick	@juliet
Generic example	"unscoped handle"	@juliet
Generic example	"scoped handle"	@juliet@example.com
Email style	Mailbox address	juliet@example.com

Table: some Handle identifier styles

User or account identifier:

Many systems have an internal representation of a user, service, or account separate from the handle. This is especially useful when the handle is allowed to change. Unlike the handle, this identifier typically cannot change. For example the user identifier could be a UUID or a similar construction. In IRC, a user identifier is prefixed with a "!" character (example: !jcapulet1583@example.com for the "nick" @juliet).

Client or Device identifier:

Most commercial instant messaging systems allow a single user to have multiple devices at the same time, for example a desktop computer and a phone. Usually, each client instance of the user is represented with a separate identifier with separate keys. Typically these identifiers are internal and not visible to the end-user (XMPP fully qualified JIDs are a rare exception). The client or device identifier is often based on a UUID, a persistent long-term unique identifier like an IMEI or MAC address, a sequence number assigned by the IM service domain, or a combination. In some cases the identifier may contain the internal user identifier. These identifiers look quite different across protocols and vendors.

Protocol	Identifier Address	Example
Jabber/XMPP	Fully-qualified JID	juliet/balcony@example.com
SIP	Contact Address	sip:juliet@[2001:db8::225:96ff:fe12:3456]
Wire	Qualified client ID	0fd3e0dc-a2ff-4965-8873-509f0af0a75c/072b@example.com

Table: some Client/Device identifier styles.

Group Chat or Channel identifier (external):

All or nearly all instant messaging systems have the concept of named groups or channels which support more than 2 members and whose membership can change over time. Many IM systems support an external identifier for these groups and allows them to be addressed. In IRC and many other systems, they are identified with a "#" (hash-mark) prefix. The proliferation of hashtags on social media makes this convention less common on newer systems.

Group, Conversation, or Session identifiers (internal):

Most IM protocols use an internal representation for a group or 1:1 chat. In MLS this is called the group_id. The Wire protocol uses the term qualified conversation ID to refer to a group internally across domains. Among implementations of the Double Ratchet family of protocols a unidirectional sequence of messages from one client to another is referred to as a session, and often has an associated session identifier.

Team or Workspace identifier:

A less common type of identifier among IM systems is used to describe a set of users or accounts. This is described variously as a team, workspace, or tenant.

One user often has multiple clients (for example a mobile and a desktop client). A handle usually refers to a single user or rarely it may redirect to multiple users. In some systems, the user identifier is a handle. In other systems the user identifier is an internal representation, for example a UUID. Handles may be changed/renamed, but hopefully internal user identifiers do not. Likewise, group conversation identifiers could be internal or external representations, whereas group names or channel names are often external friendly representations. It is easy to imagine a loose hierarchy between these identifiers (domain to user to device), but hard to agree on a specific fixed structure. In some systems, the group chat or session itself has a position in the hierarchy underneath the domain, the user, or the device. As described in the next section, the author proposes using URIs as a container for interoperable IM identifiers. All the examples use the mimi: URI scheme described in . While other URI schemes could be used inside IM systems, the distinction between each type of identifier is implicit rather than explicit. Other schemes are fine within a closed system, as long as the comparison and validation rules are clear.

Representation of identifiers using URIs Most if not all of the identifiers described in the previous section could be represented as URIs. While individual instant messaging protocol-specific URI schemes may not have been specified with this use of URIs in mind, the mimi: URI scheme is flexible enough to represent all of or any needed subset of the previously discussed identifiers. For example, the XMPP protocol can represent a domain, a handle (bare JID), or a device (fully qualified JID). Unfortunately its xmpp: URI scheme was only designed to represent handles and domains, but the mimi: URI scheme can represent all XMPP identifiers:

• mimi://example.com (domain only)
• mimi://example.com/u/juliet (bare JID - handle)
• mimi://example.com/d/juliet/balcony (fully qualified JID - client/device)

Likewise the IRC protocol can represent domain, handle (nick), user (account), and channel. The examples below represent a domain, a nick, a user, a local channel, and the projectX channel.

• mimi://irc.example.com
• mimi://irc.example.com/u/juliet
• mimi://irc.example.com/u/jcapulet1583@example.com
• mimi://irc.example.com/r/local_announcements_channel
• mimi://irc.example.com/r/projectX

The first path segment in a MIMI URI discriminates the type of identifier and makes the type of resource unambiguous types of MIMI URI identifiers

id type	example URI
Provider	mimi://a.example
User	mimi://a.example/u/alice
Pseudonym	mimi://a.example/p/crazykoala75
Client	mimi://a.example/d/ClientA1 or mimi://a.example/d/alice/ClientA1
Room	mimi://a.example/r/clubhouse
MLS group	mimi://a.example/g/TII9t5viBrXiXc
Team	mimi://a.example/t/engineering

A Pseudonym is a user identifier that is designed to conceal the identity of its user, but may or may not wish to reveal its pseudonymous nature. In that way a pseudonym could be represented with a first path segment as a User or as Pseudonym, according to local policy.

• Note that if there is no domain, a URI scheme could use local.invalid in place of a resolvable domain name.

Different Root of Trust Approaches Different IM applications and different users of these applications may have different trust needs. The following subsections describe three specific trust models for example purposes. Note that the descriptions in this section use certificates in their examples, but nothing in this section should preclude using a different technology which provides similar assertions.

Centralized credential hierarchy In this environment, end-user devices trust a centralized authority operating on behalf of their domain (for example, a Certificate Authority), that is trusted by all the other clients in that domain (and can be trusted by federated domains). The centralized authority could easily be associated with a traditional Identity Provider (IdP). This is a popular trust model for companies running services for their own employees and contractors. This is also popular with governments providing services to their employees and contractors or to residents or citizens for whom they provide services. For example XYZ Corporation could make an assertion that "I represent XYZ Corporation and this user demonstrated she is Alice Smith of the Engineering department of XYZ Corporation." In this model, a Certificate Authority (CA) run by or on behalf of the domain generates certificates for one or more of the identifier types described previously. The specifics of the assertions are very important for interoperability. Even within this centralized credential hierarchy model, there are at least three ways to make assertions about different types of IM identifiers with certificates:

Example 1 (Separate Certs):

The CA generates one certificate for a user Alice which is used to sign Alice's profile. The CA also generates a separate certificate for Alice's desktop client and a third for her phone client. The private key in each client certificate is used to sign MLS KeyPackages or Double Ratchet-style prekeys.

Example 2 (Single Combined Cert):

The CA generates a single certificate per client which covers both Alice's handle and her client identifier in the same certificate. The private key in each of these certificates is used to sign MLS KeyPackages or Double Ratchet-style prekeys. Note that there is no separate key pair used to refer to the user distinct from a device. All the legitimate device key pairs would be able to sign on behalf of the user.

Example 3 (Cascading Certs):

The CA generates a single user certificate for Alice's handle and indicates that the user certificate can issue its own certificates. The user certificate then generates one certificate for Alice's desktop client and another certificate for Alice's phone client. The private key in each client certificate is used to sign MLS KeyPackages or Double Ratchet-style prekeys.

What is important in all these examples is that other clients involved in a session or group chat can validate the relevant credentials of the other participants in the session or group chat. Clients would need to be able to configure the relevant trust roots and walk any hierarchy unambiguously. When using certificates, this could include associating an Issuer URI in the issuerAltName with one of the URIs in the subjectAltName of another cert. Other mechanisms have analogous concepts. Regardless of the specific implementation, this model features a strong hierarchy. The advantage of this approach is to take advantage of a strong hierarchy which is already in use at an organization, especially if the organization is using an Identity Provider (IdP) for most of its services. Even if the IM system is compromised, the presence of client without the correct end-to-end identity would be detected immediately. The disadvantage of this approach is that if the CA colludes with a malicious IM system or both are compromised, an attacker or malicious IM system can easily insert a rogue client which would be as trusted as a legitimate client.

Web of Trust In some communities, it may be appropriate to make assertions about IM identity by relying on a web of trust. The following specific example of this general method is used by the OMEMO community presented by and proposed in . This document does not take any position on the specifics of the proposal, but uses it to illustrate a concrete implementation of a web of trust involving IM identifiers. The example uses a web of trust with cross signing as follows:

• Each user (Alice and Bob) has a master key.
• Alice's master key signs exactly two keys:
  • Alice's device-signing key (which then signs her own device keys), and
  • Alice's user-signing key (which can sign the master key of other users).

The advantage of this approach is that if Alice's and Bob's keys, implementations, and devices are not compromised, there is no way the infrastructure can forge a key for Alice or Bob and insert an eavesdropper or active attacker. The disadvantages of this approach are that this requires Alice's device-signing key to be available any time Alice wants to add a new device, and Alice's user-signing key to be available anytime she wants to add a new user to her web of trust. This could either make those operations inconvenient and/or unnecessarily expose either or both of those keys. | master | +--------+ \/: +--------+ / \ / \___ / \ / \ / : \ / \ +---------+ +---------+ +---------+ +---------+ | device | | user | :| user | | device | | signing | | signing | :| signing | | signing | +---------+ +---------+ :+---------+ +---------+ / \ : / \ +----+ +----+ : +----+ +----+ | A1 | | A2 | : | B1 | | B2 | +----+ +----+ : +----+ +----+ ]]> Figure: Alice and Bob cross sign each other's master keys A detailed architecture for Web of Trust key infrastructure which is not specific to Instant Messaging systems is the Mathematical Mesh .

Well-known service cross signing In this trust model, a user with several services places a cross signature for all their services at a well known location on each of those services (for example a personal web site .well-known page, an IM profile, the profile page on an open source code repository, a social media About page, a picture sharing service profile page, a professional interpersonal-networking site contact page, and a dating application profile). This concept was perhaps first implemented for non-technical users by Keybase. The user of this scheme likely expects that at any given moment there is a risk that one of these services is compromised or controlled by a malicious entity, but expects the likelihood of all or most of their services being compromised simultaneously is very low. The advantage of this approach is that it does not rely on anyone but the user herself. This disadvantage is that if an attacker is able to delete or forge cross signatures on a substantial number of the services, the forged assertions would looks as legitimate as the authentic assertions (or more convincing).

Combining approaches These different trust approaches could be combined, however the verification rules become more complicated. Among other problems, implementers need to decide what happens if two different trust methods come to incompatible conclusions. For example, what should the application do if web of trust certificates indicate that a client or user should be trusted, but a centralized hierarchy indicates a client should not be, or vice versa.

Cryptographic mechanisms to make assertions about IM identifiers

X.509 Certificates X.509 certificates are a mature technology for making assertions about identifiers. The supported assertions and identifier formats used in certificates are somewhat archaic, inflexible, and pedantic, but well understood. The semantics are always that an Issuer asserts that a Subject has control of a specific public key key pair. A handful of additional attributes can be added as X.509 certificate extensions, although adding new extensions is laborious and time consuming. In practice new extensions are only added to facilitate the internals of managing the lifetime, validity, and applicability of certificates. X.509 extensions are not appropriate for arbitrary assertions or claims about the Subject. The Subject field contains a Distinguished Name, whose Common Name (CN) field can contain free form text. The subjectAltName can contain multiple other identifiers for the Subject with types such as a URI, email address, DNS domain names, or Distinguished Name. The rules about which combinations of extensions are valid are defined in the Internet certificate profile described in . As noted in a previous section of this document, URIs are a natural container for holding instant messaging identifiers. Implementations need to be careful to insure that the correct semantics are applied to a URI, as they may be referring to different objects (ex: a handle versus a client identifier). There is a corresponding issuerAltName field as well. Certificates are already supported in MLS as a standard credential type which can be included in MLS LeafNodes and KeyPackages.

• In the X3DH key agreement protocol (used with Double Ratchet), the first message in a session between a pair of clients can contain an optional certificate, but this is not standardized.

Arguably the biggest drawback to using X.509 certificates is that administratively it can be difficult to obtain certificates for entities that can also generate certificates---specifically to issue a certificate with the standard extension basicContraints=CA:TRUE. Figure: mocked up IM client certificate with both client id and handle If implementing cascading certificates, the Issuer might be a expressed as a URI in the issuerAltName extension. Figure: mocked up IM client certificate issued by the domain for the handle URI as Subject. Then another certificate issued by the handle URI for the device URI as its Subject.

JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) JSON Web Signing (JWS) and JSON Web Tokens (JWT) are toolkits for making a variety of cryptographic claims. (CBOR Web Tokens are semantically equivalent to JSON Web Tokens.) Both token types are an appealing option for carrying IM identifiers and assertions, as the container type is flexible and the format is easy to implement. Unfortunately the semantics for validating identifiers are not as rigorously specified as for certificates at the time of this writing, and require additional specification work. The JWT Demonstrating Proof of Possession (DPoP) specification adds the ability to make claims which involve proof of possession of a (typically private) key, and to share those claims with third parties. The owner of a the key generates a proof which is used to fetch an access token which can then be verified by a third party. JWT DPoP was actually created as an improvement over Bearer tokens used for authentication, so its use as a certificate-like assertion may require substantial clarification and possibly additional profile work. While there is support for token introspection, in general access tokens need online verification between resources and the token issuer. Figure: JOSE header and claims sections of a JWT DPoP proof referring to an IM URI Finally, there are selective disclosure variants of JWTs and CWTs available. Selective Disclosure JWTs (SD-JWT) have an optional key binding mechanism. Selective Disclosure CWTs (SD-CWT) have a mandatory Key Binding Token (KBT). Both can be used directly as MLS credentials .

Verifiable Credentials Verifiable Credentials (VC) is a framework for exchanging machine-readable credentials . The framework is well specified and has a very flexbile assertion structure, which in addition to or in place of basic names and identifiers, can optionally include arbitrary attributes (ex: security clearance, age, nationality) up to and including selective disclosure depending on the profile being used. For example, a verifiable credential could be used to assert that an IM client belongs to a Customer Support agent of Sirius Cybernetic Corp, who speaks English and Vogon, and is qualified to give support for their Ident-I-Eeze product, without revealing the name of the agent. The VC specification describes both Verifiable Credentials and Verifiable Presentations. A Verifiable Credential contains assertions made by an issuer. Holders assemble credentials into a Verifiable Presentation. Verifiers can validate the Verifiable Credentials in the Verifiable Presentation. Specific credential types are defined by referencing ontologies. The example at the end of this section uses the VCard ontology . Most of the examples for Verifiable Credentials and many of the implementations by commercial identity providers use Decentralized Identifiers (DIDs), but there is no requirement to use DID or the associated esoteric cryptography in a specific VC profile. (Indeed the VC profile for COVID-19 for vaccination does not use DIDs). The most significant problem with VCs are that there is no off-the-shelf mechanism for proof of possession of a private key, and no consensus to use VCs for user authentication (as opposed to using VCs to assert identity attributes). While the examples in this document are represented as JSON, including whitespace, the actual JSON encoding used for VC has no whitespace. The first example shows a fragment of the claims in a JWT-based VC proof, referencing the VCard ontology. Figure: fragment of example VC claims using VCard ontology In the next example, there is a Verifiable Presentation (VP) JOSE header and claims which contains two embedded VCs for the same holder. The JOSE header contains an actual Ed25519 public key. The corresponding key id could be expressed using the kid type with a urn:ietf:params:oauth:jwk-thumbprint:sha-256: prefix, the actual fingerprint value would be mJafqNxZWNAIkaDGPlNyhccFSAqnRjhyA3FJNm0f8I8. The first VC contains a full name and a handle-style identifier. It is created by one issuer (for example an identity provider), and uses standard claims from OpenID Connect Core. The second VC contains a client or device identifier and is created by a different issuer (the IM service). Note that in the text version of this document, the jws values and verification Method URLs are truncated. Figure: Example VP with 2 embedded VCs

Other possible mechanisms Below are other mechanisms which were not investigated due to a lack of time.

• Anonymous credential schemes which can present attributes without the long-term identity (ex: travel agent for specific team) such as those generated by the Privacy Pass Architecture , or Anonymous Credit Tokens . .- Zero-knowledge proofs - new work is starting in the IETF to define JSON Web Proofs (JWP) , a new format that uses zero knowledge proofs (with both JSON and CBOR formats).
• Deniable credentials

IANA Considerations This document requires no action by IANA.

Security Considerations TBC. (The threat model for interoperable IM systems depends on many subtle details).

References Normative References Cisco The More Instant Messaging Interoperability (MIMI) working group is defining a suite of protocols that allow messaging providers to interoperate with one another. This document lays out an overall architecture enumerating the MIMI protocols and how they work together to enable an overall messaging experience. Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Cisco The Matrix.org Foundation C.I.C. Phoenix R&D Rohan Mahy Consulting Services The Matrix.org Foundation C.I.C. Phoenix R&D This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. Authlete Keio University Ping Identity This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. mesur.io Transmute Fraunhofer SIT Rohan Mahy Consulting Services This specification describes a data minimization technique for use with CBOR Web Tokens (CWTs). The approach is based on the Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE) and CWTs. Rohan Mahy Consulting Services The Messaging Layer Security (MLS) protocol contains Credentials used to authenticate an MLS client with a signature key pair. Selective Disclosure CBOR Web Tokens (SD-CWT) and Selective Disclosure JSON Web Tokens (SD-JWT) define token formats where the holder can selectively reveal claims about itself with strong integrity protection and cryptographic binding to the holder's key. This document defines MLS credentials for both these token types. Informative References UC Berkeley UC Berkeley Signal Signal Signal Signal Element The Messaging Layer Security (MLS) protocol (RFC 9420) provides a group key agreement protocol for messaging applications. MLS is designed to protect against eavesdropping, tampering, and message forgery, and to provide forward secrecy (FS) and post-compromise security (PCS). This document describes the architecture for using MLS in a general secure group messaging infrastructure and defines the security goals for MLS. It provides guidance on building a group messaging system and discusses security and privacy trade-offs offered by multiple security mechanisms that are part of the MLS protocol (e.g., frequency of public encryption key rotation). The document also provides guidance for parts of the infrastructure that are not standardized by MLS and are instead left to the application. While the recommendations of this document are not mandatory to follow in order to interoperate at the protocol level, they affect the overall security guarantees that are achieved by a messaging application. This is especially true in the case of active adversaries that are able to compromise clients, the Delivery Service (DS), or the Authentication Service (AS). This document defines the terminology and interaction patterns involved in the deployment of Key Transparency in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non- prescriptive guidance on how to securely apply Key Transparency to a number of common applications. Cisco Rohan Mahy Consulting Service End-to-end (E2E) security is a critical property for modern user communications systems. E2E security protects users' communications from tampering or inspection by intermediaries that are involved in delivering those communcations from one logical endpoint to another. In addition to the much-discussed E2E encryption systems, true E2E security requires an identity mechanism that prevents the communications provider from impersonating participants in a session, as a way to gain access to the session. This document describes a high-level architecture for E2E identity, identifying the critical mechanisms that need to be specified. The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK] ThresholdSecrets.com The Mathematical Mesh is a Threshold Key Infrastructure that makes computers easier to use by making them more secure. Application of threshold cryptography to key generation and use enables users to make use of public key cryptography across multiple devices with minimal impact on the user experience. This document provides an overview of the Mesh data structures, protocols and examples of its use. [Note to Readers] Discussion of this draft takes place on the MATHMESH mailing list (mathmesh@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- architecture.html. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model, to help ensure that the desired security and privacy goals are fulfilled. Google Google This document specifies Anonymous Credit Tokens (ACT), a privacy- preserving authentication protocol that enables numerical credit systems without tracking individual clients. Based on keyed- verification anonymous credentials and privately verifiable BBS-style signatures, the protocol allows issuers to grant tokens containing credits that clients can later spend anonymously with that issuer. The protocol's key features include: (1) unlinkable transactions - the issuer cannot correlate credit issuance with spending, or link multiple spends by the same client, (2) partial spending - clients can spend a portion of their credits and receive anonymous change, and (3) double-spend prevention through cryptographic nullifiers that preserve privacy while ensuring each token is used only once. Anonymous Credit Tokens are designed for modern web services requiring rate limiting, usage-based billing, or resource allocation while respecting user privacy. Example applications include rate limiting and API credits. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. Ping Identity Self-Issued Consulting Ping Identity The JOSE set of standards established JSON-based container formats for Keys, Signatures, and Encryption. They also established IANA registries to enable the algorithms and representations used for them to be extended. Since those were created, newer cryptographic algorithms that support selective disclosure and unlinkability have matured and started seeing early market adoption. The COSE set of standards likewise does this for CBOR-based containers, focusing on the needs of environments which are better served using CBOR, such as constrained devices and networks. This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) and COSE Signed Messages called a _JSON Web Proof (JWP)_. Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a protected header to prevent replay.

Acknowledgments The author wishes to thank Richard Barnes, Tom Leavy, Joel Alwen, Marta Mularczyk, Pieter Kasselman, and Rifaat Shekh-Yusef for discussions about this topic.