An Identitifier Proof-of-Possession Mechanism

Many applications and platforms rely the receipt of a text message, typically a Short Messaging Service (SMS) (typically ) 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 , 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 , in a way that multiple platforms can rely on. While this is often straightforward for Service Specific Identifiers (SSIs) of the form "user@example.com", where clearly "example.com" 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 , this document builds on the existing ACME framework for telephone numbers . 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). 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.

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.

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. A user enrolling with a communications platform asserts their ownership of the telephone number to the platform The platform instructs the user to await an SMS with a code Simultaneously, the platform contacts an ACME server with a new order for that telephone number The ACME server issues a challenge to the platform that requires a code to complete In parallel, the ACME server also sends an SMS with the code to the asserted telephone number (without sharing that code with the platform) Upon receipt of the code, the user inputs the code to the communications platform The platform then responds to the ACME challenge with the code Provided the challenge is correctly answered, the ACME platform issues the certificate to the communications platform At the end of this process, the platform has a certificate that could be to assert that SII identity in communication (per ), as well as in support of various discovery functions as described in . 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.

New-order requests issued by platforms to ACME servers in this specification MUST utilize the TNAuthList ACME identifier type , with a TNAuthList value of a single telephone number. From there, the ACME flow follows that of , although it uses a new ACME challenge type identifier here, "sms-link-00." type (required, string): The string "sms-link-00" token (required, string): A random value that uniquely identifies the challenge. This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it. It MUST NOT contain any characters outside the URL-safe Base64 alphabet and MUST NOT contain any padding characters ("=").

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.

TBD.

This document incorporates ideas and text from . Thanks as well go to Jonathan Rosenberg for his work on these ideas.

TBD.