Updates For SDL Core Release 8.0.0

config.json

@@ -68,7 +68,15 @@
             "name":"App Services"
         },
         {
-            "name":"RPC Encryption"
+            "name":"Security",
+            "navigation":[
+                {
+                    "name":"Protected Services"
+                },
+                {
+                    "name":"RPC Encryption"
+                }
+            ]
         },
         {
             "name":"Best Practices",

docs/Policies/App Policies/index.md

@@ -45,7 +45,7 @@ This field is mandatory when defining policies for a cloud application, in which
 
 ### AppHMIType
 
-This field defines a list of AppHMITypes which an application is allowed to register with. If omitted, all AppHMITypes will be allowed (with the exception of `WEB_VIEW`).
+This field defines a list of AppHMITypes which an application is allowed to be registered with. If provided, this list of AppHMITypes will be used for this application in place of the `appHMIType` list provided in the app's RegisterAppInterface request. If there are AppHMITypes present in the app's RegisterAppInterface request that are not present in this list, SDL Core will provide a warning of this discrepancy to the app in the RegisterAppInterface response.
 
 !!! note
 This field is mandatory for webengine apps which use the `WEB_VIEW` AppHMIType, in which case the `WEB_VIEW` value must be explicitly included in this list.

docs/Protocol Spec/index.md

@@ -1187,7 +1187,7 @@ The control service is the lowest level service available. While Control Frame p
 ### 5.2 RPC Service
 >Required: All Protocol Versions
 
-The RPC service is used to send requests, responses, and notifications between an application and a head unit. Valid messages are defined in the [RPC Specification](https://github.com/smartdevicelink/sdl_core/blob/master/src/components/interfaces/MOBILE_API.xml).
+The RPC service is used to send requests, responses, and notifications between an application and a head unit. Valid messages are defined in the [RPC Specification](https://github.com/smartdevicelink/rpc_spec/blob/master/MOBILE_API.xml).
 
 The payload of a message sent via the RPC service, which directly follows the Frame Header in the packet, consists of a Binary Header, and JSON data representing the RPC.
 
@@ -1246,7 +1246,7 @@ The payload of a message sent via the RPC service, which directly follows the Fr
   <tr>
     <td>RPC Function ID</td>
     <td>28 bit</td>
-    <td>The Function ID of each RPC is specific to each version of the <a href="https://github.com/smartdevicelink/sdl_core/blob/develop/src/components/interfaces/MOBILE_API.xml#L2146-2207">RPC Specification</a> but in general do not change from version to version.
+     <td>The Function ID of each RPC is specific to each version of the <a href="https://github.com/smartdevicelink/rpc_spec/blob/master/MOBILE_API.xml">RPC Specification</a> but in general do not change from version to version.
   </tr>
   <tr>
     <td>Correlation ID</td>

docs/Security/Protected Services/index.md

@@ -0,0 +1,36 @@
+# Protected Services
+
+#### Related Evolution Proposals
+- [0317: SDL Protocol Security Specification](https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0317-sdl-protocol-security-specification.md)
+
+## 1. Overview
+
+Secured services in SDL are established using a TLS handshake, the TLS handshake process is defined by TLS and is not part of the SDL protocol.
+
+|||
+TLS Handshake Process
+![TLS Handshake activity diagram](./assets/tls_handshake_process.png)
+|||
+
+## 2. Peer roles during the handshake
+
+The handshake for establishing secured services uses a client-server model which is configurable via SDL Core settings. An application must take the role of the server while SDL Core is the client. The client entity will initiate a TLS handshake with the corresponding security manager of the server. The client will do this only if the server was not previously authenticated in the current transport connection.
+
+### 2.1 Peer certificate verification
+
+According to the TLS handshake process, the peer certificate can be omitted for the server but is required for the client. Certificate peer verification can be enabled/disabled in SDL Core by changing the `VerifyPeer` parameter in the configuration file. The SDL app libraries do not require a certificate from Core for the TLS handshake, but Core does perform its own internal certificate validation before starting the handshake. During internal validation, Core checks if the certificate is missing (or outdated/invalid) and if so, it initiates a PTU to obtain a new certificate from the Policy Server. If a valid certificate can't be obtained, Core does not start the TLS handshake and it notifies the app library that starting the protected service has failed.
+
+## 3. RPC processing
+After [RPC service encryption](../rpc-encryption) is enabled, SDL Core will reject any unencrypted RPC requests with an unencrypted response and result code `ENCRYPTION_NEEDED` if the RPC needs protection.
+
+!!! NOTE
+
+- SDL Core continues processing an unencrypted RPC request if the RPC does not need protection and responds with an unencrypted response.
+
+- SDL Core continues processing an encrypted RPC request if the RPC needs protection and responds with an encrypted response. In addition, SDL Core shall continue processing an encrypted RPC request if the RPC does not need protection and responds with an encrypted response.
+
+- SDL Core sends an unencrypted notification if the RPC does not need protection.  
+
+- SDL Core sends an encrypted notification if the RPC needs protection.
+
+!!!

docs/Supported Platforms/index.md

@@ -22,11 +22,19 @@ The standard version of Java is supported to be used mostly embedded or local on
 The enterprise edition of Java is supported, however, there is no Java EE specific code in the library itself. This is due to the fact that Java EE has conflicts with our licensing model for the open source library. This library is designed to be ran from a backend leveraging Java Beans and other web specific Java features.
 
 
+#### JavaScript
+The vanilla JavaScript Library allows you to create applications that run in the browser. WebEngine applications, which are installed via an app store and are run by supported HMIs, also fall into this category.
+
+
+#### Node.js
+The Node.js Library allows you to create applications that run on a web server. These applications can also take advantage of npm packages.
+
+
 ### Core Platforms
 
 #### Ubuntu
 
-Core currently officially supports Ubuntu versions 16.04, 18.04 and 20.04. Ubuntu 20.04 is the main supported platform of the project.
+Core currently officially supports Ubuntu versions 18.04 and 20.04. Ubuntu 20.04 is the main supported platform of the project.
 
 #### QNX
 
@@ -47,4 +55,4 @@ HTML is the most widely supported platform for developing the HMI. There are sev
 
 #### QT
 
-Some partners have created HMI implementations using QT. This platform is useable, but is a bit less dynamic and more difficult to update than HTML.
+Some partners have created HMI implementations using QT. This platform is usable, but is a bit less dynamic and more difficult to update than HTML.