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 CEA6CC14F69A for ; Fri, 16 Aug 2024 10:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.105 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, 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 Pf2OdlFlrYvh for ; Fri, 16 Aug 2024 10:42:51 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 8B83BC14F69D for ; Fri, 16 Aug 2024 10:42:46 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2ef27bfd15bso26244001fa.2 for ; Fri, 16 Aug 2024 10:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beyondidentity.com; s=google-bid; t=1723830164; x=1724434964; 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=8Bwoj/WZqEBzUgKt3TJfrscsvYanasNg75gHerZxw0M=; b=GFyv//klT+xS5s5qgisSuA+lfz45gqVNBOvUhtELLF0MnP7KgLFOrVqfUOdh9iDGLC Ul+fzHflHWt2oD/U/wlkN0XTlSGhnd8KAKqr4R/4rJ9OBfNFZunz2ztj5kpbPOHL242K 8C+vZuRsxb8vemg+93mdU8UT2wYJ2brL+yON1WHZMoZx59vst/Co2jpyvmstrF3PzMbk sUHr4lCCQU0jsMZdhYotHGnyJMzM+7GtBf/Xk6n4xymAe7ApWrkmXMjsL0smOlU1jo42 VI23+pVYetixNuZNK9ODZZaV51aKz81vpdlF1SRyjn032ZuFz6E0YHSyGC0Dm14DYloC i63g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723830164; x=1724434964; 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=8Bwoj/WZqEBzUgKt3TJfrscsvYanasNg75gHerZxw0M=; b=Tp6EXSN3DFz5+XMy/WNPK8F2g2pfCN4azV+jNjfrYP/sMpSoYGpA6YpzIHk74NZHps 9JecqG19AcZ9EHzXq6E1SCbEd117F4aZuSPJvPLs6i9bVu/qJzW7oRL8ogQlefxoglFR GG4etKQiYU7zmwHmjRqOQqgImXFgvsKSZ8HkVX9zvxAeImbKQao/6hz7JwcUY3QceNpc Lb9Bn5uUbbJigI3NjingKJo2nwuN5T8MzCmuIlhnfRfCakEm4chylhfLAaXbiA2ZqQXt Zr8fPzwiU0GEv8PYFTNaxGxIhjjUstIzWHmujH2ajhBi3LspfW+pQK+cXxz2EJ2vMDV3 pxJg== X-Forwarded-Encrypted: i=1; AJvYcCXucpzxVmweH/7o6tF4mGnDHfcjV1IT3kGK8/fQ2+G7r7VZrwauhu8ESX2TsWkose8TeNPooFo3f8bEryjP3A== X-Gm-Message-State: AOJu0YzJS31mcs9mySEh35wbM+EEHt5Z+r6wr+Dy9uzUPPWCz3tRdUtI VEBwmT4WXXfaDB8FTS03z+QBG61hi4CLKP91uFypq75eJOKpdWlgeDFSytLI6bobmcR5N/VIu56 49oJgxzcwNsmvnM2ypGxJCD5wbh/nE4JeIB8/rA== X-Google-Smtp-Source: AGHT+IFYXiAQhgSoXXlskTpXvi2o0JQltJZE+TdoMa+GFxKZV3gAZ0SzG8AICxR9bXwxvX2GfvSxgjFTez/SNHalFSE= X-Received: by 2002:a2e:b608:0:b0:2ef:2e59:11dc with SMTP id 38308e7fff4ca-2f3be597daemr27221201fa.25.1723830163435; Fri, 16 Aug 2024 10:42:43 -0700 (PDT) Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Fri, 16 Aug 2024 10:42:42 -0700 Received: from 1064022179695 named unknown by gmailapi.google.com with HTTPREST; Fri, 16 Aug 2024 13:42:39 -0400 MIME-Version: 1.0 (Mimestream 1.3.7) References: <17054C45-D280-4F6D-92FA-69780E697C69@mit.edu> <970c8541-ce9d-4869-9397-a648734ed72b@cisco.com> In-Reply-To: From: Dean Saxe Date: Fri, 16 Aug 2024 10:42:42 -0700 Message-ID: To: John Kemp Content-Type: multipart/alternative; boundary="0000000000008b94f2061fd07c90" Message-ID-Hash: 3YRTQ7SXPS323JSB7MLTN5MHILYTR3V4 X-Message-ID-Hash: 3YRTQ7SXPS323JSB7MLTN5MHILYTR3V4 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 , Joseph Salowey , "Flemming Andreasen (fandreas)" 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: --0000000000008b94f2061fd07c90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you all for the feedback. I=E2=80=99m about to start a week of well deserved time out of the office w= ith my family. Can I ask that those of you who have provided feedback on this doc and/or the use cases doc authored by Yaroslav place your feedback in issues and/or pull requests on the GitHub repos? https://github.com/yaroslavros/wimse-tokentranslation-requirements https://github.com/deansaxe/wimse-token-exchange-and-translation When I return from being OOO I will set up a time for a regular meeting to discuss these docs to see if we can make forward progress based on the feedback. Thank you, -dhs -- Dean H. Saxe, CIDPRO Principal Engineer Office of the CTO Beyond Identity dean.saxe@beyondidentity.com On Aug 12, 2024 at 1:33:02=E2=80=AFPM, John Kemp wrote: > I also support A, and related to Joe's comments below, I think we need > to develop a deeper understanding of what token "translation" means, > within the specific areas that Flemming pointed to in > https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.html and > also with particular regard to what is already in RFC8693. > > In my opinion, there are three overlapping concepts: > > 1. Token (initial) issuance -- in my mind, this token is issued in > response to a set of primary identity claims being validated enough to > "authenticate" the maker of those claims. In particular, token issuance > is part of the SSO dance in response to a (human) user authentication > event where the user is pretty explicitly delegating an application to > operate on the user's behalf. > > 2. Token exchange -- a token is offered to a "security token service" > and the token is a set of identity claims that are self-contained within > the token but can be authenticated cryptographically within the context > of that session. The original token is exchanged for a (one or more) new > token(s), which may have different semantics than that of the original. > > 3. Token translation -- a token is provided, and the original semantics > of that token are maintained in the production of a new token (or > something) usable in a different context. We could describe these > contexts as token translation "profiles". > > In the case of SPIFFE <-> "OAuth" we're pretty explicitly moving between > a world where the root of identity is non-human, to one where the root > of identity is (or started as) primarily human (and vice-versa). We may > or may not need to maintain the human context (authorization of a human > delegating to an application -- workload in/out of the context of a > logged-in SSO session). In particular, I am mindful of "as a SPIFFE user > with more than 10k workloads, I=E2=80=99d like to access OAuth protected > resources without having to manage 10k OAuth Clients" (from the > use-cases doc linked above). > > There are, of course, humans involved in workloads. The human that runs > an application which calls a workload to run some query across some > nodes, and authorizes it to run even while the human is logged out, say. > Or the sysadmin/devops human that bootstraps an orchestration framework > that offers nodes upon which workloads may run. > > Cheers, > > - johnk > > John Kemp > Independent Security Architect > e: stable.pseudonym@gmail.com > t: +1.413.645.4169 > > On 8/8/24 6:11 PM, Joseph Salowey 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=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 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 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=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/ > < > 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 > > >> > > > -- > > Wimse mailing list -- wimse@ietf.org > > To unsubscribe send an email to wimse-leave@ietf.org > > > > > > --0000000000008b94f2061fd07c90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you all for the feedback.

