Docs : Added Provisioning and Protocomm related docs

Co-Authored-By: Amey Inamdar <amey@espressif.com>
Co-Authored-By: Anurag Kar <anurag.kar@espressif.com>

docs/Doxyfile

@@ -99,6 +99,19 @@ INPUT = \
     ../../components/esp_http_client/include/esp_http_client.h \
     ../../components/http_server/include/http_server.h \
     ##
+    ## Provisioning - API Reference
+    ##
+    ## Protocol Communication
+    ../../components/protocomm/include/common/protocomm.h \
+    ../../components/protocomm/include/security/protocomm_security.h \
+    ../../components/protocomm/include/security/protocomm_security0.h \
+    ../../components/protocomm/include/security/protocomm_security1.h \
+    ../../components/protocomm/include/transports/protocomm_ble.h \
+    ../../components/protocomm/include/transports/protocomm_console.h \
+    ../../components/protocomm/include/transports/protocomm_httpd.h \
+    ## WiFi Provisioning
+    ../../components/wifi_provisioning/include/wifi_provisioning/wifi_config.h \
+    ##
     ## Storage - API Reference
     ##
     ## SPI Flash and Partition APIs

docs/_static/unified_provisioning.xml

@@ -0,0 +1 @@
+<mxfile userAgent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36" version="8.4.8" editor="www.draw.io" type="device"><diagram id="9337f294-c11b-1f31-aa11-c60915e486ba" name="Page-1">7Zxtc6I6FMc/jTN7X+wOSXjQl/jU7dz21lm67b6NkGpmkTARa7uf/gYBFU/streAK72+UQ8kyO+cnJx/ADtksHi6kDSeX4uAhR1sBE8dMuxgjExiqLfU8pxZHKebGWaSB5nJ2Bk8/ovlLQvrigdsmdsyUyJEmPC4bPRFFDE/KdmolGJd3u1BhEHJENMZAwbPpyG03vMgmWfWLrZ39q+Mz+bFkZHdy7ZMqf9zJsUqyo/XweRh88o2L2jRV36iyzkNxHrPREYdMpBCJNmnxdOAhSnbMrbxka3b3y1ZlLymAc4aPNJwlZ/6yJt8vhyO85+XPBdINifF0maoQ/rrOU+YF1M/3bpWQaBs82QR5psfeBgORCjkpi1xewNz1Ff2/GhMJuzp6C9GWw4qvphYsEQ+q13yBmZOLo8sqyC53vnJsXPbfM9HRTuah8Zs2/MOj/qQE9LTIjpayuCuAi7U+5A9slDEi/RUsDGWdMHWQv5Unz+5w/FfHWyH6tf0p1J9miUbHh/HUlU8RSJSO/WXiRQ/2V6QGZuX2kKln2cUo5aQwz3rdSGHkfX+mDNBzF2zgFNl+upeVTpKA4t1A1OHtounxLargWmVYW6nij2YCPUgTKeC8WsBlsXI9RLJ6GIJ4/bTJfY6eJAOZ64gqz2flwlbZKavt7eTdFTTRUo2mi7jmmO/MS+hYsJ+0U1OPW7S5FmAMJ1k46MnmtcFdFrsbrw5TIuuCgAW+gKHPdYN+92e74GA4MC/ubh4U3AZbw4uVahg39cFV2BPbevVwZV58CjczwiXswCCaLs2JFtFPkWw5HG/396cJUZsOJCbZlBWwg0mz5vJd+8suSFN0VhbvPUAt/GVOzhLbsRsLty6cJim1FqR/gqOL2S/mrBCqvfuXaUMq6pPXp37mofoAIjXE9IKiJoqr7YBDos8bzIa/TjLAX1Yz+g41jW/wGh0r7+dJcWDtNhgMNqQYS4MByJgvkYXns+6SMUZA5UzhjLodFFXo4sc8n5HvSDhJzxmIVcMzk9tH6yJkC6ssyxCIFFiV0AU5g8vZsyfK9s35otZlHARaRZG7txhtgryN3teCxls9+dpA+1iZ4WOqSonvc0xxcrE/ioI0SxWWbgCx8BazWPykfvsP6ejs+OPegf1CYYjAxuambUSB0Dl1r9V3108nJyJEHmZ7naNqaBrEk0ur6twKab3PbzDq3/cVpAlhnFKsghOklzGIX1uBVwQtla3SbgYwL1XsyVNWsEWBG6zbI9dYJ0wyeM5kzSstRT/04vz3xQrvcMyEnqupxNQqIIyksDLFbdilVaRtY6KhurzXjnjmAQ3OSqg5umvkkRXlLeBreM0yRYqf2+Yyn6aCpo24jUbxQvF5T3/PObtRGs3mhWgPIRUy7cnXUYJkw8pQ6jmPb6IQ/7AFXHVYHL5ypuVKlSUzTjNROXr+jpFiRwMfVaFoiRQUU5UVc5kS2GDikQr31E9sE2oLwehWKXx/d51lHOpLmu8Ja48ipDTA47V3hKHUAX3B5lQgk2kSIQv/pcHx11mH66lNSkPTKjsWrPY4xikXAc4doN1gAmFV5/yYAXRDldM3njtmFjsEvHtBbxS+tFMK6gC3lCNDRmL+5LyqFKSDa2wW+h0KDWXXRf0l07YuiF7oq24pIFPCVxzr8AR4FfqBNuAmxSrJ6fADSXahRCzUKO/7gTXyTJ3ueTLhEZvW1z+U31hEud0voDSq/CFMeQ0FLNxKNZnCPXwRvUmoVpQYrkhn9IpPUOQ9ilBwit2tyvJo9kZcnRQ93QcYTEMCLIocNNHRDtb2bVHDJBxRq49MrZbiqdByZYVC8CjpL8ltX9fj+4BktwmWUgT/ljuXocnP8JE8M2Dh9vHcA8CuosPH0xZipX0Wd5uh/n3XRn2YVcJlTOWgK42Htue+uucCCvsj+tEpZu+WFW5UdNZrY6E9f3HdaSJzeocqemsVkdC3fBxHWkbFY5ITWe1OlJ30eijOtIxetU5UtNZhY5UX3f/CZHtvvvjDTL6Fw==</diagram></mxfile>

