From ba549fe4ff11feafe5c2267a8ab56329fc527453 Mon Sep 17 00:00:00 2001 From: "Dean H. Saxe - AWS Identity" <33666281+dhs-aws@users.noreply.github.com> Date: Fri, 28 Jun 2024 15:48:16 -0700 Subject: [PATCH 1/2] Update draft-saxe-wimse-token-exchange-and-translation-protocol.md Fixing normative references --- draft-saxe-wimse-token-exchange-and-translation-protocol.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-saxe-wimse-token-exchange-and-translation-protocol.md b/draft-saxe-wimse-token-exchange-and-translation-protocol.md index c186a17..b77d40f 100644 --- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md +++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md @@ -33,13 +33,14 @@ author: email: george.fletcher@capitalone.com normative: + RFC8693: informative: --- abstract -The specification defines the processes of token exchange and token translation for workloads. Token exchange is well defined for OAuth 2.0 in RFC8693, allowing the exchange of access tokens, refresh tokens, OpenID Connect ID Token ({{OIDC}}), and SAML assertions for new OAuth access tokens. However, for workloads, there exist a broad array of input and output token types which must be considered beyond the input types supported by {{RFC8693}}. These token types include, but are not limited to, SPIFFE SVIDs, x.509 certificates, Amazon sigv4A, macaroons, <...>. Further, these tokens may be encoded in formats including JWT, CBOR, and protocol buffers (protobufs). Given the variety and complexity of input and output token types and encoding, a strict token exchange that maintains all of the contextual information from the input token to the output token may not be possible. We define these non-RFC8693 use cases with potentially lossy conversions as "token translation" (e.g. information may be lost in translation). In this document we describe a workload profile for token exchange, using the mechanisms in {{RFC8693}}, and a new set of translations between arbitrary token types. Additionally, we define mechanisms to enrich tokens during translation to support the use cases defined in . +The specification defines the processes of token exchange and token translation for workloads. Token exchange is well defined for OAuth 2.0 in {{RFC8693}}, allowing the exchange of access tokens, refresh tokens, OpenID Connect ID Token (OIDC), and SAML assertions for new OAuth access tokens. However, for workloads, there exist a broad array of input and output token types which must be considered beyond the input types supported by {{RFC8693}}. These token types include, but are not limited to, SPIFFE SVIDs, x.509 certificates, Amazon sigv4A, macaroons, <...>. Further, these tokens may be encoded in formats including JWT, CBOR, and protocol buffers (protobufs). Given the variety and complexity of input and output token types and encoding, a strict token exchange that maintains all of the contextual information from the input token to the output token may not be possible. We define these non-RFC8693 use cases with potentially lossy conversions as "token translation" (e.g. information may be lost in translation). In this document we describe a workload profile for token exchange, using the mechanisms in {{RFC8693}}, and a new set of translations between arbitrary token types. Additionally, we define mechanisms to enrich tokens during translation to support the use cases defined in . --- middle From 53aaa3f2beb118018081c464888d02ea2318303d Mon Sep 17 00:00:00 2001 From: "Dean H. Saxe - AWS Identity" <33666281+dhs-aws@users.noreply.github.com> Date: Wed, 3 Jul 2024 12:39:08 -0700 Subject: [PATCH 2/2] Added changes recommended by @adeinega --- draft-saxe-wimse-token-exchange-and-translation-protocol.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/draft-saxe-wimse-token-exchange-and-translation-protocol.md b/draft-saxe-wimse-token-exchange-and-translation-protocol.md index c6e45c5..ab0899c 100644 --- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md +++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md @@ -39,9 +39,11 @@ author: normative: RFC2119: # Keywords - RFC6750: #OAuth + RFC6750: # OAuth RFC8174: # Ambiguity in Keywords + RFC8392: # CBOR Web Token (CWT) RFC8693: # OAuth 2.0 Token Exchange + RFC9068: # JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens OIDC: title: OpenID Connect Core 1.0 incorporating errata set 2 @@ -66,7 +68,7 @@ informative: --- abstract -The specification defines the processes of token exchange and token translation for workloads. Token exchange is well defined for OAuth 2.0 in {{RFC8693}}, allowing the exchange of access tokens, refresh tokens, OpenID Connect ID Token (OIDC), and SAML assertions for new OAuth access tokens. However, for workloads, there exist a broad array of input and output token types which must be considered beyond the input types supported by {{RFC8693}}. These token types include, but are not limited to, SPIFFE SVIDs, x.509 certificates, Amazon sigv4A, macaroons, <...>. Further, these tokens may be encoded in formats including JWT, CBOR, and protocol buffers (protobufs). Given the variety and complexity of input and output token types and encoding, a strict token exchange that maintains all of the contextual information from the input token to the output token may not be possible. We define these non-RFC8693 use cases with potentially lossy conversions as "token translation" (e.g. information may be lost in translation). In this document we describe a workload profile for token exchange, using the mechanisms in {{RFC8693}}, and a new set of translations between arbitrary token types. Additionally, we define mechanisms to enrich tokens during translation to support the use cases defined in . +The specification defines the processes of token exchange and token translation for workloads. Token exchange is introduced in {{RFC8693}}, allowing the exchange of access tokens, refresh tokens, OpenID Connect ID Token (OIDC), and SAML assertions for new OAuth access tokens. However, for workloads, there exist a broad array of input and output token types which must be considered beyond the input types supported by {{RFC8693}}. These token types include, but are not limited to, SPIFFE SVIDs, x.509 certificates, Kerberos service tickets, Amazon sigv4A, macaroons, <...>. Further, these tokens may be encoded in formats including JWT OAuth 2.0 Acesss Tokens {{RFC9068}}, CWT {{RFC8392}}, and protocol buffers (protobufs). Given the variety and complexity of input and output token types and encoding, a strict token exchange that maintains all of the contextual information from the input token to the output token may not be possible. We define these non-RFC8693 use cases with potentially lossy conversions as "token translation" (e.g. information may be lost in translation). In this document we describe a workload profile for token exchange, using the mechanisms in {{RFC8693}}, and a new set of translations between arbitrary token types. Additionally, we define mechanisms to enrich tokens during translation to support the use cases defined in . --- middle