Internet-Draft ID Prover March 2024
Peterson Expires 5 September 2024 [Page]
Network Working Group
Intended Status:
Standards Track
J. Peterson

An Identitifier Proof-of-Possession Mechanism


This document specifies a means for a third-party service to prove and attest the association of a communications platform with a particular user's telephone number. This capability supports secure enrollment for users of messaging platforms or similar real-time communication applications, for cases where users assert telephone numbers as communication identifiers, and interoperating platforms need to verify that identifiers are being properly attested. This general approach can potentially work with other forms of Service Independent Identifiers (SIIs) in the More Instant Messaging Interoperability (MIMI) framework.

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

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 5 September 2024.

Table of Contents

1. Introduction

Many applications and platforms rely the receipt of a text message, typically a Short Messaging Service (SMS) (typically [SMPP]) message, to enable users to prove their control or ownership of a telephone number. During enrollment with a platform, services will send an SMS to the user's asserted telephone number containing a code or one-time URL; by interacting with that resource, the user proves receipt of the SMS, and thus validates the association of their telephone number with their account on that service. Resources sent via SMS may be used continually after enrollment as a two-factor authentication (TFA) systems.

While this mechanism may be sufficient to prove to the service in question that a user controls a telephone number, it does not help services prove to other services that users control telephone numbers and can legitimately assert them as identifiers in communications systems. For example, if Alice enrolls a telephone number with Platform A, and uses that telephone number as her identifier for a messaging service communicating with Bob on Platform B, Platform B has no way of validating how or if Platform A verified Alice's telephone number.

This issue arises in interoperable messaging systems that use Service Independent Identifiers (SIIs) as defined in [I-D.rosenberg-mimi-discovery-reqs], and in particular telephone numbers as SIIs. There is a need in interoperable messaging for users to be able to assert an SII as an identity, per [I-D.mahy-mimi-identity], in a way that multiple platforms can rely on. While this is often straightforward for Service Specific Identifiers (SSIs) of the form "", where clearly "" should can attest to the users of its service, it is more difficult for SIIs, as such identifiers are often not issued or controlled by the messaging platform. This specification thus describes a service that can be invoked by a communications platform to validate a platform user's control of an SII in order to create a publicly-verifiable credential asserting te platform's association with the SII. As prior work for X.509 credentials has been done along similar lines for ACME [RFC8555], this document builds on the existing ACME framework for telephone numbers [RFC9448].

This mechanism might be used to prove possession of SIIs other than telephone numbers, including email addresses. Moreover, this mechanism could be applied to proving identifiers for communications other than textual messaging, including most forms of real-time communications (e.g. STIR [RFC8224]). Note that the aim of this document is not to prove the assignment and delegation of resources in the telephone network: it is instead to establish whether Internet-enabled entites have effective control over the devices associated with those resources. Such credentials are not mutually exclusive with credentials delegated from national authorities.

Because the assignment of numbering resources can change over time, demonstrations of effective control must be regularly refreshed -- though because of the diverse capabilities of the devices involved, different schemes for refreshing the challenge, ones that require less direct user supervision, may be available to some devices and not others.

2. Terminology

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.

3. Overview of Operations

The following details the basic flow of this identity proving mechanism. Assume a case where a user, either a new user or an existing one updating their account, is interacting with a platform via an appp or over a web interface, and attempting to associate a new telephone number with their account. The exact methods that platforms use to communicate with users in steps 1, 2, and 6 below are outside the scope of this document.

At the end of this process, the platform has a certificate that could be to assert that SII identity in communication (per [I-D.mahy-mimi-identity]), as well as in support of various discovery functions as described in [I-D.rosenberg-mimi-discovery-reqs]. Any relying parties who trust the identity proving service can trust that the platform can assert the telephone number in question, and that the user of that SII is reachable at the platform. Subordinate certificates of various kinds could then be issued to the enrolling user by the platform for various end-to-end security functions.

4. ACME Behavior

New-order requests issued by platforms to ACME servers in this specification MUST utilize the TNAuthList ACME identifier type [RFC9448], with a TNAuthList value of a single telephone number. From there, the ACME flow follows that of [RFC8823], although it uses a new ACME challenge type identifier here, "sms-link-00."

  "type": "sms-link-00",

A client's response to this challenge simply acknowledges that it is ready to receive the validation SMS from the server.

On receiving a response, the identity proving service sends an SMS message to the TN being validated containing a code that the client must have a user access in order to complete the challenge. This code is intended to be relayed to the platform to complete the ACME challenge. By allowing a user action to complete the challenge, this validation method supports the use of ACME with SMS endpoints that do not support automated response to challenges; handset support for automated responses to these challenges is outside the scope of this document. The use of six-digit numeric codes is however weidely supported for automatic responses on handsets today.

5. Example


6. Acknowledgments

This document incorporates ideas and text from [I-D.ietf-acme-telephone]. Thanks as well go to Jonathan Rosenberg for his work on these ideas.

7. IANA Considerations


8. Privacy Considerations


9. Security Considerations


10. References

10.1. Normative References

Barnes, R. L., "An Architecture for More Instant Messaging Interoperability (MIMI)", Work in Progress, Internet-Draft, draft-barnes-mimi-arch-03, , <>.
Peterson, J. and R. Barnes, "ACME Identifiers and Challenges for Telephone Numbers", Work in Progress, Internet-Draft, draft-ietf-acme-telephone-01, , <>.
Mahy, R., "More Instant Messaging Interoperability (MIMI) Identity Concepts", Work in Progress, Internet-Draft, draft-mahy-mimi-identity-02, , <>.
Rosenberg, J., "MIMI Discovery Requirements and Considerations", Work in Progress, Internet-Draft, draft-rosenberg-mimi-discovery-reqs-00, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, , <>.
Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, , <>.
Melnikov, A., "Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates", RFC 8823, DOI 10.17487/RFC8823, , <>.
Wendt, C., Hancock, D., Barnes, M., and J. Peterson, "TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token", RFC 9448, DOI 10.17487/RFC9448, , <>.

10.2. Informative References

SMS Forum v5.0 | 19 February 2003, "Short Message Peer to Peer Protocol Specification", .

Author's Address

Jon Peterson