Define Margo strategy for Device identity and authorization

[ajcraig]

Feature description

Goal: Provide an interoperable strategy for device identity and authentication between vendors within the Margo ecosystem.

Interoperability in Margo is built on the idea that different components - apps, edge devices, and fleet managers - can work together without pre-arranged integration. That only works if each component can be reliably recognized and accepted by the others. The current WFM API finalized for PR1 uses RFC 9421 HTTP Message Signatures to authenticate device clients through their X.509 certificates.

A shared Margo mechanism for registering and distributing trust anchors - and defining common renewal and revocation procedures - would give all components, regardless of vendor, a reliable operational baseline for managing device certificates.

Provide adequate technical acceptance criteria(s) associated with this feature below:

• Defined device identity strategy: clear rules for how edge devices establish, renew, rotate, and retire their identities
• Inter-vendor authentication: a way for edge devices, Device Fleet Managers, and Workload Fleet Managers from different vendors to recognize each other without manual or vendor-specific setup.
  • shared mechanism for registering and distributing trust anchors between vendors
• Margo standard schema for representing a device identity

Non functional requirements:

• Ensure this approach does not break existing proprietary or standards based methods for device onboarding.
• Ensure this device identity strategy integrates with the existing Client_ID utilized via the Workload Fleet Managers.

Although not required, it is highly encouraged to provide feature use-cases below:

• Scoped authorization model - authenticated clients use their identity to obtain short-lived, operation-specific tokens, would allow components to enforce least-privilege access consistently.
• Enables 'non Margo' services such as observability platforms and device management(vendor specific implementations) to utilize the same identity and trust anchors.
• Emerging proposals, such as the gateway SUP - which proposes to extend the Workload Fleet Manager concept to support gateways that act on behalf of multiple devices - make this feature even more relevant.
  • Such scenarios will depend on clear identity relationships and scoped authorization to prevent privilege overlap between a gateway and the devices it represents.

Additional information

No response