-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define WIMSE URI #49
Comments
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. |
@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. |
resolved by PR #82 by removing references WIMSE URI and using WIMSE Identity instead |
Commenting as identity enthusiast as opposed to WIMSE co-chair:
Section 5 introduces the term "WIMSE URI" - if this is defined in the architecture document, it should be referenced. If this is defined in Section 3, perhaps rename as workload identitifier.
The text was updated successfully, but these errors were encountered: