fix: rename wos to wfm

Workload Orchestration Service (WOS) has been renamed to Workload Fleet
Management (WFM) after this PR was originally created. This commit fixes
it.

Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>

Author: Silvanoc

system-design/fleet-management/workload/workload-fleet-management-edge-onboarding.md

@@ -5,13 +5,13 @@ In order for the Workload Fleet Management software to manage the edge device's
 
 **The onboarding process includes:**
 
-- The end user provides the the Workload Fleet Management web service's root URL to the device's management client
-- The device's management client downloads the workload orchestration solution vendor's public root CA certificate using the [Onboarding API](../../margo-api-reference/workload-api/onboarding-api/rootca-download.md)
-- Context and trust is established between the device's management client and the Workload Fleet Management web service
-- The device's management client uses the [Onboarding API](../../margo-api-reference/workload-api/onboarding-api/device-onboarding.md) to onboard with the workload orchestration service.
+- The end user provides the the Workload Fleet Management (WFM) web service's root URL to the device's management client
+- The device's management client downloads the WFM solution vendor's public root CA certificate using the [Onboarding API](../../margo-api-reference/workload-api/onboarding-api/rootca-download.md)
+- Context and trust is established between the device's management client and the WFM web service
+- The device's management client uses the [Onboarding API](../../margo-api-reference/workload-api/onboarding-api/device-onboarding.md) to onboard with the WFM.
 - The device's management client receives the client Id, client secret and token endpoint URL used to generate a bearer token.
 - The device's management client receives the URL for the Git repository containing its desired state and an associated access token for authentication
-- The [device capabilities](./device-capability-reporting.md) information is sent from the device to the workload orchestration web service using the [Device API](../../margo-api-reference/workload-api/device-api/device-capabilities.md)
+- The [device capabilities](./device-capability-reporting.md) information is sent from the device to the WFM web service using the [Device API](../../margo-api-reference/workload-api/device-api/device-capabilities.md)
 
 > Note:
 > 🔐 Indicates communication is secure and requires authentication/authorization.
@@ -24,49 +24,49 @@ sequenceDiagram
     participant device as Device
     actor user as End User
     participant rendezvous as Rendezvous Server
-    participant wos as WOS
-    participant git as WOS: Device Git Repo   
-    note over device, git: Workload orchestration onboarding
+    participant wfm as WFM
+    participant git as WFM: Device Git Repo   
+    note over device, git: WFM onboarding
     user ->>+ device: Get device id and cert
     device -->>- user: return
-    user ->> wos: Provides device id and cert to pre-register device in end user's tenant 🔐
+    user ->> wfm: Provides device id and cert to pre-register device in end user's tenant 🔐
      
     %% A background highlight could be also used here
     %% https://mermaid.js.org/syntax/sequenceDiagram.html#background-highlighting
     alt FIDO: client-initiated rendezvous
-        user ->> rendezvous: Provides WOS URL
+        user ->> rendezvous: Provides WFM URL
     else FIDO: Discoverable credentials
-        device ->>+ rendezvous: Looks up WOS URL
+        device ->>+ rendezvous: Looks up WFM URL
         rendezvous -->>- device: return
     end
-    device ->>+ wos: Request WOS' public signing cert 🔓
-    wos -->>- device: return
-    device ->>+ wos: Send onboard request, device id and certificate 🔓
-    wos ->> wos: Validates device id and cert with onboarding registry
-    wos -->>- device: returns URL to check onboarding status
+    device ->>+ wfm: Request WFM' public signing cert 🔓
+    wfm -->>- device: return
+    device ->>+ wfm: Send onboard request, device id and certificate 🔓
+    wfm ->> wfm: Validates device id and cert with onboarding registry
+    wfm -->>- device: returns URL to check onboarding status
     
     loop until onboarding status is active   
-        device ->>+ wos: Checks onboarding status providing device id and certificate 🔓
-        wos ->> wos: Validates device id and cert with onboarding registry
-        wos -->>- device: returns in progress
+        device ->>+ wfm: Checks onboarding status providing device id and certificate 🔓
+        wfm ->> wfm: Validates device id and cert with onboarding registry
+        wfm -->>- device: returns in progress
     end
