Define the standard mechanism for compose enabled devices to authenticate and pull Compose Archive

[ajcraig]

Feature description

Goal: Define the standard way for compose enabled devices to authenticate and pull the application deployment package(compose file(s)).

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

• Define standard mechanism for devices to authenticate and pull the compose archive packages from a location.
• If multiple storage locations are to be proposed(HTTPS / OCI), integrate within the device capabilities
• If multiple storage locations are to be supported, ensure authentication methods are provided and detailed for both.

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

Managing workloads on compose enabled devices, ensuring the pointer the wfm provides in the deployment specification can be acted upon via the same or 3rd party device.

Additional information

HTTPs along with OCI were present in various Margo discussions and plugfests.

[jachstet-sea]

Authentication is only one point here. The others being:

• Do we expect devices to be able to pull stuff "from the outside world" / open internet or do we expect that the WFM (and an OCI registry, which might be local or on the internet as well) are the only points a device will be allowed to talk to?
• Will a device need to trust the "usual trust anchors" / CAs that a "normal" web browser or OS would trust? Or is it fair to assume that only a limited set of CAs are trusted? Or is this a user-configurable setting?
• How can downloaded artifacts be verified by the device? Files (application packages) hosted via OCI could be signed using notation, files downloaded via HTTPS could be PGP signed?

[nilanjan-samajdar]

This feature is being specified in the following SUP - margo/specification-enhancements#68