Return-Path: 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 2F093C14F736 for ; Thu, 8 Aug 2024 15:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=salowey-net.20230601.gappssmtp.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 KjDpsA7e23a8 for ; Thu, 8 Aug 2024 15:11:30 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 D4333C14F6A1 for ; Thu, 8 Aug 2024 15:11:29 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2ef248ab2aeso21838651fa.0 for ; Thu, 08 Aug 2024 15:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20230601.gappssmtp.com; s=20230601; t=1723155088; x=1723759888; 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=/BAr544BKBZJKi9FwOxHeI9pO+2Bn5qEDqbNEpz8Uv4=; b=qcNz2AIStijtH1b8lhUIDX5bGsqupL+D+taOqA0Qp1LJ5I2/1MWMiFcUmNWt8e4yIJ 7OkcFLejgPh3TlDm/8ScA31h2ekX75zCr4z84NaSOGflqso40WQXQ8oQWn2P+mQEGYaE 4wuXz9umhZ0NpsmyFPqdirXuDPKWDrXWmUVUFVwe2uA1musDfjrO9rJOseqw3NBqLNNM GP4zqHceuVHLTjhhp2pdrIvHwYsd6UmgsmHqNA5M/euXm/nrH+mXhw6C316u2K4CNNif +2T1Ng6M5WUqmbIBGS5EgxdbhZmMJtQkicaAiym+l9Rj0SwWOhJcoIbobsRLxuIPvU1L wT3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723155088; x=1723759888; 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=/BAr544BKBZJKi9FwOxHeI9pO+2Bn5qEDqbNEpz8Uv4=; b=Xss0Huf8O21Gk9cG6OA2A/3UFFFxWLQa1TWr8qGZ9BlCPu3g5JIV9H1F94rPQGgAAL IUqFlYTt+7w05GZznbsXlAwPl51Yb8W9H5LQQaNMTPylU9pPIXlOcEcBIza23dg0sbq2 YMZNyodsKo5khbAa1AXv3rqC28T/zDyYHRF9bY1DqkS3yFW+OyrBViD7b4SGQq3QM9vh fQwavApR6eX5lXzMTHu/l5l+tQy0IFqOGGx/cj6+FpeUXUnZv6x1QpKrtVvemsmU6H97 jA1m+Q7OxBhMFq5HElfpNUaUsdGhcbNH8b1i+vzypiH0AT1vmkIfUBCaVN7YeYPlIhJZ hxWQ== X-Forwarded-Encrypted: i=1; AJvYcCX+f0bLd9BAWIdY9ZXCUumYC9S3m9Y31YKPOxiJHa3tBwsK+meoie+ph4UhuD7O/pPRGNIYwE2ahUXt5sFfHQ== X-Gm-Message-State: AOJu0YxWLv/23ku7gEexPLtJWwgEqFjXUBebbgacjwoyXOmc1V3/s7Z4 EhHEC/WxoI3nFcgr40hpn0DSdpMbj2rcpdi8aR7+vxHmYp+xEeql/IRq9vKxEPG+ta1zyNFhjk6 /N2kRh0bFqEvZWSvJZCIHqZ5Cvzm3RwYz/U5b5A== X-Google-Smtp-Source: AGHT+IF8iSTTGf0+/20ZgvNMKBJEAycdaEOy9FeKFUdktm+BUwc8t4TTclphWH940DAnjwzpYuW2sPVLj1te1a3yK8Q= X-Received: by 2002:a2e:9906:0:b0:2ef:2c86:4d49 with SMTP id 38308e7fff4ca-2f19de394cdmr25929521fa.22.1723155087648; Thu, 08 Aug 2024 15:11:27 -0700 (PDT) MIME-Version: 1.0 References: <17054C45-D280-4F6D-92FA-69780E697C69@mit.edu> <970c8541-ce9d-4869-9397-a648734ed72b@cisco.com> In-Reply-To: <970c8541-ce9d-4869-9397-a648734ed72b@cisco.com> From: Joseph Salowey Date: Thu, 8 Aug 2024 15:11:15 -0700 Message-ID: To: "Flemming Andreasen (fandreas)" Content-Type: multipart/alternative; boundary="000000000000e483de061f334e4f" Message-ID-Hash: KF2FGN2JAWOQ4VYRVNKD5VFCI6KWTRXF X-Message-ID-Hash: KF2FGN2JAWOQ4VYRVNKD5VFCI6KWTRXF X-MailFrom: joe@salowey.net 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: Dean Saxe , Justin Richer , "wimse@ietf.org" , Brian Campbell X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BWimse=5D_Re=3A_Token_Exchange_and_Translation_Protocol?= List-Id: WIMSE Workload Identity in Multi-Service Environment Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000e483de061f334e4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Flemming Andreasen (fandreas) 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 a= s > 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 do= c > 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=E2=80=99s more work to be done on the use cases draft = to inform > this document. > > Additional commentary/questions inline below. > > -dhs > -- > Dean H. Saxe, CIDPRO > Principal Engineer, Office of the CTO > Beyond Identity > dean.saxe@beyondidentity.com > > > > > On Jul 30, 2024 at 6:16:23=E2=80=AFPM, Flemming Andreasen (fandreas) 40cisco.com@dmarc.ietf.org> wrote: > >> We have a charter item corresponding to this document and I don't see an= y >> 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" scenario= s. >> > > 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 Desig= n >> 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 W= G >> 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 poi= nt >> 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=E2=80=99d need) >> >> D: You don=E2=80=99t give a flying rat about this document (i.e., this i= s not a >> topic you care strongly about) >> >> >> Please reply to the list by August 12th, 2024. >> >> =E2=80=94 Justin and Pieter >> >> [1] >> https://datatracker.ietf.org/doc/draft-saxe-wimse-token-exchange-and-tra= nslation/ >> >> >> >> >> -- >> 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 > --000000000000e483de061f334e4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support A - continue to work on this document to de= velop it for working group adoption.=C2=A0 While the document needs a fair = amount of work, I don't see anything that really hinders it from becomi= ng something that we could adopt.=C2=A0=C2=A0
What I would like t= o see in this document:
1. I would like to see the more concrete = use cases and examples fleshed out more.=C2=A0 Maybe not all of them need t= o go into the document, but I think we will need these going forward.=C2=A0= =C2=A0
2. Do we think that all the use cases will need to use a n= ew token translation endpoint?=C2=A0 I'm not sure, but I really would l= ike to understand the functionality and characteristics=C2=A0of the new end= point.=C2=A0 Also it seems token exchange would work for some of the use ca= ses, would the use of existing=C2=A0token exchange procedures be described = in this document as well?
3. I like that there already are some s= ecurity 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.=C2=A0

