Skip to content

Commit

Permalink
Merge branch 'fix-lint-errors' into main
Browse files Browse the repository at this point in the history
  • Loading branch information
dhs-aws authored Jul 3, 2024
2 parents 4523019 + d32e46b commit 57484f5
Showing 1 changed file with 1 addition and 2 deletions.
3 changes: 1 addition & 2 deletions draft-saxe-wimse-token-exchange-and-translation-protocol.md
Original file line number Diff line number Diff line change
Expand Up @@ -67,8 +67,7 @@ informative:

--- abstract


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 <Use Cases Doc>.
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 (todo: add link to use cases doc).


--- middle
Expand Down

0 comments on commit 57484f5

Please sign in to comment.