[Wimse] Re: Token Exchange and Translation Protocol

Warren Parad <wparad@rhosys.ch> Mon, 29 July 2024 14:24 UTC

Return-Path: <wparad@rhosys.ch>
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 03080C180B42 for <wimse@ietfa.amsl.com>; Mon, 29 Jul 2024 07:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=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_BLOCKED=0.001, 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=rhosys.ch
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 7d_5ZuFVJyb9 for <wimse@ietfa.amsl.com>; Mon, 29 Jul 2024 07:24:33 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22B7C16943D for <wimse@ietf.org>; Mon, 29 Jul 2024 07:24:33 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a7a94fc107dso42617966b.0 for <wimse@ietf.org>; Mon, 29 Jul 2024 07:24:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google2024; t=1722263072; x=1722867872; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rNfVPhfjowPipBwcNa9EwMAzBhxCVpKPivmbiXNDKqQ=; b=MUX3mQF8Wj8SV4GchacWmxNDOK93JfhQuVzL9qoL43uRRHmlzrttrMMw7R+sa8DmGo 78JC7HSEXhJoq+KoJHTMePtXeYeBnWw/+aoEJrnjNmyk3qMofuqRXGTHyJg0/HifK7kL /0uwj5oJD7qq8eRtvFLG64JVyRT87v3HWdXqDk9tAUKTcDoBQbai9CJX0fLagcsxlQkQ P6AI4UVBtJ7eMwuaqT9uA91h9hg5Asz64ZLZDeaAIDwrTYlhSMAFYKXo1zIVye4dZmPR W4LmzQJW02QpXxrAwbGXHtI1vRx+4NmDQKX7qzMHZMI/PTgyObZyMQ9TdjzxrC1x9eqG lCkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722263072; x=1722867872; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rNfVPhfjowPipBwcNa9EwMAzBhxCVpKPivmbiXNDKqQ=; b=MAWIVGQFWUL804h+aSt0L31mnwMdDtGubF9hubT0Kp8oSVCRUWnsbs7TA71pEO1Dg8 EH6kJ1/jkJCPAs1yY7Bi7ms/xM5i9KRzPAqv+7zCy0JNR1wjfIu0HV0g5PWFzQJqAeXj O8BWWWzHSX169I3h2ySHkL2KlcK4yMeZmgTgfhneynWDd0zZEw+i3AIyz5sgaMF5/T6C DTDjlqKU6/oVHJFi0Ic+5N6AyyZZIVOZTOMRPJpxUnfemQ6b55QXG6L9ocIPHuIB+1ML frfjMQ4Pay6V109IWTul3RTOQGxlWEaECttwnlCctJ+ItQ7YfC/VSmgWQngSePj3+CG4 eWDA==
X-Gm-Message-State: AOJu0YyamzJsWDCGiWQn8r3cAZNA5Szh5+JlB72Mi5En+VkLnqgP6t+6 NKI8YLgQkf9lAEic0R9GheiR5Cw0UUEQP1wxieprz0/4kMLqFDcoV9DA/+Ml/4w31zr7i6WniiS OwuS+2RMEivB79dGao9OnVZBl9Io8GTAUqVQzA8afHdqSIsVq7bNkW0XmfQ==
X-Google-Smtp-Source: AGHT+IGiYo1t62uWKoABr/QZ//8mWHIEMH8I2dXWMxq+uexsPjZx4oNWM2DuPMaZpdofxSGDUxGufULXdERuna/iv00=
X-Received: by 2002:a17:907:7f24:b0:a7a:8c2b:3ac1 with SMTP id a640c23a62f3a-a7ac5b19d06mr629017966b.6.1722263071493; Mon, 29 Jul 2024 07:24:31 -0700 (PDT)
MIME-Version: 1.0
References: <17054C45-D280-4F6D-92FA-69780E697C69@mit.edu>
In-Reply-To: <17054C45-D280-4F6D-92FA-69780E697C69@mit.edu>
From: Warren Parad <wparad@rhosys.ch>
Date: Mon, 29 Jul 2024 16:24:20 +0200
Message-ID: <CAJot-L10pD0ayawWmpL5VWBuiU76YnZQ3F1dFgK2eG0PHcFMpQ@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000962b51061e639ea9"
Message-ID-Hash: 67WKCJFLNG2ZFGQRSVHNDTPTRMKOEZ7W
X-Message-ID-Hash: 67WKCJFLNG2ZFGQRSVHNDTPTRMKOEZ7W
X-MailFrom: wparad@rhosys.ch
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
CC: "wimse@ietf.org" <wimse@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Wimse] Re: Token Exchange and Translation Protocol
List-Id: WIMSE Workload Identity in Multi-Service Environment <wimse.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/wimse/UrrhzgLbaVWgwabbQeLQIxCQ_Zk>
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>

C, I don't understand what having the ratified RFC would achieve. I believe
I understand the challenges identified by the draft, but I don't know what
having a finished version actually looks like. How does having this
document affect future work? It doesn't look like a standard to me, what
are we standardizing on here?

So my answer is C, because it is not in a state that can be decided whether
or not to be adopted because it doesn't actually propose a solution, that I
can see.

The one thought I have is that maybe it is saying "We need a generic
version of RFC8693", is that accurate?

If that's the case, maybe I would ask, is that actually possible? Is the
goal to create an abstraction and let future RFCs define exactly how to
consume the endpoint and create a new profile utilizing this RFC and the
requirements by each of the before/after specs? Or is it the goal that all
future specifications for token formats could always utilize this document
to exchange tokens with any other format without explicitly specifying how
that works anywhere?


- Warren

On Mon, Jul 29, 2024 at 4:03 PM Justin Richer <jricher@mit.edu> wrote:

> Following discussion in Vancouver, the chairs would like to begin
> discussion on what the next steps should be for the Token Exchange and
> Translation Protocol document [1], an output of the Token Exchange Design
> Team. This is not a call for adoption as there was a clear indication in
> the room that the document was not yet ready for this stage.
>
> Please reply to the list to indicate that:
>
> A: You believe this document should be developed into a state that the WG
> can adopt it. (Please discuss what you believe would be required changes
> for this. Please keep in mind that a call for adoption is a starting point
> for a document, not a finished document.)
>
> B: You believe this document should NOT be developed further by the WG.
> (Please indicate why if possible)
>
> C: You need more information before making this decision. (Please indicate
> what information you’d need)
>
> D: You don’t give a flying rat about this document (i.e., this is not a
> topic you care strongly about)
>
>
> Please reply to the list by August 12th, 2024.
>
> — Justin and Pieter
>
> [1]
> https://datatracker.ietf.org/doc/draft-saxe-wimse-token-exchange-and-translation/
>
>
> --
> Wimse mailing list -- wimse@ietf.org
> To unsubscribe send an email to wimse-leave@ietf.org
>