[Wimse] Re: Token Exchange and Translation Protocol

Dean Saxe <dean.saxe@beyondidentity.com> Fri, 09 August 2024 04:05 UTC

Return-Path: <dean.saxe@beyondidentity.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 3A8A4C169433 for <wimse@ietfa.amsl.com>; Thu, 8 Aug 2024 21:05:31 -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, 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_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=beyondidentity.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 HabKAAYJS7Tl for <wimse@ietfa.amsl.com>; Thu, 8 Aug 2024 21:05:27 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 D8DDBC14F705 for <wimse@ietf.org>; Thu, 8 Aug 2024 21:05:26 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2f15dd0b489so20546911fa.3 for <wimse@ietf.org>; Thu, 08 Aug 2024 21:05:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beyondidentity.com; s=google-bid; t=1723176325; x=1723781125; 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=HZrFt7wyO48hEJAGqn9uIH95qYS3Ugvk7MNL4fCWP/I=; b=c/fGtN7vsQmgdj4R2V4MLNRwF9SeoXwJlcxsOvT7/R2jvrpmyXrdP+swjsyIVotoob ZFJveOr7lDSzytCqNkKSdJD1id55xExZ0C7B5R7hwFNJS9Cxhg2Vf+tP/TWp5gWN7v4c RnB+iiZ0PJhbq07l5glZMAHlPhUfVsfz6aXGZyTGzA6D/kyzp3kktXXsdsSpICimnM6+ JjAkkd7sQyLz+uTkVH3ZBmeJs/sHepnCPoDTr36o14PiE0WKcwds5yJm5JeDAgoO0SUd eG1NXOnvcwfadWwyANc4zlHHiyKOxBGlMXGu2AMUTBvbLPoj5eb1kjK0h0KBGSegefiw 1Yog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723176325; x=1723781125; 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=HZrFt7wyO48hEJAGqn9uIH95qYS3Ugvk7MNL4fCWP/I=; b=kBEGmDKYXT1q7ZNxGW6SplsEao8r6Mv1YukrdkfHBQdJVrSehOZII7UA4KyTpho4Ey 05U86+x0anr1Xrf1MvRbfcXAbe9qB03MB/42OA27Y8rXbCznRAHiw/3MrDSRe+p3C4Y2 wJxvctPuSCxVnC+hRcM4RUL+XuKQJFVuhW+mnOhXL40z+v22Q6IyN5FW5HrftozgVe8W 8efSJv21Ed4ZIKyVtxuG6pV2kMCzC82Qt7s0ETKg9MU+aIo30GXfoypPC3cF/kiDydQH LuAWFfO1AeLqn4yFJ4H7/E6959QkeJ9z497kdxpevrEu9aYRW4h2BOHoPLfUkrzUFYS/ cH/A==
X-Forwarded-Encrypted: i=1; AJvYcCVzkGOn0PFCu8zVU3FYErcp4FBjL8stkS5koAbTku3gASuiTOcExy8qtRktqUwLHif83sOuSi5iDTmazPf2bg==
X-Gm-Message-State: AOJu0YzyASWqaCemGho9ATXD/iL1bgqj6q4EWJWqGsBV1Is1aeSie8Qc Bq5wS/8vtdp4Y859j5D5DWbmIiVee8sIC8+VGZ4uRAPYydaVyrbuobzK/QfoAkJHUS1tjrH/zqT xBCkt5Gf/VKK+o7SGlnBNj2voOB8b+AE5vPQLrQ==
X-Google-Smtp-Source: AGHT+IG7fph5OsRutXQZP+Uyw5WpzufHo2GDCz4MkpAtVvdEylNo1MuAFy/9tCYjUDfxEIlG5QdCDtyS6glohmFTFYY=
X-Received: by 2002:a2e:4a11:0:b0:2f1:a509:ce7b with SMTP id 38308e7fff4ca-2f1a6d0c1admr2017891fa.11.1723176324224; Thu, 08 Aug 2024 21:05:24 -0700 (PDT)
Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Aug 2024 06:05:23 +0200
Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Aug 2024 06:05:20 +0200
MIME-Version: 1.0 (Mimestream 1.3.7)
References: <17054C45-D280-4F6D-92FA-69780E697C69@mit.edu> <a48794ca-6c54-4643-990b-88a06bd08c9b@cisco.com> <CALH0CC19PEpPZvEE=JNW4y-Y8Ew5tbMLtGKq9-qVcrECtD8RCA@mail.gmail.com> <970c8541-ce9d-4869-9397-a648734ed72b@cisco.com> <CAOgPGoCT7x0hdyYdfxS21TepMn482rNdc_Xj7s8jBzVP6gitZw@mail.gmail.com>
In-Reply-To: <CAOgPGoCT7x0hdyYdfxS21TepMn482rNdc_Xj7s8jBzVP6gitZw@mail.gmail.com>
From: Dean Saxe <dean.saxe@beyondidentity.com>
Date: Fri, 09 Aug 2024 06:05:23 +0200
Message-ID: <CALH0CC11tGSu=RE7qB2FjSUbUiUV4fW01J+ZdGKRmM4FA1S68g@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Content-Type: multipart/alternative; boundary="000000000000b0f5c0061f38401d"
Message-ID-Hash: 4NE3BFLVAC3LES3EQ4YDGA5U4BW7AOYE
X-Message-ID-Hash: 4NE3BFLVAC3LES3EQ4YDGA5U4BW7AOYE
X-MailFrom: dean.saxe@beyondidentity.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
CC: Justin Richer <jricher@mit.edu>, "wimse@ietf.org" <wimse@ietf.org>, Brian Campbell <bcampbell@pingidentity.com>, "Flemming Andreasen (fandreas)" <fandreas@cisco.com>
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/F4FPV0pNY1jdAkYEE7EgPhM8ouc>
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>

