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

github at oidf.org github at oidf.org
Tue Aug 4 17:14:34 UTC 2026


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: Thanks for the clarification, that makes a lot of sense. I had a hunch there should be some way to express this in SPIFFE, but I wasn't aware the hierarchical path itself could carry instance-level detail without needing a separate identifier field, that's a cleaner solution than what I had in mind when I filed this. One follow-up though: since every example in the current spec text stops at the workload/class level (including the workload-compromised example itself), as a newer reader I assumed that was the expected norm and that instance-level detail wasn't really part of the intended usage. Given that this pattern solves the exact problem this issue raised, would it be worth calling it out explicitly in the spec, maybe a short note or recommendation that Transmitters SHOULD use a more specific path when an event is inherently instance-scoped (like workload-compromised), along with an example? Right now it's really only discoverable by asking, and it seems like a useful enough pattern that it shouldn't be left purely to deployment convention. Appreciate you taking the time to explain, still working my way through WIMSE/SPIFFE conventions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20260804/e8ad2224/attachment.htm>


More information about the Openid-specs-risc mailing list