-    device ->>+ wos: Checks onboarding status providing device id and certificate 🔓
-    wos ->> wos: Validates device id and cert with onboarding registry
-    wos -->>- device: returns git repo URL and GitOps token, encrypted client id, encrypted client secret
+    device ->>+ wfm: Checks onboarding status providing device id and certificate 🔓
+    wfm ->> wfm: Validates device id and cert with onboarding registry
+    wfm -->>- device: returns git repo URL and GitOps token, encrypted client id, encrypted client secret
     
-    device ->> wos: Uploads device capabilities
+    device ->> wfm: Uploads device capabilities
     note over device, git: Workload deployment
     loop Until end of time
         device ->>+ git: Checks for updates to desired state 🔐
         git -->>- device: return
         opt
-            device ->> wos: Requests new GitOps token 🔐
-            wos -->> device: return
+            device ->> wfm: Requests new GitOps token 🔐
+            wfm -->> device: return
         end
         device ->> device: Applies new desired state
-        device ->> wos: Sends state 🔐
-        device ->> wos: Sends state 🔐
-        device ->> wos: Sends final state 🔐
+        device ->> wfm: Sends state 🔐
+        device ->> wfm: Sends state 🔐
+        device ->> wfm: Sends final state 🔐
     end    
 ```
 
@@ -76,11 +76,11 @@ sequenceDiagram
 
 > Action: Ideally this URL is discoverable instead of having to manually enter it but we still need to determine if there is a good way to make this discoverable by using something like the FIDO Rendezvous service or multicast DNS. Also, once we determine how the Margo compliant device onboarding and fleet management is going to work it will probably impact this.
 
-To ensure the management client is configured to communicate with the correct Workload Fleet Management web service, the device's management client needs to be configured with the expected URL. The device vendor MUST provide a way for the end user to manually set the URL the device's management client uses to communicate with the workload orchestration solution chosen by the end user.
+To ensure the management client is configured to communicate with the correct Workload Fleet Management web service, the device's management client needs to be configured with the expected URL. The device vendor MUST provide a way for the end user to manually set the URL the device's management client uses to communicate with the WFM solution chosen by the end user.
 
 ### Margo Web API Authentication Method
 
-The Margo Web API communication pattern between the device's management client and the workload orchestration web service must use a secure communication channel. In order to facilitate this secure communication Margo requires the use of oAuth 2.0 for authentication.
+The Margo Web API communication pattern between the device's management client and the WFM web service must use a secure communication channel. In order to facilitate this secure communication Margo requires the use of oAuth 2.0 for authentication.
 
 #### API Authorization Strategy
 
@@ -94,7 +94,7 @@ The Margo Web API communication pattern between the device's management client a
 
 Because of limitations using mTLS with common OT infrastructure such as TLS terminating HTTPS load-balancer or a HTTPS proxy doing lawful inspection Margo has adopted a certificate-based payload signing approach to protect payloads from being tampered with. By utilizing the certificates to create payload envelopes, the device's management client can ensure secure transport between the device's management client and the Workload Fleet Management's web service.
 
-- During the onboarding process the end user uploads the device's x.509 certificate to the workload orchestration solution 
+- During the onboarding process the end user uploads the device's x.509 certificate to the WFM solution 
 - The device's management client downloads the root CA certificate using the [Onboarding API](../../margo-api-reference/workload-api/onboarding-api/rootca-download.md)
 - Once this is complete, both parties are able to [secure their payloads](../../margo-api-reference/margo-api-specification.md#signing-payloads). 
 
@@ -110,7 +110,7 @@ Once the edge device has a message prepared for the Workload Fleet Management's
         - This identifier MUST be the GUID provided by the device manufacturer. Typically the hardware serial number. 
 - The envelope is sent as the payload to the Workload Fleet Management's web service. 
 - The Workload Fleet Management's web service treats the request's payload as envelope structure, and receives the certificate identifier.
-> Note: This certificate is the device certificate that was manually uploaded to the workload orchestration solution during onboarding. 
+> Note: This certificate is the device certificate that was manually uploaded to the WFM solution during onboarding. 
 - The Workload Fleet Management's web service computes digest from the payload, and verifies the signature using the device certification.
 - The payload is then processed by the Workload Fleet Management's web service.