<SYSTEM_TASK:>
Solve the following problem using Python, implementing the functions described below, one line at a time
<END_TASK>
<USER_TASK:>
Description:
 async def eap_options(request: web.Request) -> web.Response: """ Get request returns the available configuration options for WPA-EAP. Because the options for connecting to WPA-EAP secured networks are quite complex, to avoid duplicating logic this endpoint returns a json object describing the structure of arguments and options for the eap_config arg to /wifi/configure. The object is shaped like this: { options: [ // Supported EAP methods and their options. One of these // method names must be passed in the eapConfig dict { name: str // i.e. TTLS-EAPMSCHAPv2. Should be in the eapType // key of eapConfig when sent to /configure. options: [ { name: str // i.e. "username" displayName: str // i.e. "Username" required: bool, type: str } ] } ] } The ``type`` keys denote the semantic kind of the argument. Valid types are: password: This is some kind of password. It may be a psk for the network, an Active Directory password, or the passphrase for a private key string: A generic string; perhaps a username, or a subject-matches domain name for server validation file: A file that the user must provide. This should be the id of a file previously uploaded via POST /wifi/keys. Although the arguments are described hierarchically, they should be specified in eap_config as a flat dict. For instance, a /configure invocation for TTLS/EAP-TLS might look like ``` POST { ssid: "my-ssid", securityType: "wpa-eap", hidden: false, eapConfig : { eapType: "TTLS/EAP-TLS", // One of the method options identity: "alice@example.com", // And then its arguments anonymousIdentity: "anonymous@example.com", password: "testing123", caCert: "12d1f180f081b", phase2CaCert: "12d1f180f081b", phase2ClientCert: "009909fd9fa", phase2PrivateKey: "081009fbcbc" phase2PrivateKeyPassword: "testing321" } } ``` """


    return web.json_response(EAP_CONFIG_SHAPE, status=200)