docs/conf_common.py

@@ -132,6 +132,9 @@ nwdiag_fontpath = '../_static/DejaVuSans.ttf'
 rackdiag_fontpath = '../_static/DejaVuSans.ttf'
 packetdiag_fontpath = '../_static/DejaVuSans.ttf'
 
+# Enabling this fixes cropping of blockdiag edge labels
+seqdiag_antialias = True
+
 # Breathe extension variables
 
 # Doxygen regenerates files in 'xml/' directory every time,

docs/en/api-reference/index.rst

@@ -11,6 +11,7 @@ API Reference
    Ethernet <ethernet/index>
    Peripherals <peripherals/index>
    Protocols <protocols/index>
+   Provisioning <provisioning/index>
    Storage <storage/index>
    System <system/index>
    Configuration Options <kconfig>

docs/en/api-reference/provisioning/index.rst

@@ -0,0 +1,11 @@
+Provisioning API
+****************
+
+.. toctree::
+   :maxdepth: 1
+
+   Unified Provisioning <provisioning>
+   Protocol Communication <protocomm>
+   Wi-Fi Provisioning <wifi_provisioning>
+
+Example code for this API section is provided in :example:`provisioning` directory of ESP-IDF examples.

docs/en/api-reference/provisioning/protocomm.rst

