[Story: ] As a Margo WFM Vendor, I would like to understand how Device Identity will be obtained and used in the REST based communication with a Margo Device Client

[nilanjan-samajdar]

Description

Margo Device Identity SUP proposes replacing device-id with a SVID, which can be obtained as part of x.509 certificate provided in the mTLS setup.

The following information needs to be captured for a reference implementation using the SPIRE framework for SPIFFE.

1. How does SPIRE interact with the WFM Services ?

• How do WFM Microservices extract the WFM Client Id for a mTLS/REST session with a Margo Device Agent ?
• Is there a need for one of the WFM Microservices, acting as the API gateway, to forward either the x.509 certificate in X-Forwarded-Client-Cert HTTP header to the other Microservice
  OR
  the WFM Microservices, acting as the API gateway, extracts the SPIFFE Id and sends it in the x-spiffe-id HTTP Header to the other Microservice ?

2. Is there any need for the Device Client to follow the 'attestation' procedure with a SPIRE Server ?
   The Device Identity / MIAF SUP provides a system for discovery and trust-bundle download.
   Hence with SPIRE, we would want to follow the discovery / trust-bundle download procedure & use the proposed endpoints instead of attestation. Is this possible ?
3. How are the x.509 certificate lifecycle procedure - revocation, renewal and re-issuance performed for a device-agent deployed in production, does it take place in the mTLS connection ?
   With SPIRE, do we have a ready way to implement using the SPIRE client/mTLS, as required by MIAF SUP ?
   [Assuming that in PR2 phase, the enrollment phase happens "out-of-band" before the device and WFM are deployed, full support with automation of enrollment comes in PR3]

Expected Output :

• Create a prototype to evaluate the answers to these questions using SPIRE and a mock Device-Client/WFM Server.
• Create relevant ladder/flow diagram as design inputs

Raised by (email-id)

nilanjan.samajdar@capgemini.com

Type of Story

Prototyping

Related product requirements

Device Identity SUP

MIAF SUP

Definition of Done

In case of any prototyping activity, the evaluation, design and outcomes need to be documented
API updates need to be updated in swagger (or other) files

Estimated Story-points

10

Impacted artifacts

• API Documentation (Swagger)
• User Docmentation
• Reference Implementation Code
• Test Automation

[spulkit138]

How does SPIRE interact with the WFM Services ?

In the recommended deployment model, an operator uses SPIRE to issue (mint) distinct X.509-SVIDs for each principal, such as a WFM and its associated Devices/WFM Clients. These SVIDs are then provisioned to the respective systems through existing operator-managed provisioning mechanisms. Runtime authentication occurs directly between the communicating parties using mTLS and the provisioned SVIDs; SPIRE itself is not part of the authentication path.
SPIRE may additionally be used to publish the Trust Domain's trust material, including the SPIFFE Trust Bundle and related discovery endpoints, in accordance with the MIS responsibilities defined by MIAF. However, enrollment, renewal, re-issuance, and revocation remain operator-driven processes in PR2 and are not performed automatically through SPIRE workload attestation workflows.

How do WFM Microservices extract the WFM Client Id for a mTLS/REST session with a Margo Device Agent ?

In the current implementation, both the WFM (Symphony) and the WFM Client (Device Agent) are deployed as single-service components rather than as collections of independently identified microservices. As a result, identity is established at the principal level using the X.509-SVID presented during the mTLS handshake, rather than through a separate application-level client identifier.
When a Margo Device Agent initiates an mTLS connection to a WFM, the WFM validates the presented X.509-SVID against the Trust Domain's Trust Bundle and extracts the Device Agent's SPIFFE ID from the certificate's URI Subject Alternative Name (URI SAN). The verified SPIFFE ID becomes the authoritative identity of the connecting client and can be used for authorization decisions and request processing.
Likewise, the Device Agent validates the WFM's X.509-SVID during the mTLS handshake and extracts the WFM's SPIFFE ID from the URI SAN of the presented certificate. This allows both parties to establish mutual authentication based on verified SPIFFE identities.

