[Wimse] Re: Token Translation Requirements
Joseph Salowey <joe@salowey.net> Mon, 12 August 2024 02:57 UTC
Return-Path: <joe@salowey.net>
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 293CFC14CF0D for <wimse@ietfa.amsl.com>; Sun, 11 Aug 2024 19:57:00 -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=unavailable 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 WKl589Q52GpF for <wimse@ietfa.amsl.com>; Sun, 11 Aug 2024 19:56:55 -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 4FC12C14F6EA for <wimse@ietf.org>; Sun, 11 Aug 2024 19:56:55 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2ef2fbf1d14so46040031fa.1 for <wimse@ietf.org>; Sun, 11 Aug 2024 19:56:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20230601.gappssmtp.com; s=20230601; t=1723431413; x=1724036213; 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=Bt3I/QmOA6N/ebZ7/iW7WtwtHgyaKAlJ5RV47z9nF0M=; b=PJKaeOwfhZt1JbYXGhabSGFr27tRMFJSR/4qqrf9OUNp6jP+u1+4LICc0lc3KLKtrS t4c/XVuniZiNN+NxeYrRq+y08RpLlsSkuJOZhUAKmSWhYpKhENmfPXxUUB3q7+CoIJHP NN+aMuxN3AL8xg/EHQbkkdtyciAChZJrlbqEimZBv9//13W5yniZ5rmZek5bYmx2yBDK oh6KGxbqPXLaFUBAiOIg4RWv4wNLUS1ieJAI72iaI4Nbw7Cpewu7hdTdfig6bRX9fUJz 7jkYYWqRSydxTY1Mc7XqjsBGt5EXxyHJvFtg6RcNrwN8O2FDK1XOtYpzMFEF9DyFs7Ky JNzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723431413; x=1724036213; 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=Bt3I/QmOA6N/ebZ7/iW7WtwtHgyaKAlJ5RV47z9nF0M=; b=xS3mlVgbah3jp3+O0VcHG6cScnoBcdGeIX4qe6F5DAZpyRPeZXS5eHPd7q8PnwUavO 0/wS/ELcZpCcxARV7SdL9cSRpu0bY/tJdF3J25K9t5ij0ibbze+qe4M4JMMqgFVQ30TW KzYj7WUYvZQwyEuyeVpFvipN3W9FzsZJSf4m63mML6pbWgX1v1bbJoaMEj9gC3Zo2PWi fkP/HrqRlijXRpYCNL42++SiKtqem77iOLTcss/H0APvtqNT2F1sPgpGDP3zOFBN7wF7 G7pg8U0sY28YkTpVQ6c48UhzJvS43tXqqbmzr9yIasf4PUxJdvkIwphoF33Tdny/gzM5 S+Gg==
X-Forwarded-Encrypted: i=1; AJvYcCUw66i8nKEDZ+jWt7VcKQxNoSgR0G6L0retBroCsBJqoj/Sf6KcUf4k2wvCBfBBDI3vC8cHWIN6Qn2YpBzz4g==
X-Gm-Message-State: AOJu0YxcyN9Gsci2U6V7Ch5QG1AgM7AZJV/OWZ/3ebMsQB4hd0X+vgOU HcVE1c+80ZyrAugp0tiKd/gfOckG4nS2c+zTQw7EveR32m2ULaJvM2fYXVblTZ8UgcuZAtdCsWQ HXHptVFuBi3R2ZuoKgTK9BF9bDbEnSsm7bXgHqw==
X-Google-Smtp-Source: AGHT+IHkeRljPzeH3ErZoTQyHRWbUlfF9d38h9OK/SFRHt/KGBuon3Iw91HcBKNp1R5Zv74BglSltvWilcyfxRBOOP4=
X-Received: by 2002:a2e:811:0:b0:2f1:59b4:7bfd with SMTP id 38308e7fff4ca-2f1a7ab7d90mr17468361fa.25.1723431413048; Sun, 11 Aug 2024 19:56:53 -0700 (PDT)
MIME-Version: 1.0
References: <C9F484ED-DD76-41CB-8EBA-5A169BDB6D61@mit.edu> <7cec78e0-0f06-4fcf-97d4-86389fc80397@cisco.com> <CALH0CC3uH_V5Nbu4iQPKK-uOQLaqhemXVBZ2w6=RNmdqtsKiTg@mail.gmail.com> <CAOuZNLK9sx094fkNYH5Z_L7k7rxC0xEMNGroXRccD6UySbhsWA@mail.gmail.com>
In-Reply-To: <CAOuZNLK9sx094fkNYH5Z_L7k7rxC0xEMNGroXRccD6UySbhsWA@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
Date: Sun, 11 Aug 2024 19:56:41 -0700
Message-ID: <CAOgPGoBh_5kLnbNA0172UXyJ7RLTn9Ts_qGZmf1pt56WSYzNRw@mail.gmail.com>
To: Dmitry Izumskiy <idimaster@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000002b808d061f73a54e"
Message-ID-Hash: 64FF36ITU7Y42RUQK7RQ76MLM4QOBLTY
X-Message-ID-Hash: 64FF36ITU7Y42RUQK7RQ76MLM4QOBLTY
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 <dean.saxe=40beyondidentity.com@dmarc.ietf.org>, "Flemming Andreasen (fandreas)" <fandreas=40cisco.com@dmarc.ietf.org>, Justin Richer <jricher@mit.edu>, "wimse@ietf.org" <wimse@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Wimse] Re: Token Translation Requirements
List-Id: WIMSE Workload Identity in Multi-Service Environment <wimse.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/wimse/0UV1V4y4VSvcgeyA42X09AycB-o>
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>
I favor B. RIght now I think the best format would be an ID since that is easy to track in an IETF context, but I'm not opposed to other options as long as it's clear how we contribute to it and maintain it. Joe On Sun, Aug 11, 2024 at 12:53 PM Dmitry Izumskiy <idimaster@gmail.com> wrote: > Agree we Dean, > > After feedback from the working group and related conversation I think it > is B, information document not sure what is the right way to represent it > in IETF context. > > Two primary considerations: > - narrow (or add) profiles for specific protocol exchanges that may cover > 60-80% actively used by microservice environments. > a) JWT based exchanges between trust domains, something close to > Macaroons > <https://backstage.forgerock.com/docs/am/7/oauth2-guide/oauth2-macaroons.html#:~:text=Macaroons%20are%20a%20type%20of,resource%20servers%20without%20compromising%20security.> > > b) Hybrid environment API Gateway to Service Mesha and vise versa > (mTLS to JWT or as one example X.509-SVID > <https://github.com/spiffe/spiffe/blob/main/standards/X509-SVID.md> to > JWT-SVID > <https://github.com/spiffe/spiffe/blob/main/standards/JWT-SVID.md> ...) > - focus on security considerations for use cases when > translation missing/require some information and translation service need > to perform additional compensation action. > > Would like to get more feedback about what are the most problematic token > translation profiles. > > Best regards, > Dmitry > > > On Wed, Jul 31, 2024 at 11:36 AM Dean Saxe <dean.saxe= > 40beyondidentity.com@dmarc.ietf.org> wrote: > >> Thanks for the feedback, Flemming. After hearing the discussion about use >> cases in WIMSE and later in SPICE, I agree that this is unlikely to become >> a RFC, but there is good information in this draft to help us guide the >> work moving forward. >> >> Chairs, I’m at B on this doc - we need to continue developing the doc >> while recognizing it’s not destined to be an RFC. I’m supportive of this >> being an I-D and later being codified into a wiki or similar artifact. >> >> -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 2:28:09 PM, Flemming Andreasen (fandreas) <fandreas= >> 40cisco.com@dmarc.ietf.org> wrote: >> >>> My preference would be Option A, but as noted below, I do not see the >>> document becoming an RFC. >>> >>> A few considerations wrt. the current document that I would like to see >>> addressed going forward: >>> - The requirements are fairly high-level and generic in nature. It would >>> be helpful to focus on specific token formats we want to support and >>> requirements associated with those. >>> - Requirements around when and how token translation should be done. >>> - Requirements around how to deal with token translation with >>> information loss. >>> >>> I will note that some of the above is addressed in the corresponding >>> protocol document ( >>> https://www.ietf.org/archive/id/draft-saxe-wimse-token-exchange-and-translation-00.html) >>> but if we want to do requirements, then we should consider them in the >>> requirements document as well. >>> >>> Cheers >>> >>> -- Flemming >>> >>> >>> >>> On 7/29/24 08:26, Justin Richer wrote: >>> >>> Following discussion in Vancouver, the chairs would like to begin >>> discussion on what the next steps should be for the Token Translation >>> Requirements 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. >>> >>> As this is a requirements document, and it is unusual for a requirements >>> document to be codified as an RFC, the chairs would like the group to >>> discuss what the intended direction of this document should be. 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 be developed by the WG as something >>> other than a WG / RFC-track document. (Please discuss what you think the >>> right format or forum would be - a wiki page, a web page, an eternal I-D, a >>> blog post, etc) >>> >>> C: You believe this document should NOT be developed further by the WG. >>> (Please indicate why if possible) >>> >>> D: 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-rosomakho-wimse-tokentranslation-reqs/ >>> >>> >>> -- >>> 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 >> > -- > Wimse mailing list -- wimse@ietf.org > To unsubscribe send an email to wimse-leave@ietf.org >
- [Wimse] Re: Token Translation Requirements McAdams, Darin
- [Wimse] Token Translation Requirements Justin Richer
- [Wimse] Re: Token Translation Requirements Flemming Andreasen (fandreas)
- [Wimse] Re: Token Translation Requirements Dean Saxe
- [Wimse] Re: Token Translation Requirements Dmitry Izumskiy
- [Wimse] Re: Token Translation Requirements Joseph Salowey