@@ -0,0 +1,169 @@
+Protocol Communication
+======================
+
+Overview
+--------
+Protocol Communication (protocomm) component manages secure sessions and provides framework for multiple transports. The application can also use protocomm layer directly to have application specific extensions for the provisioning (or non-provisioning) use cases.
+
+Following features are available for provisioning :
+    * Communication security at application level -
+        * protocomm_security0 (no security)
+        * protocomm_security1 (curve25519 key exchange + AES-CTR encryption)
+    * Proof-of-possession (support with protocomm_security1 only)
+
+Protocomm internally uses protobuf (protocol buffers) for secure session establishment. Though users can implement their own security (even without using protobuf). One can even use protocomm without any security layer.
+
+Protocomm provides framework for various transports - WiFi (SoftAP+HTTPD), BLE, console - in which case the handler invocation is automatically taken care of on the device side (see Transport Examples below for code snippets).
+
+Note that the client still needs to establish session (only for protocomm_security1) by performing the two way handshake. See :doc:`provisioning` for more details about the secure handshake logic.
+
+Transport Example (SoftAP + HTTP) with Security 1
+-------------------------------------------------
+For complete example see :example:`provisioning/softap_prov`
+
+    .. highlight:: c
+
+    ::
+
+        /* Endpoint handler to be registered with protocomm.
+         * This simply echoes back the received data. */
+        esp_err_t echo_req_handler (uint32_t session_id,
+                                    const uint8_t *inbuf, ssize_t inlen,
+                                    uint8_t **outbuf, ssize_t *outlen,
+                                    void *priv_data)
+        {
+            /* Session ID may be used for persistence */
+            printf("Session ID : %d", session_id);
+
+            /* Echo back the received data */
+            *outlen = inlen;            /* Output data length updated */
+            *outbuf = malloc(inlen);    /* This will be deallocated outside */
+            memcpy(*outbuf, inbuf, inlen);
+
+            /* Private data that was passed at the time of endpoint creation */
+            uint32_t *priv = (uint32_t *) priv_data;
+            if (priv) {
+                printf("Private data : %d", *priv);
+            }
+
+            return ESP_OK;
+        }
+
+        /* Example function for launching a protocomm instance over HTTP */
+        protocomm_t *start_pc(const char *pop_string)
+        {
+            protocomm_t *pc = protocomm_new();
+
+            /* Config for protocomm_httpd_start() */
+            protocomm_httpd_config_t pc_config = PROTOCOMM_HTTPD_DEFAULT_CONFIG();
+
+            /* Start protocomm server on top of HTTP */
+            protocomm_httpd_start(pc, &pc_config);
+
+            /* Create Proof of Possession object from pop_string. It must be valid
+             * throughout the scope of protocomm endpoint. This need not be static,
+             * ie. could be dynamically allocated and freed at the time of endpoint
+             * removal */
+            const static protocomm_security_pop_t pop_obj = {
+                .data = (const uint8_t *) strdup(pop_string),
+                .len = strlen(pop_string)
+            };
+
+            /* Set security for communication at application level. Just like for
+             * request handlers, setting security creates an endpoint and registers
+             * the handler provided by protocomm_security1. One can similarly use
+             * protocomm_security0. Only one type of security can be set for a
+             * protocomm instance at a time. */
+            protocomm_set_security(pc, "security_endpoint", &protocomm_security1, &pop_obj);
+
+            /* Private data passed to the endpoint must be valid throughout the scope
+             * of protocomm endpoint. This need not be static, ie. could be dynamically
+             * allocated and freed at the time of endpoint removal */
+            static uint32_t priv_data = 1234;
+
+            /* Add a new endpoint for the protocomm instance, identified by a unique name
+             * and register a handler function along with private data to be passed at the
+             * time of handler execution. Multiple endpoints can be added as long as they
+             * are identified by unique names */
+            protocomm_add_endpoint(pc, "echo_req_endpoint",
+                                   echo_req_handler, (void *) &priv_data);
+            return pc;
+        }
+
+        /* Example function for stopping a protocomm instance */
+        void stop_pc(protocomm_t *pc)
+        {
+            /* Remove endpoint identified by it's unique name */
+            protocomm_remove_endpoint(pc, "echo_req_endpoint");
+
+            /* Remove security endpoint identified by it's name */
+            protocomm_unset_security(pc, "security_endpoint");
+
+            /* Stop HTTP server */
+            protocomm_httpd_stop(pc);
+
+            /* Delete (deallocate) the protocomm instance */
+            protocomm_delete(pc);
+        }
+
+Transport Example (BLE) with Security 0
+---------------------------------------
+For complete example see :example:`provisioning/ble_prov`
+
+    .. highlight:: c
+
+    ::
+
+        /* Example function for launching a secure protocomm instance over BLE */
+        protocomm_t *start_pc()
+        {
+            protocomm_t *pc = protocomm_new();
+
+            /* Endpoint UUIDs */
+            protocomm_ble_name_uuid_t nu_lookup_table[] = {
+                {"security_endpoint", 0xFF51},
+                {"echo_req_endpoint", 0xFF52}
+            };
+
+            /* Config for protocomm_ble_start() */
+            protocomm_ble_config_t config = {
+                .service_uuid = {
+                    /* LSB <---------------------------------------
+                    * ---------------------------------------> MSB */
+                    0xfb, 0x34, 0x9b, 0x5f, 0x80, 0x00, 0x00, 0x80,
+                    0x00, 0x10, 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00,
+                },
+                .nu_lookup_count = sizeof(nu_lookup_table)/sizeof(nu_lookup_table[0]),
+                .nu_lookup = nu_lookup_table
+            };
+
+            /* Start protocomm layer on top of BLE */
+            protocomm_ble_start(pc, &config);
+
+            /* For protocomm_security0, Proof of Possession is not used, and can be kept NULL */
+            protocomm_set_security(pc, "security_endpoint", &protocomm_security0, NULL);
+            protocomm_add_endpoint(pc, "echo_req_endpoint", echo_req_handler, NULL);
+            return pc;
+        }
+
+        /* Example function for stopping a protocomm instance */
+        void stop_pc(protocomm_t *pc)
+        {
+            protocomm_remove_endpoint(pc, "echo_req_endpoint");
+            protocomm_unset_security(pc, "security_endpoint");
+
+            /* Stop BLE protocomm service */
+            protocomm_ble_stop(pc);
+
+            protocomm_delete(pc);
+        }
+
+API Reference
+-------------
+
+.. include:: /_build/inc/protocomm.inc
+.. include:: /_build/inc/protocomm_security.inc
+.. include:: /_build/inc/protocomm_security0.inc
+.. include:: /_build/inc/protocomm_security1.inc
+.. include:: /_build/inc/protocomm_httpd.inc
+.. include:: /_build/inc/protocomm_ble.inc

