Integrate MIAF and WFM identity profile SUPs - #25
Conversation
phil-abb
left a comment
phil-abb
left a comment
There was a problem hiding this comment.
I did an initial review and didn't spot anything to comment on.
Integrate the MIAF and WFM Identity Profile SUPs into the concepts and lexicon: add the Identity and Trust page, rewrite device client onboarding around operator-provisioned SVIDs and mTLS, and add MIAF identity terms. Signed-off-by: Matthias Lechner <matlec.public@gmail.com>
The trust bundle is served as a single SPIFFE bundle, not a SPIFFE Bundle Map. Signed-off-by: Matthias Lechner <matlec.public@gmail.com>
32c9123 to
1ca3aa7
Compare
|
|
||
| ## Why identity lives at the Trust Domain level | ||
|
|
||
| A single industrial deployment often mixes hardware and software from several vendors. One environment might run more than one Workload Fleet Manager, from different suppliers, each managing its own devices. If each WFM defined its own identities and distributed its own trust anchors, nothing would recognize anything issued elsewhere, and every pairing of components would need its own bespoke trust setup. |
There was a problem hiding this comment.
I recommend a reword on this paragraph, removing the notion of many fleet managers as Margo is trying to solve that issue :).
Recommendation is to reword to "many vendors of apps and devices with a fleet manager"
| A Container Image Registry hosts container images. [Components](#component) which are provided as Helm Charts or Compose Archives link to such container images. No newline at end of file | ||
| A Container Image Registry hosts container images. [Components](#component) which are provided as Helm Charts or Compose Archives link to such container images. | ||
|
|
||
| ## Identity Terms |
There was a problem hiding this comment.
I'm questioning the need for the technical details supplied in this section. URI forms / spiffee forms for WFM Identity and WFM Client identity.
I think we can simplify these descriptions, then utilizing the links you have provided to enable the user to go "deeper" into the technical details within the concepts or specification sections.
|
|
||
| #### Principal | ||
|
|
||
| A non-human Margo component that holds, or is being provisioned with, an identity in a [Trust Domain](#trust-domain). [Edge Compute Devices](#edge-compute-device), [Workload Fleet Managers](#workload-fleet-manager), and WFM Clients are all principals. |
There was a problem hiding this comment.
Just something small here, but in this section we are treating edge devices and wfm clients as seperate principal entities in Margo.
I think it would read cleaner if we removed Edge Compute Devices since the WFM Client is the actual entity receiving a spiffee id from the trust domain.
| @@ -1,43 +1,76 @@ | |||
| # Device Client Onboarding | |||
There was a problem hiding this comment.
Would it be too controversial to rename this WFM Client Onboarding.
I'm sensitive to the fact the client can represent 1 to many devices. This still reads as a 1 to 1.
3 participants
Description
Integrates the two voted MIAF SUPs into the concepts and lexicon. This is the non-normative companion to the specification PR.
What changes
Issues Addressed
Change Type
Please select the relevant options:
Checklist