Workload Identifier IMHO, and see #31.

I prefer the URI to be defined once, in the arch doc.

Brian: define it here.

Arndt: should coexist nicely with K8s. Joe: but do they have the notion of a trust domain.

RFC5280 defines a URI SAN for certificates. These URIs must conform to RFC 3986. This includes both the URL and URN schemes. The main restriction is that 5280 does not allow relative URIs and a scheme must be included, the authority component is optional. This gives some flexibility and it might even be possible to represent a k8s URN in this filed under the urn scheme, but I'm not sure it would be a good idea.
I think we should specify that a URI MUST meet the criterial of 5280 and that any scheme that is used SHOULD specify an authority component that is a domain name. If present, he authority portion MUST be used to map the name to the trust domain parameters used to validate a WIT or certificate containing the name. If the authority field is not present then the mapping of the identity to trust domain parameters MUST be done through a locally specified mechanism that is beyond the scope of this specification.

@jsalowey Why should we even worry about relative URIs? It seems weird for a certificate IMHO. We could simplify the whole thing by saying MUST meet the criteria of 5280 and MUST have an authority component. Have you seen relative URIs "in the wild" in similar situations?

K8s appears to use some form of URNs that do not have an authority component. They are just a colon separated series of names. But I am happy to say the URI must meet the criteria of 5280 and MUST have an authority component that identifies a trust domain.

See PR #61 and #62

resolved by PR #82 by removing references WIMSE URI and using WIMSE Identity instead