docs/en/api-reference/provisioning/provisioning.rst

@@ -0,0 +1,154 @@
+Unified Provisioning
+^^^^^^^^^^^^^^^^^^^^
+
+Overview
+>>>>>>>>
+Unified provisioning support in the ESP-IDF provides an extensible mechanism to the developers to configure the device with the Wi-Fi credentials and/or other custom configuration using various transports and different security schemes. Depending on the use-case it provides a complete and ready solution for Wi-Fi network provisioning along with example iOS and Android applications. Or developers can extend the device-side and phone-app side implementations to accommodate their requirements for sending additional configuration data. Following are the important features of this implementation.
+
+1. *Extensible Protocol:* The protocol is completely flexible and it offers the ability for the developers to send custom configuration in the provisioning process. The data representation too is left to the application to decide.
+2. *Transport Flexibility:* The protocol can work on Wi-Fi (SoftAP + HTTP server) or on BLE as a transport protocol. The framework provides an ability to add support for any other transport easily as long as command-response behaviour can be supported on the transport. 
+3. *Security Scheme Flexibility:* It's understood that each use-case may require different security scheme to secure the data that is exchanged in the provisioning process. Some applications may work with SoftAP that's WPA2 protected or BLE with "just-works" security. Or the applications may consider the transport to be insecure and may want application level security. The unified provisioning framework allows application to choose the security as deemed suitable.
+4. *Compact Data Representation:* The protocol uses `Google Protobufs <https://developers.google.com/protocol-buffers/>`_ as a data representation for session setup and Wi-Fi provisioning. They provide a compact data representation and ability to parse the data in multiple programming languages in native format. Please note that this data representation is not forced on application specific data and the developers may choose the representation of their choice.
+
+Typical Provisioning Process
+>>>>>>>>>>>>>>>>>>>>>>>>>>>>
+.. seqdiag::
+    :caption: Typical Provisioning Process
+    :align: center
+
+    seqdiag typical-prov-process {
+        activation = none;
+        node_width = 80;
+        node_height = 60;
+        edge_length = 360;
+        span_height = 5;
+        default_shape = roundedbox;
+        default_fontsize = 12;
+
+        CLIENT  [label = "Client"];
+        DEVICE  [label = "Device"];
+
+        === 1. Transport specific discovery and connection ===
+        DEVICE -> CLIENT [label="Some form of beaconing"];
+        CLIENT -> DEVICE [label="Client connects"];
+        === 2. Session Establishment ====
+        CLIENT -> DEVICE [label="Get Version Request"];
+        DEVICE -> CLIENT [label="Get Version Response"];
+        CLIENT -> DEVICE [label="Session Setup Request"];
+        DEVICE -> CLIENT [label="Session Setup Response"];
+        CLIENT --> DEVICE;
+        ... One or multiple steps as per protocol ...
+        DEVICE --> CLIENT
+        === 3. Configuration ===
+        CLIENT --> DEVICE [label="App specific Set Config (optional)"];
+        DEVICE --> CLIENT [label="Set Config Response (optional)"];
+        CLIENT -> DEVICE [label="Wi-Fi SetConfig(SSID, Passphrase...)"];
+        DEVICE -> CLIENT [label="Wi-Fi SetConfig response"];
+        CLIENT -> DEVICE [label="Wi-Fi ApplyConfig cmd"];
+        DEVICE -> CLIENT [label="Wi-Fi ApplyConfig resp"];
+        CLIENT -> DEVICE [label="Wi-Fi GetStatus cmd (repeated)"];
+        DEVICE -> CLIENT [label="Wi-Fi GetStatus resp (repeated)"];
+        === 4. Close connection ===
+        DEVICE -> CLIENT [label="Close Connection"];
+    }
+
+Deciding on Transport
+>>>>>>>>>>>>>>>>>>>>>
+Unified provisioning subsystem supports Wi-Fi (SoftAP+HTTP server) and BLE (GATT based) transport schemes. Following points need to be considered while selecting the best possible transport for provisioning.
+
+1. BLE based transport has an advantage that in the provisioning process, the BLE communication channel stays intact between the device and the client. That provides reliable provisioning feedback.
+2. BLE based provisioning implementation makes the user-experience better from the phone apps as on Android and iOS both, the phone app can discover and connect to the device without requiring user to go out of the phone app
+3. BLE transport however consumes ~110KB memory at runtime. If the product does not use the BLE or BT functionality after provisioning is done, almost all the memory can be reclaimed back and can be added into the heap.
+4. SoftAP based transport is highly interoperable; however as the same radio is shared between SoftAP and Station interface, the transport is not reliable in the phase when the Wi-Fi connection to external AP is attempted. Also, the client may roam back to different network when the SoftAP changes the channel at the time of Station connection.
+5. SoftAP transport does not require much additional memory for the Wi-Fi use-cases
+6. SoftAP based provisioning requires the phone app user to go to "System Settings" to connect to Wi-Fi network hosted by the device in case of iOS. The discovery (scanning) as well as connection API is not available for the iOS applications.
+
+Deciding on Security
+>>>>>>>>>>>>>>>>>>>>
+Depending on the transport and other constraints the security scheme needs to be selected by the application developers. Following considerations need to be given from the provisioning security perspective:
+1. The configuration data sent from the client to the device and the response has to be secured.
+2. The client should authenticate the device it is connected to.
+3. The device manufacturer may choose proof-of-possession - a unique per device secret to be entered on the provisioning client as a security measure to make sure that the user can provisions the device in the possession.
+
+There are two levels of security schemes. The developer may select one or combination depending on requirements.
+
+1. *Transport Security:* SoftAP provisioning may choose WPA2 protected security with unique per-device passphrase. Per-device unique passphrase can also act as a proof-of-possession. For BLE, "just-works" security can be used as a transport level security after understanding the level of security it provides.
+2. *Application Security:* The unified provisioning subsystem provides application level security (*security1*) that provides data protection and authentication (through proof-of-possession) if the application does not use the transport level security or if the transport level security is not sufficient for the use-case.
+
+Device Discovery
+>>>>>>>>>>>>>>>>
+The advertisement and device discovery is left to the application and depending on the protocol chosen, the phone apps and device firmware application can choose appropriate method to advertise and discovery.
+
+For the SoftAP+HTTP transport, typically the SSID (network name) of the AP hosted by the device can be used for discovery.
+
+For the BLE transport device name or primary service included in the advertisement or combination of both can be used for discovery.
+
+Architecture
+>>>>>>>>>>>>
+The below diagram shows architecture of unified provisioning.
+
+.. figure:: ../../../_static/unified_provisioning.png
+    :align: center
+    :alt: Unified Provisioning Architecture
+
+    Unified Provisioning Architecture
+
+It relies on the base layer called :doc:`protocomm` (Protocol Communication) which provides a framework for security schemes and transport mechanisms. Wi-Fi Provisioning layer uses Protocomm to provide simple callbacks to the application for setting the configuration and getting the Wi-Fi status. The application has control over implementation of these callbacks. In addition application can directly use protocomm to register custom handlers.
+
+Application creates a protocomm instance which is mapped to a specific transport and specific security scheme. Each transport in the protocomm has a concept of an "end-point" which corresponds to logical channel for communication for specific type of information. For example security handshake happens on a different endpoint than the Wi-Fi configuration endpoint. Each end-point is identified using a string and depending on the transport internal representation of the end-point changes. In case of SoftAP+HTTP transport the end-point corresponds to URI whereas in case of BLE the end-point corresponds to GATT characteristic with specific UUID. Developers can create custom end-points and implement handler for the data that is received or sent over the same end-point.
+
+Security Schemes
+>>>>>>>>>>>>>>>>
+At present unified provisioning supports two security schemes:
+1. Security0 - No security (No encryption)
+2. Security1 - Curve25519 based key exchange, shared key derivation and AES256-CTR mode encryption of the data. It supports two modes :
+
+    a. Authorized - Proof of Possession (PoP) string used to authorize session and derive shared key
+    b. No Auth (Null PoP) - Shared key derived through key exchange only
+
+Security1 scheme details are shown in the below sequence diagram
+
+.. seqdiag::
+    :caption: Security1
+    :align: center
+
+    seqdiag security1 {
+        activation = none;
+        node_width = 80;
+        node_height = 60;
+        edge_length = 480;
+        span_height = 5;
+        default_shape = roundedbox;
+        default_fontsize = 12;
+
+        CLIENT  [label = "Client"];
+        DEVICE  [label = "Device"];
+
+        === Security 1 ===
+        CLIENT -> CLIENT [label = "Generate\nKey Pair", rightnote = "{cli_privkey, cli_pubkey} = curve25519_keygen()"];
+        CLIENT -> DEVICE [label = "SessionCmd0(cli_pubkey)"];
+        DEVICE -> DEVICE [label = "Generate\nKey Pair", leftnote = "{dev_privkey, dev_pubkey} = curve25519_keygen()"];
+        DEVICE -> DEVICE [label = "Initialization\nVector", leftnote = "dev_rand = gen_16byte_random()"];
+        DEVICE -> DEVICE [label = "Shared Key", leftnote = "shared_key(No PoP) = curve25519(dev_privkey, cli_pubkey) \nshared_key(with PoP) = curve25519(dev_privkey, cli_pubkey) ^ SHA256(pop)"];
+        DEVICE -> CLIENT [label = "SessionResp0(dev_pubkey, dev_rand)"];
+        CLIENT -> CLIENT [label = "Shared Key", rightnote = "shared_key(No PoP) = curve25519(cli_privkey, dev_pubkey)\nshared_key(with PoP) = curve25519(cli_privkey, dev_pubkey) ^ SHA256(pop)"];
+        CLIENT -> CLIENT [label = "Verification\nToken", rightnote = "cli_verify = aes_ctr_enc(key=shared_key, data=dev_pubkey, nonce=dev_rand)"];
+        CLIENT -> DEVICE [label = "SessionCmd1(cli_verify)"];
+        DEVICE -> DEVICE [label = "Verify Client", leftnote = "check (dev_pubkey == aes_ctr_dec(cli_verify...)"];
+        DEVICE -> DEVICE [label = "Verification\nToken", leftnote = "dev_verify = aes_ctr_enc(key=shared_key, data=cli_pubkey, nonce=(prev-context))"];
+        DEVICE -> CLIENT [label = "SessionResp1(dev_verify)"];
+        CLIENT -> CLIENT [label = "Verify Device", rightnote = "check (cli_pubkey == aes_ctr_dec(dev_verify...)"];
+    }
+
+Sample Code
+>>>>>>>>>>>
+Please refer to :doc:`protocomm` and :doc:`wifi_provisioning` for API guides and code snippets on example usage.
+
+Various use case implementations can be found as examples under :example:`provisioning`.
+
+Provisioning Tools
+>>>>>>>>>>>>>>>>>>
+
+A python based provisioning tool is provided under `$IDF_PATH/tools/esp_prov`, intended for use along with the examples under :example:`provisioning`.
+
+For android, a provisioning tool along with source code is available on Github as `esp-idf-provisioning-android <https://github.com/espressif/esp-idf-provisioning-android>`_