I=E2=80=99m about to start a week of well deserved time out of th= e office with my family.=C2=A0 Can I ask that those of you who have provide= d feedback on this doc and/or the use cases doc authored by Yaroslav place = your feedback in issues and/or pull requests on the GitHub repos?



When I r= eturn from being OOO I will set up a time for a regular meeting to discuss = these docs to see if we can make forward progress based on the feedback.

Thank you,

-dhs

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




On Aug 12, 2024 at 1:33:02=E2=80= =AFPM, John Kemp <stable.p= seudonym@gmail.com> wrote:
=20
I also support A, and related to Joe's comments below, I think we n= eed
to develop a deeper understanding of what token "translation&q= uot; means,
within the specific areas that Flemming pointed to in
<= a href=3D"https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.h= tml">https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.html and
also with particular regard to what is already in RFC8693.
In my opinion, there are three overlapping concepts:

1. Token (ini= tial) issuance -- in my mind, this token is issued in
response to a set= of primary identity claims being validated enough to
"authenticat= e" the maker of those claims. In particular, token issuance
is par= t of the SSO dance in response to a (human) user authentication
event w= here the user is pretty explicitly delegating an application to
operate= on the user's behalf.

2. Token exchange -- a token is offered t= o a "security token service"
and the token is a set of identi= ty claims that are self-contained within
the token but can be authentic= ated cryptographically within the context
of that session. The original= token is exchanged for a (one or more) new
token(s), which may have di= fferent semantics than that of the original.