Thanks for the feedback, Joe.  I think these are fair requests.

-dhs
--
Dean H. Saxe, CIDPRO <https://idpro.org/cidpro/>
Principal Engineer, Office of the CTO
Beyond Identity
dean.saxe@beyondidentity.com




On Aug 8, 2024 at 3:11:15 PM, Joseph Salowey <joe@salowey.net> wrote:

> I support A - continue to work on this document to develop it for working
> group adoption.  While the document needs a fair amount of work, I don't
> see anything that really hinders it from becoming something that we could
> adopt.
> What I would like to see in this document:
> 1. I would like to see the more concrete use cases and examples fleshed
> out more.  Maybe not all of them need to go into the document, but I think
> we will need these going forward.
> 2. Do we think that all the use cases will need to use a new token
> translation endpoint?  I'm not sure, but I really would like to understand
> the functionality and characteristics of the new endpoint.  Also it seems
> token exchange would work for some of the use cases, would the use of
> existing token exchange procedures be described in this document as well?
> 3. I like that there already are some security considerations in the
> document, but I'd like to see a bit more fleshed out before adoption, but
> it does not need to be exhaustive at this point.
>
> Thanks,
>
> Joe
>
>
> On Wed, Jul 31, 2024 at 2:04 PM Flemming Andreasen (fandreas) <fandreas=
> 40cisco.com@dmarc.ietf.org> wrote:
>
>> Hi Dean
>>
>> I think we are largely on the same page here. Wrt. the use cases I-D, I
>> assume you are referring to
>> https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.html ?
>> If so, that draft expired in February, and I'm not clear on what the intent
>> of it is going forward. Regardless, when you look at the use cases
>> described in there, I don't see anything specifically talking about token
>> exchange/translation. I think I generally understand the notion of token
>> exchange based on RFC 8693, however I'm less clear on token translation as
>> defined in the draft. The AWS-to-SPIFFE scenario described in the draft
>> makes sense, and I am asking for more such examples to help guide the
>> specific translations we shold be focusing on (profiles). From a
>> documentation point of view, I like the more descriptive style of some of
>> the use cases, but I also recognize the value of the user story approach
>> taken in the use-cases draft above - a combination of the two would be
>> ideal from my point of view.
>>
>> Cheers
>>
>> -- Flemming
>>
>>
>> On 7/31/24 14:47, Dean Saxe wrote:
>>
>> Flemming,
>>
>> Thank you again for the feedback.
>>
>>
>> For IETF 120 the most important output (IMHO) was to frame up the problem
>> space and an approach to solving for the use cases we identified.  The doc
>> is rough and at a high level because we really needed feedback to inform
>> the next steps - are we approaching this problem from the right
>> perspective?  Are we missing something in the existing RFCs?
>>
>> I agree that there’s more work to be done on the use cases draft to
>> inform this document.
>>
>> Additional commentary/questions inline below.
>>
>> -dhs
>> --
>> Dean H. Saxe, CIDPRO <https://idpro.org/cidpro/>
>> Principal Engineer, Office of the CTO
>> Beyond Identity
>> dean.saxe@beyondidentity.com
>>
>>
>>
>>
>> On Jul 30, 2024 at 6:16:23 PM, Flemming Andreasen (fandreas) <fandreas=
>> 40cisco.com@dmarc.ietf.org> wrote:
>>
>>> We have a charter item corresponding to this document and I don't see
>>> any other candidate documents at this time, so I vote for A.
>>>
>>> The document is pretty rough though and mostly introduces some of the
>>> problems to consider. Additionally, the document would benefit from the
>>> following:
>>> - More work on the requirements to feed into this document (per separate
>>> e-mail thread on requirements)
>>> - A set of representative use case scenarios to illustrate what we are
>>> after. This is especially important for the "token translation" scenarios.
>>>
>>
>> How is this different from the use cases described in the use cases I-D?
>> Are these more concrete examples or something entirely different?
>>
>> - Clarity on whether we aim to use (/profile) RFC 8693 for "token
>>> translation" or whether that is only for "token exchange"
>>>
>>
>> I have an action item to follow up with Brian Campbell on this as
>> discussed in the WG last week.
>>
>>
>> - Clarity on which token formats we want to be able to
>>> translate/exchange. While the document notes that these will be provided as
>>> "translation profiles", we shold understand the target ones early on, and
>>> develop at least some of them in parallel with the basic
>>> translation/exchange protocol.
>>>
>>
>> I am supportive of developing the profiles side-by-side with this ID.  I
>> thought I had said that in the meeting, but if I did not, that was my
>> intent.  My thought process was to enable profiles to be developed on a
>> separate track to allow the WG to deliver RFC candidates more quickly
>> without allowing one profile to bog down the work on the larger token
>> translation doc.
>>
>> If you have suggested token translations to focus on in the near term,
>> please let me know.
>>
>>
>>
>>> Cheers
>>>
>>> -- Flemming
>>>
>>>
>>> On 7/29/24 08:25, Justin Richer 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
>>>
>>
>> --
>> Wimse mailing list -- wimse@ietf.org
>> To unsubscribe send an email to wimse-leave@ietf.org
>>
>