[Wimse] Re: Token Exchange design team update

John Kemp <stable.pseudonym@gmail.com> Thu, 13 June 2024 19:08 UTC

Return-Path: <stable.pseudonym@gmail.com>
X-Original-To: wimse@ietfa.amsl.com
Delivered-To: wimse@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5293BC14F6EC for <wimse@ietfa.amsl.com>; Thu, 13 Jun 2024 12:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJA3427qJ85R for <wimse@ietfa.amsl.com>; Thu, 13 Jun 2024 12:08:35 -0700 (PDT)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8066DC14F6F3 for <wimse@ietf.org>; Thu, 13 Jun 2024 12:08:35 -0700 (PDT)
Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-dff0067a263so1600191276.0 for <wimse@ietf.org>; Thu, 13 Jun 2024 12:08:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718305714; x=1718910514; darn=ietf.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=bxngw9NlK8DrTlWQXYbzCPrIcBaDaEZ7uFHJaLIJpW8=; b=Z7hNmLkOOCNpvg/GH779f2DVXLITfeUojWRqwUCotP6F4rW0akqdB6YyDXHv6hvjLB F8iZzu4S513ddlzTZk/OCqD5u46rOIHP0XNzS0pBXC7i/ewBdD6CzPTCh/3ARilMTqwA 8ba1hUFvAkwOkrZmFHZ5cWWKUqiIA0F+OzoWn+GxyuOXbW2GgGmk50JwQQOBhnGoRkEe cE1HSCC1RLH67dLGPpd0M5eBjUa13/6JiAJJToFxtmPqNNctUPsNaY2jalWW4XSxbzni KzlvYfsapCo8NdizxdgLYrx3bY8ryF7av1YGJXZKY/B/+QNXhhgAQXL1Z/VspVE4A7RM p14g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718305714; x=1718910514; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bxngw9NlK8DrTlWQXYbzCPrIcBaDaEZ7uFHJaLIJpW8=; b=cz60fZO2A9gluJfjB6wGNy1ugLmTQp40hX5FODskDRJboJnb8TcAD25xCnpMyyQYTy fQp0MKzRzME0RtlK1smOfrDy5XPyc+8Jm0uBZ6SJ+ei52Hn45dNw2b+G6YJ8Dl8STNip 0SQe37ZB2QXNsqhupOCe6RwXBl68dTFGs1a9+C/0upIDpifXrdP53d1UnaIAnwBMhGLr 19c09KZFku9/dqCsRCjMQ19cxqrH3ROt2nKPhdYGXKjVAl4Pdq9L2Ckj9fUB/wwEictX na1D/L1PPPKB34qKxU2cJlrxjJ5vFqoXWKTNCKFrZ+kaUtoyUfa7CV0FLgcyogRTDZQ7 yz+Q==
X-Gm-Message-State: AOJu0YyPpGolBoRSYvpB5FusqFzDmBRl+Be0ZHkjGzAk1+jcz8HobMPn z89kZy/70Duw6gPFVEEAv7O8MIst/2AkPemAdFpjPwoYLGA+J3ufHbNOJg==
X-Google-Smtp-Source: AGHT+IHNxiESMgMYHCQ9X0x8mvvQbVRw9e1wVWpukvvFGLfTKeacd3Wlx22lGQ9bmcXjtGa2jkiKpw==
X-Received: by 2002:a25:ced1:0:b0:df7:8ab9:c196 with SMTP id 3f1490d57ef6-dff150d35b9mr397520276.0.1718305714115; Thu, 13 Jun 2024 12:08:34 -0700 (PDT)
Received: from [192.168.1.89] (syn-066-066-241-224.res.spectrum.com. [66.66.241.224]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6b2a5bf55f8sm9716866d6.15.2024.06.13.12.08.33 for <wimse@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Jun 2024 12:08:33 -0700 (PDT)
Message-ID: <ff22af7d-1197-413d-9f84-df54b262b38a@gmail.com>
Date: Thu, 13 Jun 2024 15:08:33 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: wimse@ietf.org
References: <CAMtubr2c=c=pE5xV4f1N84y8ACAk98nvf7=F1CCwp3PaQMU_bw@mail.gmail.com> <A6CC88F8-D289-4AA7-8F75-519EEEEFC9CD@amazon.com>
Content-Language: en-US
From: John Kemp <stable.pseudonym@gmail.com>
In-Reply-To: <A6CC88F8-D289-4AA7-8F75-519EEEEFC9CD@amazon.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: WTDTICTIKV3CEXEVLVJC5KD3VAGTQU4E
X-Message-ID-Hash: WTDTICTIKV3CEXEVLVJC5KD3VAGTQU4E
X-MailFrom: stable.pseudonym@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Wimse] Re: Token Exchange design team update
List-Id: WIMSE Workload Identity in Multi-Service Environment <wimse.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/wimse/Y2EXaJzCejeiIvkG3tYdbS2Qumw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/wimse>
List-Help: <mailto:wimse-request@ietf.org?subject=help>
List-Owner: <mailto:wimse-owner@ietf.org>
List-Post: <mailto:wimse@ietf.org>
List-Subscribe: <mailto:wimse-join@ietf.org>
List-Unsubscribe: <mailto:wimse-leave@ietf.org>

On 6/13/24 14:02, Saxe, Dean wrote:
> Second, we have come to the conclusion that token exchange has a 
> distinct meaning due to the use of the term in RFC 8693 
> <https://datatracker.ietf.org/doc/html/rfc8693>. Recognizing that WIMSE 
> is broader than OAuth 2.0 and that there may be exchanges that are lossy 
> between different token types, we have embraced the idea of “token 
> translation” as a term to express that there may be information “lost in 
> translation” in such exchanges.  Where WIMSE can use the existing 
> mechanisms in RFC 8693, we will continue to refer to that as “token 
> exchange”.  In my opinion, token translation is a superset which 
> includes the existing OAuth Token Exchange protocol.  I look forward to 
> broader discussion on this idea with the WIMSE WG.

Just an attempt to understand this concretely, I thought I'd use the 
SPIRE-OIDC-AWSIAM example from the docs:

1. A SPIRE SVID JWT is issued to the workload at some point prior to the 
use of AWS S3, just via the normal SPIRE mechanisms.

2. Once OIDC discovery + IdP in AWS is setup, via OIDC discovery, the 
SPIRE OIDC provider provides an OpenID Connect ID Token to the AWS IdP, 
representing the workload, with the SVID url as its 'sub'. So this has 
been an actual token exchange (of a kind) from one format of JWT to 
another (let's forget there's probably barely any translation needed there).

3. Once the token has been obtained by the client, it can be used to go 
to S3, along with the request to 'assume role' based on that token.

4. The JWT is "translated" (and I think translation sounds more accurate 
than "exchange" here) to an IAM role (which concretely means AWS 
"temporary credentials" - but the client application never sees those 
effectively, so there is no "exchange" as such.

So the overall protocol requires both an actual token exchange (not 
mediated by the client) and a translation.

Did I get that right (in which case, I agree with "translation" being 
needed?)

Cheers, - johnk