From 29343fc2efc528031dbbbde0e86f3e49491e3ba6 Mon Sep 17 00:00:00 2001 From: George Fletcher Date: Wed, 26 Jun 2024 11:29:11 -0400 Subject: [PATCH 1/7] Update draft-saxe-wimse-token-exchange-and-translation-protocol.md Updated structure of the document --- ...token-exchange-and-translation-protocol.md | 24 ++++++++++++++----- 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/draft-saxe-wimse-token-exchange-and-translation-protocol.md b/draft-saxe-wimse-token-exchange-and-translation-protocol.md index 38ee23f..a59ee75 100644 --- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md +++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md @@ -71,7 +71,20 @@ TODO: Define the need for token exchange & translation - refer to the use cases. This specification defines a protocol for converting from one security token to another with support for high fidelity and lossy conversions. We refer to the high fidelity exchange as "token exchange" as has been embodied in OAuth 2.0 Token Exchange (RFC8693). We profile RFC8693 to enable OAuth token exchange for workloads where the output is an OAuth Access Token or Refresh Token. "Token translation" describes all other conversions, including those where data loss may occur during conversion. This protocol does not define the specifics of token translation between arbitrary token types. Profiles must be defined to describe token translations between different token types, including any loss of context during translation. Where the input and output token are of the same type, and the protocol herein is sufficient to meet the use cases defined in . -## Token Exchange vs. Token Translation + +# Notational Conventions + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 {{RFC2119}} {{RFC8174}} when, and only when, they appear in all capitals, as shown here. + + +# Terminology + +TODO: Define terms used by this specification + + +# Overview + +TODO: high level description of the token translation flow TODO - define exchange vs. translation in terms of RFC8693 and WS-Trust. Translation may be perfect or introduce lost context @@ -79,10 +92,6 @@ Token translation fills a gap that workloads must reinvent today. For example, Token translation accounts for different token types, formats, encodings, and encyryption allowing for translation between most, but not all, token types using token translation profiles. Profiles are not required when the input and output token are the same type. Not all token input/output pairs are expected to be profiled. During translation, the token translation service (TTS) may add, replace, or remove contextual data including attestations, validity constraints, and subjects. Cryptographic operations on the tokens may be replaced or supplemented, such as by adding PQC algorithms to a token encrypted and signed with classical algorithms. For each use case defined in , this document defines the protocol requirements. -## Token Translation Endpoint - -TODO - Define a new translation endpoint. - ## Token Context Enrichment TODO - what context do we enrich tokens with during translation? Embedding tokens, attestations, assertions, validity, change/add subject, sender constraints. This doc can give specific guidance on adding context to a scoped set of token types that are common. Maybe a reference to the use cases is sufficient, along with a short description of any fields that the translation endpoint MUST add to a newly issued token. @@ -97,8 +106,11 @@ Translation may be lossy or lossless, such as when exchanging an input token for For example, assume the token translation endpoint receives a input SAML token with signed claims over the user's full name, user ID, email address, and a list of groups. The output token format, T, only carries the user ID and list of groups (in addition to signatures and other metadata). The token translation endpoint will follow the SAML -> T profile, mapping the context from input to output tokens, and dropping the user's full name and email address in the output token. While data loss has occurred, the data lost was meaningless to the downstream systems consuming the token, T. Lossy translation may impact downstream systems. Implementers must be aware of the risks of lost context through token translation chains. +# Token Translation Endpoint + +TODO - Define a new translation endpoint. -## Token Translation Profiles +# Token Translation Profiles TODO - this draft does not define normative specs for translating from arbitrary format to another arbitrary format. Profiles describing specific token translations must be developed and their names (possibly?) registered with IANA. Profiles will define any losses that may occur during translation and the risks associated with the loss of context. Not all token pairs can be translated, some may only be translatable in one direction. From e4902deef845d3b101cc5e619339f48075156874 Mon Sep 17 00:00:00 2001 From: George Fletcher Date: Wed, 26 Jun 2024 11:48:09 -0400 Subject: [PATCH 2/7] Update draft-saxe-wimse-token-exchange-and-translation-protocol.md Fixed syntax errors and removed `-latest1` from the doc name as the instructions say not to add it. --- ...-saxe-wimse-token-exchange-and-translation-protocol.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-saxe-wimse-token-exchange-and-translation-protocol.md b/draft-saxe-wimse-token-exchange-and-translation-protocol.md index a59ee75..d381517 100644 --- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md +++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md @@ -23,7 +23,7 @@ title: WIMSE Token Exchange and Translation Protocol abbrev: WIMSE Token Exchange & Translation category: info -docname: draft-saxe-wimse-token-exchange-and-translation-protocol-latest +docname: draft-saxe-wimse-token-exchange-and-translation-protocol submissiontype: IETF # also: "independent", "editorial", "IAB", or "IRTF" number: 1 date: @@ -67,7 +67,7 @@ The specification defines the processes of token exchange and token translation TODO: What is a security token? What is a STS? (see https://datatracker.ietf.org/doc/html/rfc8693, the intro has great definitions) -TODO: Define the need for token exchange & translation - refer to the use cases. +TODO: Define the need for token exchange & translation - refer to the use cases. This specification defines a protocol for converting from one security token to another with support for high fidelity and lossy conversions. We refer to the high fidelity exchange as "token exchange" as has been embodied in OAuth 2.0 Token Exchange (RFC8693). We profile RFC8693 to enable OAuth token exchange for workloads where the output is an OAuth Access Token or Refresh Token. "Token translation" describes all other conversions, including those where data loss may occur during conversion. This protocol does not define the specifics of token translation between arbitrary token types. Profiles must be defined to describe token translations between different token types, including any loss of context during translation. Where the input and output token are of the same type, and the protocol herein is sufficient to meet the use cases defined in . @@ -94,11 +94,11 @@ Token translation accounts for different token types, formats, encodings, and en ## Token Context Enrichment -TODO - what context do we enrich tokens with during translation? Embedding tokens, attestations, assertions, validity, change/add subject, sender constraints. This doc can give specific guidance on adding context to a scoped set of token types that are common. Maybe a reference to the use cases is sufficient, along with a short description of any fields that the translation endpoint MUST add to a newly issued token. +TODO - what context do we enrich tokens with during translation? Embedding tokens, attestations, assertions, validity, change/add subject, sender constraints. This doc can give specific guidance on adding context to a scoped set of token types that are common. Maybe a reference to the use cases is sufficient, along with a short description of any fields that the translation endpoint MUST add to a newly issued token. ## Lossy Translation -TODO - define what we mean by lossy. What's lost? Does this mean that some token translations lose valuable information? +TODO - define what we mean by lossy. What's lost? Does this mean that some token translations lose valuable information? TODO - provide a specific lossy scenario and use case. Translation may be lossy or lossless, such as when exchanging an input token for an output token of the same format. From 5fd2c34fdf6be1f369382056e37d2581f7705334 Mon Sep 17 00:00:00 2001 From: George Fletcher Date: Wed, 26 Jun 2024 11:50:04 -0400 Subject: [PATCH 3/7] Update draft-saxe-wimse-token-exchange-and-translation-protocol.md fixing more bugs... reinstating `-latest` no sure why --- draft-saxe-wimse-token-exchange-and-translation-protocol.md | 2 +- 1 file changed, 1 insertion(+), 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 d381517..0961649 100644 --- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md +++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md @@ -23,7 +23,7 @@ title: WIMSE Token Exchange and Translation Protocol abbrev: WIMSE Token Exchange & Translation category: info -docname: draft-saxe-wimse-token-exchange-and-translation-protocol +docname: draft-saxe-wimse-token-exchange-and-translation-protocol-latest submissiontype: IETF # also: "independent", "editorial", "IAB", or "IRTF" number: 1 date: From 10ccf3cac6609ffd8d2a5d4cc0158a98d355a170 Mon Sep 17 00:00:00 2001 From: George Fletcher Date: Wed, 26 Jun 2024 12:00:37 -0400 Subject: [PATCH 4/7] Update draft-saxe-wimse-token-exchange-and-translation-protocol.md Trying to fix build issues From a35b1b30c51b2a66d3f43b60d90dbdd2ce2af0ae Mon Sep 17 00:00:00 2001 From: George Fletcher Date: Wed, 26 Jun 2024 12:16:54 -0400 Subject: [PATCH 5/7] Update draft-saxe-wimse-token-exchange-and-translation-protocol.md Last attempt to fix build issues. I don't see any change between this and the previous version but I used the data from the error message directly. --- draft-saxe-wimse-token-exchange-and-translation-protocol.md | 1 + 1 file changed, 1 insertion(+) diff --git a/draft-saxe-wimse-token-exchange-and-translation-protocol.md b/draft-saxe-wimse-token-exchange-and-translation-protocol.md index 0961649..47e83b5 100644 --- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md +++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md @@ -24,6 +24,7 @@ abbrev: WIMSE Token Exchange & Translation category: info docname: draft-saxe-wimse-token-exchange-and-translation-protocol-latest + submissiontype: IETF # also: "independent", "editorial", "IAB", or "IRTF" number: 1 date: From fde26a7bd6ed4c26e3102aad989084f28ab2ab3c Mon Sep 17 00:00:00 2001 From: George Fletcher Date: Mon, 1 Jul 2024 10:16:25 -0400 Subject: [PATCH 6/7] Update draft-saxe-wimse-token-exchange-and-translation-protocol.md Fix build issues and include normative references to other specs --- ...token-exchange-and-translation-protocol.md | 24 +++++++++++++++++-- 1 file changed, 22 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 a2bd96f..eb66283 100644 --- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md +++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md @@ -34,13 +34,33 @@ author: email: george.fletcher@capitalone.com normative: + RFC2119: # Keywords + RFC6750: #OAuth + RFC8174: # Ambiguity in Keywords + RFC8693: # OAuth 2.0 Token Exchange + + OIDC: + title: OpenID Connect Core 1.0 incorporating errata set 1 + target: https://openid.net/specs/openid-connect-core-1_0.html + author: + - name: Nat Sakimura + org: NRI + - name: John Bradley + org: Ping Identity + - name: Mike Jones + org: Microsoft + - name: B. de Medeiros + org: Google + - name: Chuck Mortimore + org: Salesforce + date: 2014-11 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 "Use Cases Doc". --- middle @@ -66,7 +86,7 @@ TODO: Define terms used by this specification Token translation fills a gap that development teams must solve for themselves today without standardized mechanisms. For example, a common SPIFFE use case is to have a Kubernetes workload assume an AWS IAM role to access an S3 bucket. This is accomplished by creating an OpenID Provider (OP) in the Kubernetes cluster and configuring AWS IAM as a Relying Party (RP) to obtain an ID token from the SPIFFE service. Using the id token, AWS STS AssumeRoleWithWebIdentity generates temporary sigV4 credentials for AWS allowing the workload to assume an AWS role and any permissions assigned to that role. Similar mechanisms have been designed to support multiple cloud providers in the absence of standardized protocols. -Token translation accounts for different token types, formats, encodings, and encyryption allowing for translation between most, but not all, token types using token translation profiles. This protocol does not define the specifics of token translation between arbitrary token types. Profiles must be defined to describe token translations between different token types, including any loss of context during translation. Where the input and output token are of the same type and the conversion is lossless, the protocol defined within this document is sufficient to meet the use cases defined in . Not all token input/output pairs are expected to be profiled. +Token translation accounts for different token types, formats, encodings, and encyryption allowing for translation between most, but not all, token types using token translation profiles. This protocol does not define the specifics of token translation between arbitrary token types. Profiles must be defined to describe token translations between different token types, including any loss of context during translation. Where the input and output token are of the same type and the conversion is lossless, the protocol defined within this document is sufficient to meet the use cases defined in "USE CASES DOC". Not all token input/output pairs are expected to be profiled. ## Token Context Enrichment From 23feb65766e2cf0d6fe1cd304978c8a86f3d9372 Mon Sep 17 00:00:00 2001 From: Dmitry Date: Mon, 1 Jul 2024 22:48:59 -0700 Subject: [PATCH 7/7] Update draft-saxe-wimse-token-exchange-and-translation-protocol.md Co-authored-by: Andrii Deinega --- draft-saxe-wimse-token-exchange-and-translation-protocol.md | 2 +- 1 file changed, 1 insertion(+), 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 eb66283..638b290 100644 --- a/draft-saxe-wimse-token-exchange-and-translation-protocol.md +++ b/draft-saxe-wimse-token-exchange-and-translation-protocol.md @@ -40,7 +40,7 @@ normative: RFC8693: # OAuth 2.0 Token Exchange OIDC: - title: OpenID Connect Core 1.0 incorporating errata set 1 + title: OpenID Connect Core 1.0 incorporating errata set 2 target: https://openid.net/specs/openid-connect-core-1_0.html author: - name: Nat Sakimura