[Openid-specs-risc] openid/sharedsignals: Comment created on issue 346

[github at oidf.org]

openid/sharedsignals event

Issue Comment created on issue 346
Issue Title: Subject identifiers don't support instance-level granularity
https://github.com/openid/sharedsignals/issues/346

Comment: It depends on how the WIMSE identifier is constructed, and that is a deployment issue. SPIFFE/WIMSE identifiers are hierarchical, which means that you can use the path to identifiy a workload down to the instance level. A common practice is to have the workload type identified and then have addditional details about the specific instance. For example: wimse://trust.domain.com/workloadname/region/instance Where: wimse://trust.domain.com -> indicates the issuer /workloadname -> indicates the class of workload /region -> indicates a specific region or datacenter /instance -> inidcates a specific instance (e.g. a K8S cluster it might be running or another unique identifier assigned by the issuer for identifying the workload instance) Authorization logic can be specific to a workload class, the region (or other specifics) or down to an instance (which is usually ignored, but retaiened for audit pruposes). So you authenticate and authorize only on a subset of the identifier (the part that is relevant) and retain the ffull identifier for audit purposes. From an eventing perspective, I can see that you may need to issue an event on a specific instance or on the class (e.g. a SVE related to that specific implementation). These are examples only and there are different conventions, typically deployment specific, for how to express this ever increasing speccificity of a workload. It removes the need for additional identifiers, which becomes problematic in very large scale deployments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20260804/5bfbc181/attachment.htm>