docs/en/api-reference/provisioning/wifi_provisioning.rst

@@ -0,0 +1,60 @@
+Wi-Fi Provisioning
+==================
+
+Overview
+--------
+
+This component provides protocomm endpoint handler - `wifi_prov_config_data_handler` - and related protobuf framework which can be used for Wi-Fi configuration in the context of device provisioning, though it may be used in non-provisioning cases as well. The configuration consists of three commands :
+    * `get_status` - For querying the Wi-Fi connection status
+    * `set_config` - For setting the Wi-Fi connection credentials
+    * `apply_config` - For applying the credentials saved during `set_config` and (re)start the Wi-Fi station
+
+The way this is supposed to work is that the desired Wi-Fi configuration for the ESP32, which is to run as a station and thus connect to an AP with certain credentials, is to be sent during `set_config`. Then `apply_config` is supposed to start (or restart) the Wi-Fi in station mode with the previously set AP credentials. Afterwords, `get_config` command is used to probe the device continuously for Wi-Fi connection status, to ensure that the connection was indeed successful. If the connection failed, then appropriate status code along with disconnection reason, is to be conveyed through `get_config`.
+
+Application Example
+-------------------
+
+    .. highlight:: c
+
+    ::
+
+        esp_err_t get_status_handler(wifi_prov_config_get_data_t *resp_data)
+        {
+            /* Fill the wifi_prov_config_get_data_t structure
+             * with Wi-Fi station connection status information. */
+
+            return ESP_OK;
+        }
+
+        esp_err_t set_config_handler(const wifi_prov_config_set_data_t *req_data)
+        {
+            /* Copy contents of req_data->ssid and req_data->password
+             * which are Wi-Fi AP credentials to which the device will connect */
+
+             return ESP_OK;
+        }
+
+        esp_err_t apply_config_handler(void)
+        {
+            /* Apply the Wi-Fi STA credentials saved during set_config */
+
+            return ESP_OK;
+        }
+
+        /* Structure with various config command handlers to be passed
+         * as private data during endpoint registration with protocomm */
+        wifi_prov_config_handlers_t wifi_prov_handlers = {
+            .get_status_handler   = get_status_handler,
+            .set_config_handler   = set_config_handler,
+            .apply_config_handler = apply_config_handler,
+        };
+
+        /* Set the endpoint handler */
+        protocomm_add_endpoint(pc, "wifi_config_endpoint",
+                               wifi_prov_config_data_handler,
+                               (void *) &wifi_prov_handlers);
+
+API Reference
+-------------
+
+.. include:: /_build/inc/wifi_config.inc

docs/zh_CN/api-reference/provisioning/index.rst

@@ -0,0 +1 @@
+.. include:: ../../../en/api-reference/provisioning/index.rst

docs/zh_CN/api-reference/provisioning/protocomm.rst

@@ -0,0 +1 @@
+.. include:: ../../../en/api-reference/provisioning/protocomm.rst

docs/zh_CN/api-reference/provisioning/provisioning.rst

@@ -0,0 +1 @@
+.. include:: ../../../en/api-reference/provisioning/provisioning.rst

docs/zh_CN/api-reference/provisioning/wifi_provisioning.rst

@@ -0,0 +1 @@
+.. include:: ../../../en/api-reference/provisioning/wifi_provisioning.rst