Re: [tcpm] Universal Session Protocol

[Jonathon Anderson <[e-mail]>]

I've refined some of my ideas, and realized a few more benefits. As I mentioned, I just got the very rough draft together when I sent the first copy.

Client Overview
01. Client software tells operating system it wants to create an application session, such as HTTP, with a remote server
02. Operating system initializes a USP session, specifying the remote server and application
03. USP requests an encrypted byte stream from a presentation layer protocol such as TLS, using Diffie-Hellman without PKI
04. Presentatation layer requests a raw byte stream from a transport layer protocol such as TCP
05. Transport layer creates a session with the remote server, sending locally generated session ID instead of remote port
06. USP requests an application menu from the remote server
07. USP optionally authenticates if authentication is offered
08. If HTTP is offered as a service, with or without authentication, USP requests a session token
09. USP uses token to request an application session for a new or existing TLS session
10. USP passes TLS session to client software via IPC

Server Overview
01. Operating system receives request to establish TCP session with remote client's session ID instead of source port
02. Operating system generates a TCP session and sends the session ID to client to complete the connection
03. Operating system receives a request for TLS session and establishes a secure channel using Diffie-Hellman without PKI
04. Operating system receives request for USP session, launches the USP client, and replies with application menu, optionally offering authentication
05. Optionally authenticate remote client
06. USP receives request for application session and validates authorization and parameters
07. USP responds with error or application session token
08. USP receives request with application session token and validates the request
09. USP associates the application session with a new or existing TLS session
10. USP passes TLS session to client software via IPC

High Level Benefits
- Eliminate port scanning
- Prevent applications from becoming bots
    - Hosts can't create arbitrary TCP streams
    - OS can rate limit connection creation
    - OS itself would be the only target to make a bot