Is there a need for one of the WFM Microservices, acting as the API gateway, to forward either the x.509 certificate in X-Forwarded-Client-Cert HTTP header to the other Microservice OR the WFM Microservices, acting as the API gateway, extracts the SPIFFE Id and sends it in the x-spiffe-id HTTP Header to the other Microservice?

Currently this is not required. Please refer to previous answer.

[spulkit138]

Is there any need for the Device Client to follow the 'attestation' procedure with a SPIRE Server ?

The Device Identity / MIAF SUP provides a system for discovery and trust-bundle download.
Hence with SPIRE, we would want to follow the discovery / trust-bundle download procedure & use the proposed endpoints instead of attestation. Is this possible ?

No. For a PR2-compliant implementation, the Device Client is not required to participate in SPIRE node attestation or workload attestation workflows. MIAF explicitly defines PR2 as an operator-driven provisioning model, where principals obtain their X.509-SVIDs through operator pre-provisioning rather than through an automated enrollment mechanism.

Under the recommended approach, SPIRE is used solely as an implementation of the Margo Identity Service (MIS) role. An operator uses SPIRE to mint X.509-SVIDs for the WFM and Device Client, provisions those credentials through an existing trusted provisioning channel, and distributes the corresponding Trust Bundle required for validation. Runtime authentication is then performed using mTLS and the provisioned SVIDs.

The automated enrollment, attestation, renewal, and revocation mechanisms commonly associated with SPIRE are intentionally outside the scope of PR2 and are deferred to a future release (PR3). Consequently, a Device Client can participate fully in the MIAF trust architecture without performing SPIRE node attestation or workload attestation, provided it has been provisioned with a valid X.509-SVID and the appropriate Trust Bundle.

[spulkit138]

How are the x.509 certificate lifecycle procedure - revocation, renewal and re-issuance performed for a device-agent deployed in production, does it take place in the mTLS connection ?

With SPIRE, do we have a ready way to implement using the SPIRE client/mTLS, as required by MIAF SUP ?
[Assuming that in PR2 phase, the enrollment phase happens "out-of-band" before the device and WFM are deployed, full support with automation of enrollment comes in PR3]

For Production scenarios, there needs to be an automated procedure for revocation, renewal & re-issuance, however all of that is not part of PR2. It is deferred beyond PR2 for discussions. Once that is formalized & normalized, we can implement it.

SPIRE Agent & SPIRE server initial communication happens over TLS (not mTLS), which is also called bootstrapping or node attestation, because the agent does not yet have a SPIFFE identity (Node SVID) to participate in mTLS.

The Agent establishes a TLS connection to the SPIRE Server, but the authentication model depends on the attestor being used, not on an existing SPIFFE mTLS identity. (methods mentioned below are not exhaustive, but are just for explaination)

join_token method
The agent sends the join token as attestation evidence. The token is what authenticates the node during bootstrap, not a client certificate. Therefore this is not mTLS.

x509pop method
The agent presents its externally provisioned certificate and proves possession of the private key. Authentication comes from the x509pop attestation flow, not from SPIFFE mTLS. Although an X.509 certificate is involved, SPIRE still treats this as node attestation evidence rather than an established SPIFFE mTLS identity. The plugin verifies certificate chains and performs a proof-of-possession challenge

Once attestation succeeds:

1. SPIRE issues a Node X509-SVID.
2. Agent stores it.
3. Agent reconnects to Server using the Node SVID.

At this point, the Agent and Server mutually authenticate using SPIFFE identities. This is the stage where SPIFFE mTLS is fully established.

MIAF SUP talks about communication between WFM & WFM client to be mTLS at all times, and it says enrollment (bootstrapping) should be performed by operator. So, technically, Node attestation comes in category of "automated enrollment" or atleast a sub-process of it. And MIAF does not talk about it in PR2, nor does it talk about bootstrapping or enrollment to happen over mTLS.

Furthermore, SPIRE Agent is responsible for automating enrollment, revocation, renewal and re-issuance. But, automating certificate lifecycle items are not defined in PR2, but deferred for upcoming PRs. Right now, Operator Provisioning is what is defined.