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 61953C1DFD56 for ; Mon, 12 Aug 2024 20:28:39 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 N7Wrh_M59woz for ; Mon, 12 Aug 2024 20:28:38 -0700 (PDT) Received: from mail-il1-x141.google.com (mail-il1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (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 BA355C1DFD53 for ; Mon, 12 Aug 2024 20:28:33 -0700 (PDT) Received: by mail-il1-x141.google.com with SMTP id e9e14a558f8ab-39b3c36d247so20802385ab.3 for ; Mon, 12 Aug 2024 20:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723519713; x=1724124513; 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=68VKENLPxuNOdIZ0XotleLIy8vQfOZSUbfEGMR0WX9k=; b=cRFsqLdv1oqxRq6KABjsD9cJFADYOtw5q+qpePWNrHRG3BZriLq6r4snblqR5cuI6W Y1Jwlxz2PScyUdoMGQoLtWX7zXeYdkWuaiB9+pF8MgtxT8lrjLRUj3Ras9Fg2Sqvzqrt L728VIso9ZFX8gUxPZww4PwaIPLFkmrSMlXpGOFAq0g6V8zHiUVLh5jAIImTSl3khqc6 NabpbZJI0jL5B9nAEQJKJ44K5qnY7AITTyQYyypGXFiLbfCmboe/9pLELWNgS32Z1tt8 xd34qskIccSh7643JNSIPZU4UwxZE3rxMt8TJuxd9sFIT5SG10P1qHLpTjn/f9GKiHZK DhJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723519713; x=1724124513; 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=68VKENLPxuNOdIZ0XotleLIy8vQfOZSUbfEGMR0WX9k=; b=ko0+Yx9sGN34VGRw4wO+ky4wM8jSKrv+n0nI3vdhvdFwnVeWLwkbe2Fl2g92Irvacy kT4bc78OYzyGvJlkSf+x2yPBL5Zt8Gh0Pep4D46RJDcnzbLPuIsq4ClXS72ShCU+7zb6 dFh4ErQMPNEwIbmIfiHLpUGsiknsmIYOGBjOUAcGJ7w3OVZacQxnppYuZbnZYRJE8seO kBHW1dHpIILYWMJLbqm7qhH6TDOkeqd/oT/oGcf8Xw9FiLQTJ1nDLvg/fZskmJj7hJMo 0dLpxoxqK/DzonTAB7nnbXdU9lKeMF27ZW+pphtU/hiJE+GtwGCqJ1y4TJU8/g7UxF48 3ToQ== X-Forwarded-Encrypted: i=1; AJvYcCVbyagHbn4JDO48+6z6c5/gugFT4EohYm01yjuv9upPNFgvQ+s8+0y1BQb6p6J3QD2g8cSOYDJbWCCrXY7X9A== X-Gm-Message-State: AOJu0YzK7tcXhkG6lfbqV+3d5jP6v64VMdDp7wCsCzkta0R1gshqBltB o7KB8erQ2dnH4zE2+5oMEqFqpkGiR9l93L4kFZgmtJ4nDqBBKfmYA6sKrHEx4EhUlawamW95Wyv SrA79cw91WOtqby+VLitI/TFXKwo= X-Google-Smtp-Source: AGHT+IH59elSz+R+vk++F9UeHOBBIWId8zba9klbbIqhz43Iq4p1yKAhTy4FdsstofFyTNrD9X4eMMLgIzPXO6OkqOY= X-Received: by 2002:a05:6e02:2185:b0:39b:28d1:169b with SMTP id e9e14a558f8ab-39c4786413bmr26340145ab.15.1723519712426; Mon, 12 Aug 2024 20:28:32 -0700 (PDT) MIME-Version: 1.0 References: <9F066930-20F3-4273-8E2A-8D42B087E668@mit.edu> In-Reply-To: From: "A.J. Stein" Date: Mon, 12 Aug 2024 23:28:21 -0400 Message-ID: To: Pieter Kasselman Content-Type: multipart/alternative; boundary="00000000000039046a061f8834e8" Message-ID-Hash: CQRQQAB5MPBHU5BBEVI2KDS4BMOEOU6E X-Message-ID-Hash: CQRQQAB5MPBHU5BBEVI2KDS4BMOEOU6E X-MailFrom: ajstein.standards@gmail.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" X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BWimse=5D_Re=3A_Authentication_Levels_for_Workloads?= List-Id: WIMSE Workload Identity in Multi-Service Environment Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000039046a061f8834e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 29, 2024 at 10:33=E2=80=AFAM Pieter Kasselman < pieter.kasselman@microsoft.com> wrote: > Thanks A.J. > > > > Can you say a little more on how you would benefit if such a draft exists= ? > First off, I apologize for the late reply. Re the benefit: I have worked in the public sector in digital services in the United States where "high assurance" requirements and practices obviate the need for better clarity here. I appreciate the interest thus far (I have looked at slides, not yet completed watching the WIMSE session on YouTube) to compare and contrast to something *akin* to SP 800-63 authenticator levels for workloads. I think that framing helped me quickly understand and I presume others (even if that comparison is not the only basis or framing, it will be a starting point for many). I had not even considered the significance of this gap as it existed in those environments where authenticating workloads instead of users or the user identities they proxy until this thread came up. So at least for me, a standard, interoperable approach for this (especially so it is not just use whatever the environment's predominant cloud service officers as a customer mapping or foundational layer) would be helpful to me. I hope that help explains my support for work in this area. > Cheers > > > > Pieter > > > > *From:* A.J. Stein > *Sent:* Monday, July 29, 2024 3:25 PM > *To:* Justin Richer > *Cc:* wimse@ietf.org > *Subject:* [Wimse] Re: Authentication Levels for Workloads > > > > You don't often get email from ajstein.standards@gmail.com. Learn why > this is important > > On Mon, Jul 29, 2024 at 10:03=E2=80=AFAM Justin Richer = wrote: > > In the Vancouver meeting, there was a presentation from Ryan Hurst > on Authentication Levels for Workloads. While this is not a current WG > charter item, the energy in the room indicated that it is a topic of > interest. As such, the chairs would like to encourage conversation on thi= s > topic. Please see the presentation slides [1] and recording [2] for more > information. > > > > I had missed the WIMSE session and not reviewed the agenda. This > presentation is informative to me based on the first few minutes, so than= ks > for bringing it up.I will now watch the full session later. > > > > I would also like to encourage the presenters to create an I-D to capture > their thoughts on this topic to encourage further discussion. > > > > As one lurker and hardly active contributor, I would benefit from this I-= D > if they move forward with it. > > > > =E2=80=94 Justin and Pieter > > > > [1] > https://datatracker.ietf.org/meeting/120/materials/minutes-120-wimse-2024= 07241630-00 > > [2] https://www.youtube.com/watch?v=3D-BVTXj94wbw > > -- > Wimse mailing list -- wimse@ietf.org > To unsubscribe send an email to wimse-leave@ietf.org > > --00000000000039046a061f8834e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 29, 2024 at 10:33=E2=80=AFAM = Pieter Kasselman <piet= er.kasselman@microsoft.com> wrote:
<= 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">

Thanks A.J.

=C2=A0

Can you say a little more on how you would benefit if= such a draft exists?


First off, I apologize for the late reply.

Re the benefit: I have worked in the public sector in digital services in = the United States where "high assurance" requirements and practic= es obviate the need for better clarity here. I appreciate the interest thus= far (I have looked at slides, not yet completed watching the WIMSE session= on YouTube) to compare and contrast to something akin to SP 800-63 = authenticator levels for workloads. I think that framing helped me quickly = understand and I presume others (even if that comparison is not the only ba= sis or framing, it will be a starting point for many).

=
I had not even considered the significance of this gap as it existed i= n those environments where authenticating workloads instead of users or the= user identities they proxy until this thread came up. So at least for me, = a standard, interoperable approach for this (especially so it is not just u= se whatever the environment's predominant cloud service officers as a c= ustomer mapping or foundational layer) would be helpful to me.
I hope that help explains my support for work in this area.
=C2=A0
<= div class=3D"msg-6996758837443557439">

Cheers

=C2=A0

Pieter

=C2=A0

From: A.J.= Stein <ajstein.standards@gmail.com>
Sent: Monday, July 29, 2024 3:25 PM
To: Justin Richer <jricher@mit.edu>
Cc: wimse@ietf.o= rg
Subject: [Wimse] Re: Authentication Levels for Workloads

=C2=A0

On Mon, Jul 29, 2024 at 10:03=E2=80=AFAM Justin Richer <jricher@mit.edu> wr= ote:

In the Vancouver meeting, there was a presentation f= rom Ryan Hurst on=C2=A0Authentication Levels for Workloads. While this is n= ot a current WG charter item, the energy in the room indicated that it is a= topic of interest. As such, the chairs would like to encourage conversation on this topic. Please see the present= ation slides [1] and recording [2] for more information.

=C2=A0

I had missed the WIMSE session and not reviewed the = agenda. This presentation is informative to me based on the first few minut= es, so thanks for bringing it up.I will now watch the full session later.

=C2=A0

I would also like to encourage the presenters to cre= ate an I-D to capture their thoughts on this topic to encourage further dis= cussion.

=C2=A0

As one lurker and hardly active contributor, I would= benefit from this I-D if they move forward with it.

=C2=A0

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

--00000000000039046a061f8834e8--