From 5d0da843e87957a147a8fd4b3e0891c543f944e3 Mon Sep 17 00:00:00 2001 From: Joe Salowey Date: Thu, 19 Sep 2024 17:39:08 -0700 Subject: [PATCH 1/4] Define Trust Domain --- draft-ietf-wimse-s2s-protocol.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md index b6b44c1..d72b8d5 100644 --- a/draft-ietf-wimse-s2s-protocol.md +++ b/draft-ietf-wimse-s2s-protocol.md @@ -153,6 +153,10 @@ This document defines a workload identity as a URI {{!RFC3986}}. This URI is use A workload identity only has meaning within the scope of a specific issuer. Two identities of the same value issued by different issuers may or may not refer to the same workload. In order to avoid collisions identity URIs SHOULD specify, in the URI's "authority" field, the trust domain associated with an issuer that is selected from a global name space such as host domains. However, the validator of an identity credential MUST make sure that they are using the correct issuer credential to verify the identity credential and that the issuer is trusted to issue tokens for the defined trust domain. +## Trust Domain + +A trust domain is the authority that issues wimse certificates and tokens. Trust domains SHOULD be identified by a fully qualified domain name belonging to the organization defining the trust domain. A trust domain maps to a trust anchor for validating X.509 certificates and a mechanism to securely obtain a JWK Set {{!RFC7517}} for validating wimse WIT tokens. This mapping MUST be obtained through a secure mechanism that ensures the authenticity and integrity of the mapping is fresh and not compromised. + # Application Level Service To Service Authentication {#app-level} As noted in the Introduction, for many deployments communication between workloads cannot use From 1dd707ffabdb43aa80e5771f7ed19341fdbbfa5d Mon Sep 17 00:00:00 2001 From: Joe Salowey Date: Thu, 19 Sep 2024 17:50:24 -0700 Subject: [PATCH 2/4] added some ore on trust domains --- draft-ietf-wimse-s2s-protocol.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md index d72b8d5..8c3143e 100644 --- a/draft-ietf-wimse-s2s-protocol.md +++ b/draft-ietf-wimse-s2s-protocol.md @@ -149,13 +149,19 @@ This document uses "service" and "workload" interchangeably. Otherwise, all term # Workload Identity {#whimsical-identity} +## Trust Domain + +A trust domain is the authority that issues wimse certificates and tokens. Trust domains SHOULD be identified by a fully qualified domain name belonging to the organization defining the trust domain. +A trust domain maps to a trust anchor for validating X.509 certificates and a mechanism to securely obtain a JWK Set {{!RFC7517}} for validating wimse WIT tokens. This mapping MUST be obtained through a secure mechanism that ensures the authenticity and integrity of the mapping is fresh and not compromised. + +A single organization may define multiple trust domains for different purpose such as different departments or environments. Each trust domain must have a unique identifier. Workload identifiers are scoped within a trust domain. If two identifiers differ only by trust domain they still refer to two different entities. + +## Workload Identifier + This document defines a workload identity as a URI {{!RFC3986}}. This URI is used in the subject fields in the certificates and tokens defined later in this document. This specification treats the URI as opaque. The format of the URI and the namespace for the URI are at the discretion of the deployment at large. Other specifications may define specific URI structures for particular use cases. An example of a defined identity format is the [SPIFFE ID](https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md). A workload identity only has meaning within the scope of a specific issuer. Two identities of the same value issued by different issuers may or may not refer to the same workload. In order to avoid collisions identity URIs SHOULD specify, in the URI's "authority" field, the trust domain associated with an issuer that is selected from a global name space such as host domains. However, the validator of an identity credential MUST make sure that they are using the correct issuer credential to verify the identity credential and that the issuer is trusted to issue tokens for the defined trust domain. -## Trust Domain - -A trust domain is the authority that issues wimse certificates and tokens. Trust domains SHOULD be identified by a fully qualified domain name belonging to the organization defining the trust domain. A trust domain maps to a trust anchor for validating X.509 certificates and a mechanism to securely obtain a JWK Set {{!RFC7517}} for validating wimse WIT tokens. This mapping MUST be obtained through a secure mechanism that ensures the authenticity and integrity of the mapping is fresh and not compromised. # Application Level Service To Service Authentication {#app-level} From 114ba5505b119bafe4cfff2ab8fe4cb59c276fa2 Mon Sep 17 00:00:00 2001 From: jsalowey Date: Thu, 26 Sep 2024 07:05:02 -0700 Subject: [PATCH 3/4] Update draft-ietf-wimse-s2s-protocol.md Co-authored-by: Yaron Sheffer --- draft-ietf-wimse-s2s-protocol.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md index 8c3143e..dc8d461 100644 --- a/draft-ietf-wimse-s2s-protocol.md +++ b/draft-ietf-wimse-s2s-protocol.md @@ -151,8 +151,8 @@ This document uses "service" and "workload" interchangeably. Otherwise, all term ## Trust Domain -A trust domain is the authority that issues wimse certificates and tokens. Trust domains SHOULD be identified by a fully qualified domain name belonging to the organization defining the trust domain. -A trust domain maps to a trust anchor for validating X.509 certificates and a mechanism to securely obtain a JWK Set {{!RFC7517}} for validating wimse WIT tokens. This mapping MUST be obtained through a secure mechanism that ensures the authenticity and integrity of the mapping is fresh and not compromised. +A trust domain is the authority that issues WIMSE certificates and tokens. Trust domains SHOULD be identified by a fully qualified domain name belonging to the organization defining the trust domain. +A trust domain maps to one or more trust anchors for validating X.509 certificates and a mechanism to securely obtain a JWK Set {{!RFC7517}} for validating WIMSE WIT tokens. This mapping MUST be obtained through a secure mechanism that ensures the authenticity and integrity of the mapping is fresh and not compromised. This secure mechanism is out of scope for this document. A single organization may define multiple trust domains for different purpose such as different departments or environments. Each trust domain must have a unique identifier. Workload identifiers are scoped within a trust domain. If two identifiers differ only by trust domain they still refer to two different entities. From 2d189c6ad131cfa51ced87194c8df2256dc5705a Mon Sep 17 00:00:00 2001 From: Joe Salowey Date: Sat, 12 Oct 2024 14:44:01 -0700 Subject: [PATCH 4/4] Revised initial sentence --- draft-ietf-wimse-s2s-protocol.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md index dc8d461..4ded89c 100644 --- a/draft-ietf-wimse-s2s-protocol.md +++ b/draft-ietf-wimse-s2s-protocol.md @@ -151,7 +151,7 @@ This document uses "service" and "workload" interchangeably. Otherwise, all term ## Trust Domain -A trust domain is the authority that issues WIMSE certificates and tokens. Trust domains SHOULD be identified by a fully qualified domain name belonging to the organization defining the trust domain. +A trust domain is a logical grouping of systems that share a common set of security controls and policies. WIMSE certificates and tokens are issued under the authority of a trust domain. Trust domains SHOULD be identified by a fully qualified domain name belonging to the organization defining the trust domain. A trust domain maps to one or more trust anchors for validating X.509 certificates and a mechanism to securely obtain a JWK Set {{!RFC7517}} for validating WIMSE WIT tokens. This mapping MUST be obtained through a secure mechanism that ensures the authenticity and integrity of the mapping is fresh and not compromised. This secure mechanism is out of scope for this document. A single organization may define multiple trust domains for different purpose such as different departments or environments. Each trust domain must have a unique identifier. Workload identifiers are scoped within a trust domain. If two identifiers differ only by trust domain they still refer to two different entities.