3. Token translation --= a token is provided, and the original semantics
of that token are main= tained in the production of a new token (or
something) usable in a diff= erent context. We could describe these
contexts as token translation &q= uot;profiles".

In the case of SPIFFE <-> "OAuth"= ; we're pretty explicitly moving between
a world where the root of = identity is non-human, to one where the root
of identity is (or started= as) primarily human (and vice-versa). We may
or may not need to mainta= in the human context (authorization of a human
delegating to an applica= tion -- workload in/out of the context of a
logged-in SSO session). In = particular, I am mindful of "as a SPIFFE user
with more than 10k w= orkloads, I=E2=80=99d like to access OAuth protected
resources without = having to manage 10k OAuth Clients" (from the
use-cases doc linked= above).

There are, of course, humans involved in workloads. The hum= an that runs
an application which calls a workload to run some query ac= ross some
nodes, and authorizes it to run even while the human is logge= d out, say.
Or the sysadmin/devops human that bootstraps an orchestrati= on framework
that offers nodes upon which workloads may run.

Che= ers,

- johnk

John Kemp
Independent Security Architect
e= : stable.pseudonym@gmail.com<= /a>
t: +1.413.645.4169

On 8/8/24 6:11 PM, Joseph Salowey wrote:
I support A - continue to work on this documen= t to develop it for
working gro= up adoption.=C2=A0 While the document needs a fair amount of work,
I don't see anything that really hi= nders it from becoming something that
we could adopt.
What I wo= uld like to see in this document:
1. I would like to see the more concrete use cases and examples fleshed <= br>
out more.=C2=A0 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= ?=C2=A0 I'm not sure, but I really would like to
understand the functionality and characteristics=C2= =A0of the new endpoint. =C2=A0
A= lso it seems token exchange would work for some of the use cases, would
the use of existing=C2=A0token exc= hange procedures be described in this
document as well?
3. I li= ke that there already are some security considerations in the
document, but I'd like to see a bit more= fleshed out before adoption,
b= ut 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)
<fandr= eas=3D40cisco.com@dmarc.ietf.= org
<mailto:40cisco.com@dmarc.ietf.org>> wr= ote:

=C2=A0=C2=A0=C2=A0=C2=A0__
=C2=A0=C2=A0=C2=A0=C2=A0Hi Dean

=C2=A0=C2=A0=C2=A0= =C2=A0I think we are largely on the same page here. Wrt. the use cases
<= /blockquote>
=C2=A0=C2=A0=C2=A0=C2=A0I-D, I assum= e you are referring to
=C2=A0=C2= =A0=C2=A0=C2=A0https://www.ietf.org/archive/id/draft-gilman-wimse-use= -cases-00.html
=C2=A0=C2=A0= =C2=A0=C2=A0<https://www.ietf.org/archive/id/draft-gilman-wimse-us= e-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 specifi= cally talking about token exchange/translation. I think I generally underst= and the notion of token exchange based on RFC 8693, however I'm less cl= ear on token translation as defined in the draft. The AWS-to-SPIFFE scenari= o described in the draft makes sense, and I am asking for more such example= s 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 ap= proach taken in the use-cases draft above - a combination of the two would = be ideal from my point of view.
=
=C2=A0=C2=A0=C2=A0=C2=A0Cheers<= br>

=C2=A0=C2=A0=C2=A0=C2=A0-- Flemming