- Possibility to create third party connection brokers for the application layer
- Decouple application and transport layer configurations
- Releives end user of requiring prior knowledge of remote system configuration to interact with system (port #)
- Completes and re-orders OSI model (OSIv2) for more reasonable control flow
    - Layer 5 becomes presentation
    - Layer 6 becomes session
    - HTTP client software requests application session from USP, USP requests encrypted byte strem from TLS, TLS requests byte stream from TCP
    - Gives useful meaning to presentation and session layers
- Identity is established at session layer instead of transport layer
- True separation of responsibilities
- Uses object capability model
  - Actions on streams can only be performed if the associated function is provided on the stream object
  - Runaway programs cannot create TCP connections at will to flood remote targets
- Dynamic changes to offered services without needing to manage port allocations
- Authentication before being granted access to protocol
- Can establish multiple sessions simultaneously
- Better isolation because applications will not be required to serve multiple streams in the same process
- Improved confidentiality because all TCP streams are encrypted by default, without PKI
- Improved confidentiality because public keys will no longer be exchanged in the open
- Improved accountability because every application session can be tied to an authorization token and ultimately to a requestor
    - If someone did attempt to exploit a weakness in an application layer protocol, you would be able to trace that activity to an identity instead of it being an anonymous person on the internet

Detailed Analysis
1. (TCP) Transport Layer
  - No port numbers
  - Client sends it's own dynamically generated TCP session ID with request
  - Server accepts request and responds with own generated TCP session ID
  - No longer use client_ip:client_port <-> server_ip:server_port pairs as identifiers
  - Connections identified by client_ip:client_tcp_stream <-> server_ip:server_tcp_stream
  - Removing port information here eliminates encoding of layer 7 information into layer 4 configurations and vice versa It also improves scalability by elimination constraints on available port numbers, and removes a configuration concern from system administration, which reduces the possibility of errors and vulnerabilities.
  - I've come to believe that the use of remote ports to establish connections is a bug. Changing this property alone enables nearly every other change detailed here

2. (TLS) Presentation Layer
  - Encryption of sessions should be default, as a matter of principal
  - Identity is no longer established at this layer. It's established at the session layer instead.
  - Diffie-Hellman is capable of establishing secure channels without PKI
  - PKI is currently used to validate the identity of the cryptographic primitives being exchanged
  - Instead, a secure channel can be built and PKI can be used to verify identity after that, as part of the authentication option detailed below
  - PKI and DH both suffer from vulnerability to man in the middle attacks. The extra measure of signing primitives does not mitigate that.
  - Because PKI exchanges public certificates in the open, confidentiality is limited to data being transferred. If a secure channel is already established before certificates are exchanged, a new level of confidentiality is available that was not before.
  - Caeser had his data ciphered and then signed it with his seal. He did not brand his cryptographer and then assume all data that was produced bore his identity, however hilarious and entirely disturbing that would have been...

3. (USP) Session Layer

3.a. (USP) Client Request - Initial request
  - Required Fields
    - "client_session_id"
    - "menu_authorization_token"
    - "application_session"
      - "token"
      - "action"
  - Field Meaning
    - "client_session_id"
      - Unique session identifier created by client
    - "menu_authorization_token"
      - Auth token provided after completing the client chosen authentication process
    - "application_session"."token"
      - Provided by server after service negotiation
      - Required to connect to application
    - "action"
      - Commands to control the sesssion itself (not application layer commands)
  - {
      "client_session_id":"<some id>",
      "menu_authorization_token":"<NULL or SOME TOKEN>",
      "application_session": NULL OR {
        "token":"<NULL or some ID>",
        "action":"<action available for specific session type>"
      }
    }

3.b. (USP) Server Response
  - If "application_session" is NULL
    - If "menu_authorization_token" is NULL: Offer unauthenticated menu
    - If "menu_authorization_token" is invalid: Offer unauthenticated menu
    - If "menu_authorization_token" is valid: Offer authenticated menu
  - If "application_session" is populated
    - Validate that application session token is valid for the requesting IP
      - If a third party is allowed to specify a client IP for the application, and that IP is associated with the token, then a brokering host could establish connections for arbitrary clients, if authorization between client and broker has occurred. (See request body details below.)
    - Begin application associated with token using parameters that were defined in the request body defined below.
      - Maintaining a token to application and parameter mapping will permit the menu to change on the fly and establish ahead of time what conditions the application will be started under
    - Ignore "menu_authorization_token" as it's only meant for menu access

3.b.i. (USP) Application Menu
  - Required fields
    - "server_session_id"
    - "identity"
        - "service"
    - "applications"
      - "name"
      - "expected_request_body"

  - Field Meaning
    - "server_session_id"
      - Unique session identifier created by server
    - "identity"
        - "service"
            - Should provide token invalidation service
            - Name of identity services offered for authentication
            - Can offer a "server identification" or "mutual identification" services so verify server and/or client identity
      - "expected_request_body"
        - Lays out the expected structure of the identity request
    - "applications"
      - "name"
        - human readable name
      - "expected_request_body"
        - Lays out the expected structure of the application connection request
        - If an IP is accepted as a connection parameter, a brokering host could request an "application_session"."token" and pass it back to a client host. When the client host makes a request to the server, the token will match the IP that was provided in the request body. "Connection brokering" could be a service that's offered after authentication to ensure brokering hosts are not abused.
        - Clients could receive unsolicited brokered connections if the client is configured to also act as a USP server and offer a "connection brokering client" option.
            - For security, this could require authentication

      - The benefit of providing a separate list after authentication is that secure applications remain unknown AND unavailable until after authentication occurs. So, for example, instead of SSH being available for everyone and fighting off authentication and protocol attacks on its own, availability of the SSH service could not be be known much less a connection established because the index would not be known and the server would not have responded with the necessary connection information and, most importantly, a security token allowing access to the program. This would provide an enormous amount of security by placing potentially flawed protocols behind the authentication wall instead of in front of it.
      - Another way to look at the previous benefit is that "port scanning", or "scanning listening applications and attempting to exploit protocol vulnerabilities", will be significantly reduced or eliminated. It will create a secre collection of applications available only to authenticated and authorized users.
      - There is no association between index numbers and layer 7 applications, so each layer only needs to know about its own information
      - Application menu SHOULD be built dynamically
        - Installed applications SHOULD register their parameters with the operating system in a place that can be read by UAP
        - Available authentication methods SHOULD also be registered with parameters
        - USP SHOULD allow configurations of registry path
        - If registration is used
          - Registry SHOULD provide "expected_request_body"
          - Empty fields representing the expected structure of a request for that application

  - {
  "server_session_id":"<some session id>",
  "identity": [
    {
      "service":"identity_service_name",
      "field1":"auth_value1",
      "field2":"auth_value2",
      "expected_request_body":{
        "required_field1":"",
        "required_field2":""
      }
    },
    {
      "service":"identity_service_name",
      "field1":"auth_value1",
      "field2":"auth_value2",
      "expected_request_body":{
        "required_field1":"",
        "required_field2":""
      }
    }
  ],
  "applications": [
    {
      "name":"application_name",
      "application_field1":"application_value1",
      "application_field2":"application_value2",
      "expected_request_body":{
          "required_field1":"",
          "required_field2":""
      }
    },
    {
      "name":"application_name",
      "application_field1":"application_value1",
      "application_field2":"application_value2",
      "expected_request_body":{
          "required_field1":"",
          "required_field2":""
      }
    }
  ]
}

3.b.ii. (USP) Client Request
  - Required Fields
    - "client_session_id"
    - "menu_authorization_token"
    - "identity"
        - "service"
    - "applications"
        - "name"

  - If acting as a connetion broker, and authorized in the server's configuration, the client may terminate sessions for other hosts by invalidating their application session token.
  - Client may only invalidate its own menu authorization token
  - Client may request multiple services in the same request body to establish multiple sessions simultaneously, including starting the authentication process while simultaneously acknowledging other valid service requests by sending an application session token for each service
  - {
  "client_session_id":"<some id>",
  "menu_authorization_token":"<NULL or SOME TOKEN>",
  "applications": {
    "identity": [
      {
        "service":"identity_service_name",
        "required_field1":"required_value1",
        "required_field2":"required_value2"
      },
      {
        "service":"identity_service_name",
        "required_field1":"required_value1",
        "required_field2":"required_value2"
      }
    ],
    "applications": [
      {
        "name":"application_name",
        "required_field1":"required_value1",
        "required_field2":"required_value2"
      },
      {
        "name":"application_name",
        "required_field1":"required_value1",
        "required_field2":"required_value2"
      }
    ]
  }
}

3.b.iii. (USP) Server Response
  - Required Fields
    - "server_session_id"
    - "identity"
        -"service"
        - "token"
    - "applications"
        - "name"
        - "token"

  - Authentication
    - If request is made for authentication, initiate authentication process
    - Ending by providing "identity"."token"

  - Requested Services
    - For each valid and authorized service, generate and respond with token that will be used as "application_session"."token" by client

  - Authorization
    - If "identity"."token" is NULL:
      - Respond to secure application requests with error
      - Complete session establishment for valid public application requests
    - If "identity"."token" is invalid:
      - Respond to secure application requests with error
      - Complete session establishment for valid public application requests
    - If "identity"."token" is valid: Complete session establishment for all valid requests

    - {
  "identity":[
    {
      "service":"identity_service_name",
      "token":"<some token>"
    },
    {
      "service":"identity_service_name",
      "error":{
        "message":"Authentication failure"
      }
    }
  ],
  "applications":[
    {
      "name":"application_name",
      "token":"<some token>"
    },
    {
      "name":"application_name",
      "error":{
        "message":"Menu authorization token missing"
      }
    }
  ]
}

4. Application Initialization
  - If the client request as a valid application session token, initialize the desired application and pass the TCP stream into the application using IPC
  - Server applications are no longer responsible for creating their TCP connections, alleviate application programmers from needing to manage system functions
  - Server applications can be prevented from arbitrarily creating TCP connections, making it impossible for applications to become bots.
  - Instead of creating server applications that manage multiple streams internally, lightweight applications could be started. This would provide better process isolation. It's likely we don't do this now because it's impossible with the limit on the number of ports available. There is no restriction on the number of session ID's, like there is on ports, so again the only restriction is available resources
  - Because authentication can be a requirement for access to the application itself, it can be tied directly back to a user
    - Every application session can require an application token
    - Every application token can be associated with a menu authorization token (permission to view the application in the menu)
    - Every menu authorization token can be associated with an identity provided to the authentication server
    - Every menu authorization token can also be logged by the client operating system and associated with a user identity
    - If someone did attempt to exploit a weakness in an application layer protocol, you would be able to trace that activity to an identity instead of it being an anonymous person on the internet

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, November 22nd, 2021 at 11:13 AM, Jonathon Anderson <[e-mail]> wrote:

> I believe I can complete the code for the session layer protocol fairly easily, since it's a new design and I have all of the details worked out conceptually. It's the TCP layer that I would really need help with to expedite development.
>
> Sent with [ProtonMail](https://protonmail.com/) Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, November 22nd, 2021 at 10:48 AM, Jonathon Anderson <[e-mail]> wrote:
>
>> I didn't intend this as a complete submission. My impression was that your working group would be the first people to ask for guidance before investing time in code that may not be accepted. I understand where you are coming from, but if the community rejects my proposal on principle, then, I think, it would be unlikely they would accept my running code.
>>
>> This type of network programming is also currently outside my reach and involves operating system level changes. Although I am confident that in enough time I can provide a working sample, tackling all of operating system design, TCP design, and the new protocol itself is seemingly impossible to do alone. My hope was to find someone with that level of experience to work with to accelerate the process while I am continuing to develop my experience. I also think that other industry players, such as RedHat and Microsoft, should be involved in the process, because there are considerations for operating system design.
>>
>> The implications for this are huge. Just being able to track all protocol interactions to an identity and eliminating bot nets alone seem to merit addressing this issue. I'm not asking for approval of the protocol; I'm asking for help completing the protocol. I'm just looking for people to work with at this point, and the TCP working group seems like the the most natural first place to find those people.
>>
>> Sent with [ProtonMail](https://protonmail.com/) Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Monday, November 22nd, 2021 at 10:35 AM, Scharf, Michael <[e-mail]> wrote:
>>
>>> Hi Jonathan,
>>>
>>> Thanks a lot for reaching out to TCPM.
>>>
>>> Without digging into details of your proposal I’d like to highlight that the IETF is all about running code, i.e., implementations are very important. The transport layer and its interaction with applications are really non-trivial when it comes to details and a lot oft he real-world challenges may only become visible once one actually tries to implement it. I strongly suggest to look into implementations before designing a mechanisms in a top-down fashing.
>>>
>>> Note that there are also research conferences to which new ideas can be submitted. Often, new ideas are first discussed in research before the detailed protocol engineering in the IETF starts. You could also think about a conference or journal submission as a first step. But even in that case a prototype implemenation would most likely be required to be accepted.
>>>
>>> Best regards
>>>
>>> Michael
>>>
>>> (TCPM co-chair)
>>>
>>> From: tcpm <[e-mail]> On Behalf Of Jonathon Anderson
>>> Sent: Saturday, November 20, 2021 5:27 PM
>>> To: [e-mail]
>>> Subject: [tcpm] Universal Session Protocol
>>>
>>> I am submitting this as a suggested line of research and an offer for collaboration, if it's considered worthwhile. I believe that I have developed a layer 5 protocol that will greatly improve functionality at and between layers 4, 5, and 7, providing numerous efficiency and security benefits. In order to work, it would require a change to TCP that would appreciably alter how the internet is constructed today, although the change itself is rather minor. I'm calling the layer 5 protocol the "Universal Session Protocol" (USP). This is my first draft, so I'm sure there is a lot to do here, and my first submission to IETF, so it would be great to work with someone who knows the process.
>>>
>>> My background is 15 years in network and system administration / engineering, and I'm currently studying for my masters in computer science. The only network stack development I've done is creating a TCP stream from an example in a book, so I don't understand the inner workings of TCP enough to elaborate what changes would need to be made; just enough to grasp the fundamentals. That being said, I believe the principles are sound at a high conceptual level.
>>>
>>> I am reluctant to submit this because I understand the implications of suggesting a change to one of the foundational protocols of the internet. However, every time I walked away from this I cam back with another justification as to why this was a good idea, and after a challenge session from a good friend we both came to the conclusion that there may be something here. So, I hope that you enjoy it, and I look forward to any responses.
>>>
>>> -------------------------------------
>>>
>>> Client Overview
>>>
>>> 1. Client program tells operating system it wants to make an HTTP request to a remote host
>>>
>>> 2. Operating system creates TCP stream to remote host (using stream ID's, not ports)
>>>
>>> 3. Operating system creates USP session and determines if HTTP is offered as an application
>>>
>>> 4. If HTTP is not offered but authentication is, attempt to authenticate and check for HTTP again
>>>
>>> 5. If HTTP is offered as a service, create a new TCP connection and submit application token to establish an HTTP session (using stream ID's, not ports)
>>>
>>> 6. Operating system passes TCP stream into client
>>>
>>> Server Overview
>>>
>>> 1. Operating system receives TCP request from remote host and creates TCP stream (using stream ID's, not ports)
>>>
>>> 2. Operating system sends USP application menu to remote host, offering authentication if available
>>>
>>> 3. If the remote host requests authentication, complete authentication and send the new application menu
>>>
>>> 4. If the remote host requests an application, send an application token that grants the remote host permission to connection to specified application
>>>
>>> 5. When remote host requests new TCP stream and sends USP request with application token, operating system creates a new TCP stream (using stream ID's, not ports)
>>>
>>> 6. Operating system starts application and passes stream object into server program via IPC (each token is locally associated with an application and parameters)
>>>
>>> High Level Benefits
>>>
>>> - Eliminate port scanning
>>>
>>> - Prevent applications from becoming bots
>>>
>>> - Hosts can't create arbitrary TCP streams
>>>
>>> - OS can rate limit connection creation
>>>
>>> - OS itself would be the only target to make a bot
>>>
>>> - Possibility to create third party connection brokers for the application layer
>>>
>>> - Detangle layer 7 and layer 4 configurations
>>>
>>> - True separation of responsibilities
>>>
>>> - Uses object capability model
>>>
>>> - Actions on streams can only be performed if the associated function is provided on the stream object
>>>
>>> - Runaway programs cannot create TCP connections at will to flood remote targets
>>>
>>> - Dynamic changes to offered services without needing to manage port allocations
>>>
>>> - Authentication before being granted access to protocol
>>>
>>> - Can establish multiple sessions simultaneously
>>>
>>> - Better isolation because applications will not be required to serve multiple streams in the same process
>>>
>>> - Improved confidentiality because all TCP streams are encrypted by default, without PKI
>>>
>>> - Improved accountability because every application session can be tied to an authorization token and ultimately to a requestor
>>>
>>> - If someone did attempt to exploit a weakness in an application layer protocol, you would be able to trace that activity to an identity instead of it being an anonymous person on the internet
>>>
>>> Detailed Analysis
>>>
>>> 1. (TCP) Initiate Session
>>>
>>> - No port numbers
>>>
>>> - Client sends it's own dynamically generated TCP stream ID with request
>>>
>>> - Server accepts request and responds with own generated TCP stream ID
>>>
>>> - No longer use ip:port pairs as identifiers
>>>
>>> - Connections identified by client_ip:client_tcp_stream <-> server_ip:server_tcp_stream
>>>
>>> - Removing port information here eliminates encoding of layer 7 information into layer 4 configurations and vice versa It also improves scalability by elimination constraints on available port numbers, and removes a configuration concern from system administration, which reduces the possibility of errors and vulnerabilities.
>>>
>>> 2. (TCP) Encrypt all sessions
>>>
>>> - Encryption of streams should be default, as a matter of principal
>>>
>>> - Diffie-Hellman is capable of establishing secure channels without PKI
>>>
>>> - PKI is currently used to validate the identity of the cryptographic primitives being exchanged
>>>
>>> - Instead, a secure channel can be built and PKI can be used to verify identity after that, as part of the authentication option detailed below
>>>
>>> - Caeser had his data ciphered and then signed it with his seal. He did not brand his cryptographer and then assume all data that was produced bore his identity, however hilarious and entirely disturbing that would be...
>>>
>>> 3. (USP) Client Request - Initial request
>>>
>>> - Required Fields
>>>
>>> - "client_session_id"
>>>
>>> - "authorization_token"
>>>
>>> - "application_session"
>>>
>>> - "token"
>>>
>>> - "action"
>>>
>>> - Field Meaning
>>>
>>> - "client_session_id"
>>>
>>> - Unique session identifier created by client
>>>
>>> - "authorization_token"
>>>
>>> - Auth token provided after completing the client chosen authentication process
>>>
>>> - "application_session"."token"
>>>
>>> - Provided by server after service negotiation
>>>
>>> - Required to connect to application
>>>
>>> - "application_session"."action"
>>>
>>> - "begin"
>>>
>>> - "end"
>>>
>>> - "<any other value available from application protocol>"
>>>
>>> - {
>>>
>>> "client_session_id":"<some id>",
>>>
>>> "authorization_token":"<NULL or SOME TOKEN>",
>>>
>>> "application_session": NULL OR {
>>>
>>> "token":"<NULL or some ID>",
>>>
>>> "action":"<begin/end/other>"
>>>
>>> }
>>>
>>> }
>>>
>>> 4. (USP) Server Response
>>>
>>> - If "application_session" is NULL
>>>
>>> - If "authorization_token" is NULL: Offer unauthenticated menu
>>>
>>> - If "authorization_token" is invalid: Terminate the session with an error
>>>
>>> - If "authorization_token" is valid: Offer authenticated menu
>>>
>>> - If "application_session" is populated
>>>
>>> - Validate that application session token is valid for the requesting IP
>>>
>>> - If a third party is allowed to specify a client IP for the application, and that IP is associated with the token, then a brokering host could establish connections for arbitrary clients, if authorization between client and broker has occurred. (See request body details below.)
>>>
>>> - Begin application associated with token
>>>
>>> - Maintaining a token to application mapping will permit the menu to change on the fly
>>>
>>> - Ignore "authorization_token" as it's only meant for menu access
>>>
>>> 4.a.i. (USP) Application Menu
>>>
>>> - Required fields
>>>
>>> - "server_session_id"
>>>
>>> - "application_menu"
>>>
>>> - "name"
>>>
>>> - "expected_request_body"
>>>
>>> - Field Meaning
>>>
>>> - "name"
>>>
>>> - human readable name
>>>
>>> - I can see a scenario where human readable identifiers would no longer be relevant, as the general trend is to remove constructs from applications that require human reasoning and intervention. However, for the time being all existing application layer protocols are identified with human readable names, and changing this in a revision would not be difficult, so it seems safe to require for the time being.
>>>
>>> - "server_session_id"
>>>
>>> - Unique session identifier created by server
>>>
>>> - "application_menu"
>>>
>>> - numerically indexed
>>>
>>> - JSON
>>>
>>> - Index 0 is reserved as authentication initiation if not authenticated yet
>>>
>>> - Index 0 is reserved as token invalidation if already authenticated
>>>
>>> - The benefit of providing a separate list after authentication is that secure applications remain unknown AND unavailable until after authentication occurs. So, for example, instead of SSH being available for everyone and fighting off authentication and protocol attacks on its own, availability of the SSH service could not be be known much less a connection established because the index would not be known and the server would not have responded with the necessary connection information. This would provide an enormous amount of security by placing potential flawed protocols behind the authentication wall instead of in front of it.
>>>
>>> - Another way to look at the previous benefit is that "port scanning", or "scanning listening applications and attempting to exploit protocol vulnerabilities", will be significantly reduced
>>>
>>> - Index 0 is a JSON array containing authentication methods with parameters
>>>
>>> - There is no association between index numbers and layer 7 applications
>>>
>>> - Application menu SHOULD be built dynamically
>>>
>>> - Installed applications SHOULD register their parameters with the operating system in a place that can be read by UAP
>>>
>>> - Available authentication methods SHOULD also be registered with parameters
>>>
>>> - USP SHOULD allow configurations of registry path
>>>
>>> - If registration is used
>>>
>>> - Registry SHOULD provide "expected_request_body"
>>>
>>> - Empty fields representing the expected structure of a request for that application
>>>
>>> - "expected_request_body"
>>>
>>> - Lays out the expected structure of the application connection request
>>>
>>> - If an IP is accepted as a connection parameter, the brokering host could request an "application_session"."token" and pass it back to the client host. When the client host makes a request to the server host, the token will match the IP that was provided in the request body. "Connection brokering" could be a service that's offered after authentication to ensure brokering hosts are not abused. Clients will not receive unsolicited attempts to force them to connect to servers because they won't be listening for this traffic. A client must initiate the brokering service.
>>>
>>> - {
>>>
>>> "server_session_id":"<some session id>",
>>>
>>> "application_menu": {
>>>
>>> "0": [
>>>
>>> {
>>>
>>> "auth_method1":"auth_method_name_or_id1",
>>>
>>> "auth_field1":"auth_value1",
>>>
>>> "auth_field2":"auth_value2",
>>>
>>> "expected_request_body":{
>>>
>>> "required_field1":"",
>>>
>>> "required_field2":""
>>>
>>> }
>>>
>>> },
>>>
>>> {
>>>
>>> "auth_method":"auth_method1",
>>>
>>> "auth_field1":"auth_value1",
>>>
>>> "auth_field2":"auth_value2",
>>>
>>> "expected_request_body":{
>>>
>>> "required_field1":"",
>>>
>>> "required_field2":""
>>>
>>> }
>>>
>>> }
>>>
>>> ],
>>>
>>> "1": {
>>>
>>> "name":"app1",
>>>
>>> "application_field1":"application_value1",
>>>
>>> "application_field2":"application_value2",
>>>
>>> "ecpected_request_body":{
>>>
>>> "required_field1":"",
>>>
>>> "required_field2":""
>>>
>>> }
>>>
>>> },
>>>
>>> "2": {
>>>
>>> "name":"app2",
>>>
>>> "application_field1":"application_value1",
>>>
>>> "application_field2":"application_value2",
>>>
>>> "expected_request_body":{
>>>
>>> "required_field1":"",
>>>
>>> "required_field2":""
>>>
>>> }
>>>
>>> },
>>>
>>> "3": {
>>>
>>> "name":"app3",
>>>
>>> "application_field1":"application_value1",
>>>
>>> "application_field2":"application_value2",
>>>
>>> "expected_request_body":{
>>>
>>> "required_field1":"",
>>>
>>> "required_field2":""
>>>
>>> }
>>>
>>> },
>>>
>>> "4": {
>>>
>>> "name":"app4",
>>>
>>> "application_field1":"application_value1",
>>>
>>> "application_field2":"application_value2",
>>>
>>> "expected_request_body":{
>>>
>>> "required_field1":"",
>>>
>>> "required_field2":""
>>>
>>> }
>>>
>>> }
>>>
>>> }
>>>
>>> }
>>>
>>> 4.a.ii. (USP) Client Request
>>>
>>> - Required Fields
>>>
>>> - "client_session_id"
>>>
>>> - "authorization_token"
>>>
>>> - "requested_services"
>>>
>>> - If requestng services or authorization: Request body required fields as defined in application menu
>>>
>>> - If index 0 is being used to invalidate tokens: An array of tokens
>>>
>>> - Client may request multiple services in the same request body to establish multiple sessions simultaneously, including starting the authentication process while simultaneously acknowledging other valid service requests by sending an application session token for each service
>>>
>>> - {
>>>
>>> "client_session_id":"<some id>",
>>>
>>> "authorization_token":"<NULL or SOME TOKEN>",
>>>
>>> "requested_services": {
>>>
>>> "0": { (if requesting authentication)
>>>
>>> "required_field1":"required_value1",
>>>
>>> "required_field2":"required_value2"
>>>
>>> },
>>>
>>> "0": [ (if invalidating tokens)
>>>
>>> "token1",
>>>
>>> "token2"
>>>
>>> ],
>>>
>>> "1": {
>>>
>>> "required_field1":"required_value1",
>>>
>>> "required_field2":"required_value2"
>>>
>>> },
>>>
>>> "3": {
>>>
>>> "required_field1":"required_value1",
>>>
>>> "required_field2":"required_value2"
>>>
>>> }
>>>
>>> }
>>>
>>> }
>>>
>>> 4.a.iii. (USP) Server Response
>>>
>>> - Authentication
>>>
>>> - If request is made for authentication, initiate authentication process
>>>
>>> - Ending by providing "authorization_token"
>>>
>>> - Requested Services
>>>
>>> - For each valid and authorized service, generate and respond with token that will be used as "application_session"."token" by client
>>>
>>> - Authorization
>>>
>>> - If "authorization_token" is NULL:
>>>
>>> - Respond to secure application requests with error
>>>
>>> - Complete session establishment for valid public application requests
>>>
>>> - If "authorization_token" is invalid:
>>>
>>> - Respond to secure application requests with error
>>>
>>> - Complete session establishment for valid public application requests
>>>
>>> - If "authorization_token" is valid: Complete session establishment for all valid requests
>>>
>>> - {
>>>
>>> "1": {
>>>
>>> "token":"<some token>"
>>>
>>> },
>>>
>>> "3": {
>>>
>>> "token":"<some token>"
>>>
>>> },
>>>
>>> "5": {
>>>
>>> "error":{
>>>
>>> "message":"Authorization token missing"
>>>
>>> }
>>>
>>> },
>>>
>>> "7": {
>>>
>>> "error":{
>>>
>>> "message":"Authorization token invalid"
>>>
>>> }
>>>
>>> }
>>>
>>> }
>>>
>>> 4.b. Application Initialization
>>>
>>> - If the client request as a valid application session token, initialize the desired application and pass the TCP stream into the application using IPC
>>>
>>> - Server applications are no longer responsible for creating their TCP connections, alleviate application programmers from needing to manage system functions
>>>
>>> - Server applications can be prevented from arbitrarily creating TCP connections, making it impossible for applications to become bots.
>>>
>>> - Instead of creating server applications that manage multiple streams internally, lightweight applications could be started. This would provide better process isolation. It's likely we don't do this now because it's impossible with the limit on the number of ports available. There is no restriction on the number of session ID's, like there is on ports, so again the only restriction is available resources
>>>
>>> - Because authentication can be a requirement for access to the application itself, it can be tied directly back to a user
>>>
>>> - Every application session can require an application token
>>>
>>> - Every application token can be associated with an authorization token (permission to view the application in the menu)
>>>
>>> - Every authorization token can be associated with an identity provided to the authentication server
>>>
>>> - Every authorization token can also be logged by the client operating system and associated with a user identity
>>>
>>> - If someone did attempt to exploit a weakness in an application layer protocol, you would be able to trace that activity to an identity instead of it being an anonymous person on the internet
>>>
>>> Sent with [ProtonMail](https://protonmail.com/) Secure Email.