Re: [SPICE] Call for consensus on SPICE charter

Alexander Stein <ajstein.standards@gmail.com> Fri, 15 March 2024 23:09 UTC

Return-Path: <ajstein.standards@gmail.com>
X-Original-To: spice@ietfa.amsl.com
Delivered-To: spice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA97C14F5E9 for <spice@ietfa.amsl.com>; Fri, 15 Mar 2024 16:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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_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=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 FlBR_-xXI7Zg for <spice@ietfa.amsl.com>; Fri, 15 Mar 2024 16:09:44 -0700 (PDT)
Received: from mail-yb1-xb43.google.com (mail-yb1-xb43.google.com [IPv6:2607:f8b0:4864:20::b43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE48C14F6A2 for <spice@ietf.org>; Fri, 15 Mar 2024 16:09:44 -0700 (PDT)
Received: by mail-yb1-xb43.google.com with SMTP id 3f1490d57ef6-dcc4de7d901so2239469276.0 for <spice@ietf.org>; Fri, 15 Mar 2024 16:09:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710544184; x=1711148984; darn=ietf.org; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=RFLkAaRBDUULVVburP7UiW5c1apUrKQ1RPXJtYlorIE=; b=d/ZjOaWLsjT70/CJyoDE70mgxMP2SUnb2hVSQZ+aXBUTrQiVbt8wg1VimzjNBYxJJ7 3yAgKH4MaHXI6TMobcK/EgMN4DPukIjOtG0Dep25Glag4+/V/zOr57+ZoJ05aJ7cOlC+ Po8YpWPUtcwAjPgCTJSKE8LkPRdy7sBPlnOQbWk7cHDmajGwgrz5iqq/Z3QFXwF8D+cV MRKvKuafDNtGGFvKjQPHqpUFgz8NJPKWV6kZmhwA7bVU5hgOfESgbxvOS0O9q1VxVDt7 AOIJLDWy0eB5C8qq6aUjUnTke1KaAYeVMB9gVA2ZumccuRuIE7x8sqAZFkymcgLIVwa1 eMlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710544184; x=1711148984; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=RFLkAaRBDUULVVburP7UiW5c1apUrKQ1RPXJtYlorIE=; b=KDrY8gUbykLwmdDwfH4s/W7AnRTWOJEBhiT5yktL9MLZcu3ti3BWI6CSbXpS6SLNF5 mnfucKoWA8viF4FmbOTj7hsLX6Gcd0e7ZuLhT2Jy1cqjEiT1YLnptg/sPxdZEgC05v9w hAl0LxWowi9FiI7a3oPoVRlzb8aKQwDeZD8Ce5JEvsj1ooxl9KIpMaWZeysEniurDd5+ BS7LkL0SLV+Egs97mpIHlTJ/h1H/wtcvI5Fba6OsNF93G5efunqIuAcUQSuH7kbPPJCV aiM+X5XoeUNa73V5+38nCqZ6Bezv8koZZKg7nqjuiGBOlW5sTUV7hJGEpBWS0FHIGmMc 8Zcw==
X-Forwarded-Encrypted: i=1; AJvYcCVdy1bLOdoowtKdI4b31/VQsdl4IhffrNt6fbvnebGluL5sxST6TWxLLUMRL++sRwKaDqlUQqfW360EFKzs9A==
X-Gm-Message-State: AOJu0Yy0GkBLSN343S3FG8rJdDUpyLLE9pdyIXMqc0gwa/vt+yGpjx+A xgtqFSNx6B+dVY8N2CT2ndSMRYP/oU2DsZC9hZi6P0sz+8/OoSik1+LirOyvjiw=
X-Google-Smtp-Source: AGHT+IHaqf9FSTlM8kQeVMxGRV4LQp9pD9aIrSh7DD9NmYFbJ3GFjvwdMQIDOO9Ssq2yFsIvqsAQEA==
X-Received: by 2002:a25:9186:0:b0:dcf:288e:21ca with SMTP id w6-20020a259186000000b00dcf288e21camr5818380ybl.11.1710544183454; Fri, 15 Mar 2024 16:09:43 -0700 (PDT)
Received: from [10.67.58.14] ([185.156.46.159]) by smtp.gmail.com with ESMTPSA id ay29-20020a05622a229d00b00430b385f721sm932962qtb.15.2024.03.15.16.09.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Mar 2024 16:09:41 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------5IC1EZOzh4WzoSszaCsIeIEU"
Message-ID: <ab5a0538-7601-4c7c-84df-8c745da63936@gmail.com>
Date: Fri, 15 Mar 2024 19:09:40 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Roman Danyliw <rdd@cert.org>, "spice@ietf.org" <spice@ietf.org>
References: <BN2P110MB110725C85B7253C421DDFE71DC4BA@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <BN2P110MB110764501C760AD94DBCE26DDC23A@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <CAN8C-_+HWs-rVoTgHK+-2+b3Cn=c9ssDv_PcBEM_i35S1BwdDQ@mail.gmail.com> <BN2P110MB11074F83FFB84C633B719BE7DC23A@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <BN2P110MB11074ECDC5C0262E97EDF5B8DC26A@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <BN2P110MB1107D912F7410FB25D600D53DC2BA@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
From: Alexander Stein <ajstein.standards@gmail.com>
In-Reply-To: <BN2P110MB1107D912F7410FB25D600D53DC2BA@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spice/a7_MAHlALX47bqQwzVifFLhziIY>
Subject: Re: [SPICE] Call for consensus on SPICE charter
X-BeenThere: spice@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Secure Patterns for Internet CrEdentials <spice.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spice>, <mailto:spice-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spice/>
List-Post: <mailto:spice@ietf.org>
List-Help: <mailto:spice-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spice>, <mailto:spice-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Mar 2024 23:09:49 -0000

I have reviewed the proposed changes in the 03 draft and I am supportive 
of the changes, and those drafts before them, as strong foundational 
text for a charter. As Roman outlined well in this message I am replying 
to, many of the unaddressed issues are editorial or there is an unclear 
way forward to address items in an immediate way in a foundational 
charter text. We have vacillated between more or less detail on these 
points in several iterations.

To echo the previous analysis of another contributor on this mailing 
list at a similar juncture, there is a potential for perfect being the 
enemy of good if we must go beyond rough consensus on addressing all 
these items to the full satisfaction of everyone. I will echo that at 
this point in time I feel the same now and hope we can address these 
points in the work items and deliverables. We will inevitably have to 
realize them despite how satisfactorily we outline them in the charter.

On 3/11/24 20:58, Roman Danyliw wrote:
>
> Hi!
>
> I continue to observe that there is strong consensus to form a WG 
> around digital credentials.  However, feedback continues to come on 
> the mailing list on how precisely the charter should read.
>
> To facilitate further discussion, I’ve published 00-03, 
> https://datatracker.ietf.org/doc/charter-ietf-spice/00-03/. It 
> includes the rough consensus which has formed on the list on reducing 
> the definitional text around the three-party terms.
>
> I see the following unaddressed issues being raised and discussed.
>
> (1) Explicitly adding RFC 6973 and RFC8280-reviews
>
> AD assessment: this feedback appears to be in the rough with the 
> consensus.  There appears to be extremely limited support for this 
> addition.
>
> (2) Replace “confidentiality” with “security-by-design” in “Privacy by 
> design, confidentiality, and consent will be considered, and guidance 
> will be given for each proposed standards in the program of work.”
>
> AD assessment: “confidentiality” had consensus in the call for 00-00.
>
> AD question: why is this change necessary and not editorial?  What new 
> security or design property is this introducing?  How will we know the 
> solution has “security by design”?
>
> (3) Reducing the specificity of “A proposed standard Metadata & 
> Capability Discovery protocol for JWT, CWT, SD-JWT, SD-CWT, CWP and 
> JWP using HTTPS/CoAP” to be “A proposed standard Metadata & Capability 
> Discovery protocol for using HTTPS/CoAP”
>
> AD assessment: this technology list was added based on the 00-00 
> feedback so it appears that everyone who supported 00-00 has not had a 
> chance to fully review 00-01/00-02.
>
> AD question: Why is this specific text not helpful?  What desired 
> scope is it precluding?  Why is generalization needed?
>
> (5) Including scope for multiple “Metadata & Capability Discovery” 
> protocols
>
> AD question: I could hypothetically see how multiple protocols might 
> be needed based on different use cases.  However, I am concerned that 
> there is desire for this broader scope without the ability to describe 
> for which formats/use cases (if “JWT, CWT, SD-JWT, SD-CWT, CWP and 
> JWP” is too narrow)?
>
> Practically, if there are multiple protocols, I would want to see 
> milestones which scopes the first two meta-data protocol to justify 
> that more than one protocol is needed.
>
> Otherwise, if these protocols can’t be named now, why can’t a future 
> WG recharter after it has figured out what protocol it needs?
>
> (6) 
> https://mailarchive.ietf.org/arch/msg/spice/Rpfwt8nc2qgyS_-YEz2rnrxmZWk/ 
> has an editorial recommendation
>
> AD assessment: Before streamlining this text, I’d like to see how the 
> above resolves first.  A proposal on this change would be appreciated.
>
> Regards,
>
> Roman
>
> *From:* Roman Danyliw <rdd@cert.org>
> *Sent:* Friday, March 8, 2024 10:38 PM
> *To:* spice@ietf.org
> *Subject:* Re: [SPICE] Call for consensus on SPICE charter
>
> Hi!
>
> Thanks for all of the additional feedback on 00-01 charter.  I’ve 
> published a new version 00-02 to address some of the feedback.
>
> Version 00-02
>
> https://datatracker.ietf.org/doc/charter-ietf-spice/00-02/
>
> Diff between 00-01 and 00-02
>
> https://author-tools.ietf.org/iddiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spice%2Fwithmilestones-00-01.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spice%2Fwithmilestones-00-02.txt&difftype=--html 
> <https://author-tools.ietf.org/iddiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spice%2Fwithmilestones-00-01.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spice%2Fwithmilestones-00-02.txt&difftype=--html>
>
> The narrative explanation of these changes is as follows:
>
> * Removed introductory text which didn't scope the work (from Denis)
>
> * Refined definitional language on holder behavior based on confusion 
> around the wording of "proof of digital credential" (from Denis)
>
> * Removed the example citing BBS to convey a flexible scope (from 
> Christopher)
>
> * Added TEE as a technology for consideration (from Manu)
>
> * Simplified "Privacy and security considerations regarding ..." 
> sentence (from Watson)
>
> * Renamed "Metadata protocol" to be "Metadata & Capability Discovery 
> protocol" (per Watson)
>
> Regards,
>
> Roman
>
> *From:* Roman Danyliw <rdd@cert.org>
> *Sent:* Monday, March 4, 2024 6:38 PM
> *To:* spice@ietf.org
> *Cc:* Orie Steele <orie@transmute.industries>
> *Subject:* Re: [SPICE] Call for consensus on SPICE charter
>
> Hi!
>
> Thanks for this pull request.
>
> I took the text referenced below in Github, made a few markdown 
> formatting changes, added TEEP as a WG needed for coordination, and 
> published it as charter version 00-01 in the Datatracker.
>
> New 00-01 charter text
>
> https://datatracker.ietf.org/doc/charter-ietf-spice/00-01/
>
> Diff from 00-00
>
> https://author-tools.ietf.org/iddiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spice%2Fwithmilestones-00-00.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spice%2Fwithmilestones-00-01.txt&difftype=--html 
> <https://author-tools.ietf.org/iddiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spice%2Fwithmilestones-00-00.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spice%2Fwithmilestones-00-01.txt&difftype=--html>
>
> Roman
>
> *From:* SPICE <spice-bounces@ietf.org> *On Behalf Of *Orie Steele
> *Sent:* Monday, March 4, 2024 4:48 PM
> *To:* Roman Danyliw <rdd@cert.org>
> *Cc:* spice@ietf.org
> *Subject:* Re: [SPICE] Call for consensus on SPICE charter
>
>
> 	
>
> *Warning:*External Sender - do not click links or open attachments 
> unless you recognize the sender and know the content is safe.
>
> Thanks Roman!
>
> We opened 
> and merged https://github.com/transmute-industries/ietf-spice-charter/pull/31 
> <https://github.com/transmute-industries/ietf-spice-charter/pull/31> 
> to address the feedback gathered from the consensus call.
>
> The revised charter text is here: 
> https://github.com/transmute-industries/ietf-spice-charter/blob/main/charter.md
>
> I believe it addresses all of the blocking feedback, but obviously 
> folks who responded to the consensus call will need to review and 
> confirm that.
>
> I'm not sure if the cut off applies to charters, or ADs but I request 
> that you push -01 with the text changes above,
> and we then circle back to the folks who had blocking comments to see 
> if the changes have addressed their concerns,
> or if they have additional text suggestions that we can review.
>
> Regards,
>
> OS
>
> On Mon, Mar 4, 2024 at 3:15 PM Roman Danyliw <rdd@cert.org> wrote:
>
>     Hi!
>
>     Thank you for all of the robust feedback on the 00-00 charter text
>     across multiple mailing lists. The majority of feedback (14/20
>     respondents) which expressed an opinion on chartering supported
>     forming a WG around the existing charter text. There was a
>     minority (6/20 respondents) that shared blocking concerns. 
>     Various feedback on non-blocking charter refinement was also shared.
>
>     Given the feedback, I assess there is energy to do work in this
>     space.  However, the 00-00 charter text would benefit from
>     additional refinement. Below is an attempt to summarize this
>     feedback around common themes.  If I have misrepresented your
>     position, please correct me.
>
>     # Blocking
>
>     * Use cases served by SPICE
>     (https://mailarchive.ietf.org/arch/msg/spice/Ws02RZqrsLKQTBIHV4aHrCeNWp8/)
>
>     * Privacy considerations for SPICE
>     (https://mailarchive.ietf.org/arch/msg/spice/ab5V0KotNa7CtEzl_yfIBOK2m-o/)
>
>     * Deployment-oriented privacy guidance
>     (https://mailarchive.ietf.org/arch/msg/spice/fU6AshwxaA31HcYc9K4wU8iEfXg/)
>     and
>     (https://mailarchive.ietf.org/arch/msg/spice/mhQAWCCsMVFgxEXFYkiPM3tGXKE/)
>
>     * Coupling with W3C
>     (https://mailarchive.ietf.org/arch/msg/spice/nnAA7MARNH7rxjfcgHHF6Uc4UsQ/)
>
>     * Required support hash-based elision
>     (https://mailarchive.ietf.org/arch/msg/spice/nnAA7MARNH7rxjfcgHHF6Uc4UsQ/)
>
>     * Required anchoring in hardware security/TEE 
>     (https://mailarchive.ietf.org/arch/msg/spice/7WjNnTCfDM7xUzQg9-N7-91dLDo/)
>
>     * Clarity and wisdom of the JSON/COSE split
>     (https://mailarchive.ietf.org/arch/msg/spice/fU6AshwxaA31HcYc9K4wU8iEfXg/)
>
>     * (multiple issue not easily distinguishable into “blocking” and
>     other” feedback)
>     https://mailarchive.ietf.org/arch/msg/spice/DbQcUnCYbbIApV5YPtmXlf8AneA/
>
>     # Other Feedback
>
>     * Clarify “HTTP/CoAP”
>     (https://mailarchive.ietf.org/arch/msg/spice/ZAzrJOmXwRAUholCD1eYDPs7y5I/)
>
>     * Add TEEP as a coordinating WG
>     (https://mailarchive.ietf.org/arch/msg/spice/v1hYxR8-ZISIukbetYU9269clHA/)
>
>     * WG Name and term “digital credential” is overloaded
>     https://mailarchive.ietf.org/arch/msg/saag/TE45RJZg2g8FaZydumJKE8IPgA4/
>     https://mailarchive.ietf.org/arch/msg/spice/Qo23p6hgAHlXt_8S9SHJ5WVCcn4/
>     https://mailarchive.ietf.org/arch/msg/spice/ss5tyQCsVR2jiq-uryKhn7yAPKI/
>
>     * Relationship/Considerations for mDoc
>     https://mailarchive.ietf.org/arch/msg/spice/xiRpmd-Bexv94qentlGg1Snjw1A/
>     https://mailarchive.ietf.org/arch/msg/spice/yQAhs2FHNFAZxhSI1VMTYaOCEu4/
>     https://mailarchive.ietf.org/arch/msg/spice/WsIvbPNnfu-bjUqIE0Mp-3cXEDA/
>
>     * Current status of W3C document
>     (https://mailarchive.ietf.org/arch/msg/spice/xiRpmd-Bexv94qentlGg1Snjw1A/)
>
>     * Break out verified and validated by the same entity
>     (https://mailarchive.ietf.org/arch/msg/spice/IAu8kaOJ0tKRsdufQUyM4rjX9qc/)
>
>     Regards,
>     Roman
>
>     > -----Original Message-----
>     > From: Roman Danyliw <rdd@cert.org>
>     > Sent: Friday, February 9, 2024 2:01 PM
>     > To: spice@ietf.org
>     > Subject: [SPICE] Call for consensus on SPICE charter
>     >
>     > Hi!
>     >
>     > At IETF 118, a BoF on SPICE was convened [1].  The meeting
>     provided a strong
>     > consensus signal that there was a problem to solve and that the
>     IETF was the
>     > right place to do that.  While there was enthusiasm around the
>     topic, there was
>     > strong feedback the scope of the work needed refinement.
>     >
>     > In recent months, there have been numerous follow-on discussion and
>     > refinement on the charter text.  As we approach final planning
>     for IETF 119, I'd
>     > like to assess where we stand with a formal consensus check on a
>     revised
>     > charter responsive to the feedback during the IETF 118 BoF. 
>     Please see
>     > https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/
>     (00-00) and respond
>     > to the list by Thursday, February 22 (two weeks from now):
>     >
>     > ==[ start consensus check questions ]==
>     > (1) Do you support the charter text? Or do you have objections
>     or blocking
>     > concerns (please describe what they might be and how you would
>     propose
>     > addressing the concern)?
>     >
>     > If you do support the charter text:
>     > (2) Are you willing to author or participate in the developed of
>     the WG drafts?
>     >
>     > (3) Are you willing to review the WG drafts?
>     >
>     > (4) Are you interested in implementing the WG drafts?
>     >
>     > ==[ end consensus check questions ]==
>     >
>     > If you previously spoke up at the BoF, please repeat yourself
>     here.  Earlier
>     > versions of a charter were shared on the mailing list and
>     informal inquiries of
>     > support were requested.  Please repeat your support or concerns
>     for this 00-00
>     > charter even if you commented on earlier iterations.
>     >
>     > The outcome of this consensus check will inform how to plan for
>     the second
>     > SPICE BoF scheduled at IETF 118. Non-exhaustive options include:
>     >
>     > (a) If we find consensus on the mailing with the current charter
>     text, no BoF is
>     > needed, and it will be canceled.  Note, this should be viewed as
>     a success.  The
>     > entire point of the BoF is to produce and find consensus on a
>     charter and that
>     > goal would have been realized.  SPICE proponents have indicated
>     a side
>     > meeting will be held.
>     >
>     > (b) If there are blocking concerns which cannot be resolved on
>     the mailing list,
>     > these will form the basis of the IETF 118 BoF agenda
>     >
>     > A common question I've already gotten is can SPICE be a WG by
>     IETF 119. The
>     > simple answer is no -- there is insufficient time to perform all
>     of the necessary
>     > review steps before IETF 119 to charter SPICE.  In more detail,
>     assume
>     > hypothetically that there is unbridled enthusiasm for the work
>     from the
>     > community and IESG: this email consensus check takes 2 weeks
>     (till Feb 22) + 1
>     > week advanced notice before an IESG formal telechat for initial
>     review + initial
>     > IESG review (on Feb 29) + 10 days for community review + a
>     return back for
>     > final IESG approval at a formal telechat. The last formal IESG
>     telechat is
>     > March 7 (which is before the community review period would
>     close).  In the
>     > best case by IETF 119, this charter would have been through
>     initial IESG review,
>     > all community feedback would have been adjudicated, and the
>     charter would
>     > be waiting discussion at the first formal IESG telechat after
>     the IETF 119
>     > meeting.
>     >
>     > As a process matter, options (a) and (b) are both hypothetical
>     options pending
>     > the results of this call for consensus. However, I'd like to be
>     sensitive to earlier
>     > feedback on my use of option-(a) for the last  WG chartered out
>     of SEC,
>     > KEYTRANS.  In the lead up to IETF 118, option-(a) was exercised
>     for the planned
>     > KEYTRANS BOF (i.e., it was canceled) because consensus was found
>     on the
>     > mailing list and sent to the IESG before the meeting.  There was
>     community
>     > feedback that canceling the BOF denied an opportunity to provide
>     feedback
>     > that was being saved for the F2F BoF and missed a F2F
>     opportunity to gather
>     > interested parties.  To that end, I will be cross posting this
>     call for consensus on
>     > SPICE to SAAG and identity adjacent WG lists (e.g., JOSE, COSE,
>     SCITT, OAuth,
>     > RATS) to ensure broad awareness of this call.  SPICE proponents
>     have signaled
>     > to me that they would organize a side meeting if the BoF is
>     canceled to ensure
>     > F2F discussions.  Finally, if you are already aware of factors
>     which necessitate a
>     > F2F BOF discussion that can't be introduced as part of this
>     consensus check on
>     > the mailing list, please let me know.
>     >
>     > Thanks,
>     > Roman
>     >
>     > [1] https://datatracker.ietf.org/doc/minutes-118-spice-202311070830/
>     -- 
>     SPICE mailing list
>     SPICE@ietf.org
>     https://www.ietf.org/mailman/listinfo/spice
>
>
> -- 
>
> *ORIE STEELE
> *Chief Technology Officer
> www.transmute.industries <http://www.transmute.industries>
>
> Image removed by sender. <https://transmute.industries/>
>
>