=C2=A0=C2=A0=C2=A0=C2=A0On 7/31/24 14:47, Dean= Saxe wrote:
> =C2=A0=C2=A0=C2= =A0=C2=A0Flemming,
>
> =C2=A0=C2=A0=C2=A0=C2=A0Thank you aga= in for the feedback.
>
>
> =C2=A0=C2=A0=C2=A0=C2=A0For IETF 120 the most important output = (IMHO) was to frame up the
> = =C2=A0=C2=A0=C2=A0=C2=A0problem space and an approach to solving for the us= e cases we
> =C2=A0=C2=A0=C2= =A0=C2=A0identified.=C2=A0 The doc is rough and at a high level because we<= br>
> =C2=A0=C2=A0=C2=A0=C2=A0real= ly needed feedback to inform the next steps - are we
> =C2=A0=C2=A0=C2=A0=C2=A0approaching this problem f= rom the right perspective?=C2=A0 Are we
> =C2=A0=C2=A0=C2=A0=C2=A0missing something in the existing RFCs?=
>
> =C2=A0=C2=A0=C2=A0=C2=A0I agree that there=E2=80=99s mo= re work to be done on the use cases draft
> =C2=A0=C2=A0=C2=A0=C2=A0to inform this document.
>
> =C2=A0=C2=A0=C2=A0=C2=A0Additional commentary/questions inline belo= w.
>
> =C2=A0=C2=A0=C2=A0=C2=A0-dhs
> =C2=A0=C2=A0=C2=A0=C2=A0--
> =C2=A0=C2=A0=C2=A0=C2=A0Dean H. Saxe, CIDPRO <https://idpro.org/cidpro/>
> =C2=A0=C2=A0=C2=A0=C2=A0Principal E= ngineer, Office of the CTO
> = =C2=A0=C2=A0=C2=A0=C2=A0Beyond Identity
> =C2=A0=C2=A0=C2=A0=C2=A0dean.saxe@beyondidentity.com <mailto:dean.saxe@beyondidentity.com>
>
>
>
>
> = =C2=A0=C2=A0=C2=A0=C2=A0On Jul 30, 2024 at 6:16:23=E2=80=AFPM, Flemming And= reasen (fandreas)
> =C2=A0=C2= =A0=C2=A0=C2=A0<fandreas=3D40cisco.com@dmarc.ietf.org
&= gt; =C2=A0=C2=A0=C2=A0=C2=A0<mailto:40cisco.com@dmarc.ietf.org>> wrote:
>> =C2=A0=C2=A0=C2=A0=C2=A0We have a charter i= tem corresponding to this document and I don't
>> =C2=A0=C2=A0=C2=A0=C2=A0see any other candidate = documents at this time, so I vote for A.
>>
>> =C2= =A0=C2=A0=C2=A0=C2=A0The document is pretty rough though and mostly introdu= ces some of
>> =C2=A0=C2=A0= =C2=A0=C2=A0the problems to consider. Additionally, the document would
<= /blockquote>
>> =C2=A0=C2=A0=C2=A0=C2=A0bene= fit from the following:
>> = =C2=A0=C2=A0=C2=A0=C2=A0- More work on the requirements to feed into this d= ocument (per
>> =C2=A0=C2= =A0=C2=A0=C2=A0separate e-mail thread on requirements)
>> =C2=A0=C2=A0=C2=A0=C2=A0- A set of represent= ative use case scenarios to illustrate what
>> =C2=A0=C2=A0=C2=A0=C2=A0we are after. This is especiall= y important for the "token
&= gt;> =C2=A0=C2=A0=C2=A0=C2=A0translation" scenarios.
>
= > =C2=A0=C2=A0=C2=A0=C2=A0How is this different from the use cases descr= ibed in the use
> =C2=A0=C2=A0= =C2=A0=C2=A0cases I-D?=C2=A0 Are these more concrete examples or something = entirely
> =C2=A0=C2=A0=C2=A0= =C2=A0different?
>
>> =C2=A0=C2=A0=C2=A0=C2=A0- Clarity o= n whether we aim to use (/profile) RFC 8693 for "token
>> =C2=A0=C2=A0=C2=A0=C2=A0translation&quo= t; or whether that is only for "token exchange"
<= blockquote type=3D"cite">>
>= ; =C2=A0=C2=A0=C2=A0=C2=A0I have an action item to follow up with Brian Cam= pbell on this as
> =C2=A0=C2= =A0=C2=A0=C2=A0discussed in the WG last week.
>
>
>> =C2=A0=C2=A0=C2=A0=C2=A0- Clarity = on which token formats we want to be able to
>> =C2=A0=C2=A0=C2=A0=C2=A0translate/exchange. While the = document notes that these will be
>> =C2=A0=C2=A0=C2=A0=C2=A0provided as "translation profiles&qu= ot;, we shold understand the
>= > =C2=A0=C2=A0=C2=A0=C2=A0target ones early on, and develop at least som= e of them in
>> =C2=A0=C2= =A0=C2=A0=C2=A0parallel with the basic translation/exchange protocol.
>
> =C2=A0=C2=A0=C2=A0=C2=A0I am supportive of developing the pr= ofiles side-by-side with this
>= ; =C2=A0=C2=A0=C2=A0=C2=A0ID.=C2=A0 I thought I had said that in the meetin= g, but if I did not,
> =C2=A0= =C2=A0=C2=A0=C2=A0that was my intent.=C2=A0 My thought process was to enabl= e profiles to
> =C2=A0=C2=A0= =C2=A0=C2=A0be developed on a separate track to allow the WG to deliver RFC=
> =C2=A0=C2=A0=C2=A0=C2=A0can= didates more quickly without allowing one profile to bog down
> =C2=A0=C2=A0=C2=A0=C2=A0the work on the l= arger token translation doc.
>=
> =C2=A0=C2=A0=C2=A0=C2=A0If = you have suggested token translations to focus on in the near
> =C2=A0=C2=A0=C2=A0=C2=A0term, please let = me know.
>
>
>&= gt;
>> =C2=A0=C2=A0=C2=A0= =C2=A0Cheers
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0-- Flemming=
>>
>>
>&= gt; =C2=A0=C2=A0=C2=A0=C2=A0On 7/29/24 08:25, Justin Richer wrote:
>>> =C2=A0=C2=A0=C2=A0=C2=A0Foll= owing discussion in Vancouver, the chairs would like to
>>> =C2=A0=C2=A0=C2=A0=C2=A0begin discussio= n on what the next steps should be for the Token
>>> =C2=A0=C2=A0=C2=A0=C2=A0Exchange and Translati= on Protocol=C2=A0document [1], an output of the
>>> =C2=A0=C2=A0=C2=A0=C2=A0Token Exchange Design T= eam. This is not a call for adoption as
>>> =C2=A0=C2=A0=C2=A0=C2=A0there was a clear indication in= the room that the document was
&= gt;>> =C2=A0=C2=A0=C2=A0=C2=A0not yet ready for this stage.
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0Please reply to the list = to indicate that:
>>>
>>> =C2=A0=C2=A0=C2=A0=C2= =A0A: You believe this document should be developed into a state
>>> =C2=A0=C2=A0=C2=A0=C2=A0that t= he WG can adopt it. (Please discuss what you believe would
=
>>> =C2=A0=C2=A0=C2=A0=C2=A0be required = changes for this. Please keep in mind that a call
>>> =C2=A0=C2=A0=C2=A0=C2=A0for adoption is a sta= rting point for a document, not a finished
>>> =C2=A0=C2=A0=C2=A0=C2=A0document.)
<= blockquote type=3D"cite">>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0B: You believe this document shou= ld NOT be developed further by
&g= t;>> =C2=A0=C2=A0=C2=A0=C2=A0the WG. (Please indicate why if possible= )
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0C: You need mo= re information before making this decision.
>>> =C2=A0=C2=A0=C2=A0=C2=A0(Please indicate what infor= mation you=E2=80=99d need)
>&g= t;>
>>> =C2=A0=C2=A0= =C2=A0=C2=A0D: You don=E2=80=99t give a flying rat about this document (i.e= ., this
>>> =C2=A0=C2=A0= =C2=A0=C2=A0is not a topic you care strongly about)
>>>
&= gt;>>
>>> =C2=A0= =C2=A0=C2=A0=C2=A0Please reply to the list by August 12th, 2024.
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0=E2=80=94 Justin and Piete= r
>>>
>>> =C2=A0=C2=A0=C2=A0=C2=A0[1]
>>> =C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-saxe-wimse-token-exchan= ge-and-translation/ <https://datatracker.ietf.org= /doc/draft-saxe-wimse-token-exchange-and-translation/>
>>>
>>>
>>&g= t;
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0--
<= blockquote type=3D"cite">>> =C2=A0=C2=A0=C2=A0=C2=A0Wimse mailing lis= t -- wimse@ietf.org <mailto:wimse@ietf.org>
>> =C2=A0=C2=A0=C2=A0=C2=A0To unsubscribe send an e= mail to wimse-leave@ietf.org
>> =C2=A0=C2=A0=C2=A0=C2=A0&l= t;mailto:wimse-leave@ietf.org&g= t;

=C2=A0=C2=A0=C2=A0=C2=A0--
=C2=A0=C2=A0=C2=A0=C2=A0Wimse mailing list -- wimse@ietf.org <mailto:wimse@ietf.org>
=C2= =A0=C2=A0=C2=A0=C2=A0To unsubscribe send an email to wimse-leave@ietf.org
=C2=A0=C2=A0=C2=A0=C2=A0<mailto:wimse-leave@ietf.org>


--0000000000008b94f2061fd07c90--