Thanks,

Joe<= /div>
=C2=A0=C2=A0

On Wed, Jul 31, 2024 at 2:04=E2=80=AFPM Flemming Andr= easen (fandreas) <fandreas=3D40cisco.com@dmarc.ietf.org> wrote:
Hi Dean

I think we are largely on the same page here. Wrt. the use cases I-D, I ass= ume 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 in= tent of it is going forward. Regardless, when you look at the use cases des= cribed 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 t= ranslations 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. =C2=A0


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 ident= ified.=C2=A0 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?=C2=A0 Are we missi= ng something in the existing RFCs?

I agree that there=E2=80=99s more work to be done on the u= se cases draft to inform this document. =C2=A0

Additional commentary/questions inline below.

-dhs
--
Dean H. Saxe, CIDPRO
Principal Engineer, Office of the CTO
Beyond Identity




On Jul 30, 2024 at 6:16:23=E2=80=AFPM= , Flemming Andreasen (fandreas) <fandreas=3D40cisco.com@dmarc.ietf.org> wrot= e:
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 probl= ems to consider. Additionally, the document would benefit from the followin= g:
- 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 afte= r. This is especially important for the "token translation" scena= rios.

How is this different from the use c= ases described in the use cases I-D?=C2=A0 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 w= ith Brian Campbell on this as discussed in the WG last week.


- Clarity on which token formats we want to be able to translate/excha= nge. While the document notes that these will be provided as "translat= ion profiles", we shold understand the target ones early on, and devel= op at least some of them in parallel with the basic translation/exchange protocol.

I am supportive of developing the pr= ofiles side-by-side with this ID.=C2=A0 I thought I had said that in the me= eting, but if I did not, that was my intent.=C2=A0 My thought process was t= o enable profiles to be developed on a separate track to allow the WG to deliver RFC candidates more quickly without allow= ing one profile to bog down the work on the larger token translation doc.

If you have suggested token translat= ions 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 disc= ussion on what the next steps should be for the Token Exchange and Translat= ion Protocol=C2=A0document [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 rea= dy for this stage.=C2=A0

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 change= s for this. Please keep in mind that a call for adoption is a starting poin= t 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 indi= cate what information you=E2=80=99d need)

D: You don=E2=80=99t 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.

=E2=80=94 Justin and Pieter





--
Wimse mailing list -- wimse@ietf.org
To unsubscribe send an email to wimse-leave@ietf.org

--
Wimse mailing list -- w= imse@ietf.org
To unsubscribe send an email to wimse-leave@ietf.org
--000000000000e483de061f334e4f--