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 C5D74C14F61A for ; Wed, 31 Jul 2024 11:47: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_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=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 6qUjLHilxsIF for ; Wed, 31 Jul 2024 11:47:34 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 C1568C14F5FC for ; Wed, 31 Jul 2024 11:47:34 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2eeb1ba0468so94210421fa.0 for ; Wed, 31 Jul 2024 11:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beyondidentity.com; s=google-bid; t=1722451653; x=1723056453; 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=6Eag7yPWOqt4CXO3T4DquG8lMpxwtvTjGTJxdXfzYLs=; b=R1doptQC4IrUkzlXUw3lkmNdweazzlWYfoCK8mVJ1n+YN/md2D9RNE8Gze18mZ77PZ GLkeTWtdwS70P7y0T+3IbVRDqcxxxeKpzP37T/BAL9asLVERhfA+aB2r181c/nfrdGq8 a16bQfloUpXlD4n04PZ09UqaQ7YtHx5i4+3hDS1AfIBo8Apg6ObQ7TWlqD1rzkAGowd8 8Eu8m/NiFHg1DNVcDc3+mT9n4Hr5fedeDR008+1njJRGRRbA/58JYQr9bVaAF7gTkjuS o8R6MxSA6qw4fjRjBtm87PcMnvxSKUFf37ZH8KpQBoFkxx+uuzYTTWX0JZ9wyIHxyoyq jeMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722451653; x=1723056453; 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=6Eag7yPWOqt4CXO3T4DquG8lMpxwtvTjGTJxdXfzYLs=; b=Jvdw2+8BIj+jHc4lYX05l8x4kZPlT2VrM3uoE0M6bEwa/79h+ife0jc7lTXwsR8ogm y6lxzJHuRnimNvoPCYzLBuBoVlCFcX7JJT304OUVwXzyMsh3fjMf0wGTR+gfMROCklzr nps8F6bPKBZlnKa9SJWtpNVicS23M+slzR6F/EZd/redRorVSIk8Dq+BOiSYHTmtA6hl /D1UFsZRhzRg2kFzMOOG3M3tgL+mKHD68W41DMKi29fWdZKwDzTyIx7jM4AmraHSYlkV tWlQFxvfz84ylrBPJXz905rZDBowWMtqHja8vJJVvV4ityDrUV2LmhqzWcgHmCZ/AadU sJXg== X-Forwarded-Encrypted: i=1; AJvYcCXD1uHjsmL4QarojNFnX0qz0GE2LGIiUQClFmiErSVNMniZQIntQdJhqO2t5qP9pDXGJ5R8Fuifpo7qEWkIfA== X-Gm-Message-State: AOJu0YxyohxdtxsWxQbYf6wl/eGspPNQZZ2akc1c2ylCBJVeISojeNcx X59u2cDrKBJCbLkw8TuQFyN9iTKtc1lT4n1hH67yeZ4RfmiW9y5SQtBDVZjpAOqs77qSyR251/1 VjmzNU6A1jcYrDD1pL9bn3RE0Lo++HN/7lj4jDg== X-Google-Smtp-Source: AGHT+IF4NgkspDbAf2xaHpuhv0P++nnlHMON+9nf+i1nLqEOfZrHO7EH8S0cP8LhRqU/0weoQQtgbPlf5myUD7xFEDc= X-Received: by 2002:a2e:7010:0:b0:2ee:847f:9e9b with SMTP id 38308e7fff4ca-2f153104b33mr2224191fa.28.1722451652621; Wed, 31 Jul 2024 11:47:32 -0700 (PDT) Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Wed, 31 Jul 2024 18:47:32 +0000 Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Wed, 31 Jul 2024 18:47:29 +0000 MIME-Version: 1.0 (Mimestream 1.3.7) References: <17054C45-D280-4F6D-92FA-69780E697C69@mit.edu> In-Reply-To: From: Dean Saxe Date: Wed, 31 Jul 2024 18:47:32 +0000 Message-ID: To: "Flemming Andreasen (fandreas)" Content-Type: multipart/alternative; boundary="000000000000e5d7eb061e8f8683" Message-ID-Hash: KLHQ4YYDOBBTHA3IVRGM6QZFBUAQJR55 X-Message-ID-Hash: KLHQ4YYDOBBTHA3IVRGM6QZFBUAQJR55 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 , "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: --000000000000e5d7eb061e8f8683 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=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) 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 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 indicat= e > 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 > > [1] > https://datatracker.ietf.org/doc/draft-saxe-wimse-token-exchange-and-tran= slation/ > > > > > -- > Wimse mailing list -- wimse@ietf.org > To unsubscribe send an email to wimse-leave@ietf.org > --000000000000e5d7eb061e8f8683 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Flemming,

Thank you ag= ain 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 c= ases we identified.=C2=A0 The doc is rough and at a high level because we r= eally needed feedback to inform the next steps - are we approaching this pr= oblem from the right perspective?=C2=A0 Are we missing something in the exi= sting RFCs?

I agree that t= here=E2=80=99s more work to be done on the use cases draft to inform this d= ocument. =C2=A0

Additional= commentary/questions inline below.

-dhs
--
De= an 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> wrote:
=20
We have a charter item corresponding to this document and I don't see a= ny 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 cases= 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 tran= slation" or whether that is only for "token exchange"

I have an action item to follow up with Brian Campbe= ll 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 p= rofiles", 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 supporti= ve of developing the profiles side-by-side with this ID.=C2=A0 I thought I = had said that in the meeting, but if I did not, that was my intent.=C2=A0 M= y thought process was to enable profiles to be developed on a separate trac= k to allow the WG to deliver RFC candidates more quickly without allowing o= ne profile to bog down the work on the larger token translation doc.
<= div class=3D"gmail_quote" dir=3D"ltr">
If you have suggested token translations to focus on in the nea= r term, please let me know.


<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex" type=3D"cite">

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@ie= tf.org
To unsubscribe send an email to wimse-leave@ietf.org
--000000000000e5d7eb061e8f8683--