Re: [SPICE] Call for consensus on SPICE charter

[Michael Prorock <[e-mail]>]

+1 Alexander



Mike Prorock
founder - mesur.io

On Fri, Mar 15, 2024, 16:09 Alexander Stein <[e-mail]>
wrote:

> 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 <[e-mail]> <[e-mail]>
> *Sent:* Friday, March 8, 2024 10:38 PM
> *To:* [e-mail]
> *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
>
>
>
> 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 <[e-mail]>
> *Sent:* Monday, March 4, 2024 6:38 PM
> *To:* [e-mail]
> *Cc:* Orie Steele <[e-mail]>
> *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
>
>
>
> Roman
>
>
>
> *From:* SPICE <[e-mail]> *On Behalf Of *Orie Steele
> *Sent:* Monday, March 4, 2024 4:48 PM
> *To:* Roman Danyliw <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]> 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 <[e-mail]>
> > Sent: Friday, February 9, 2024 2:01 PM
> > To: [e-mail]
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spice
>
>
>
>
> --
>
>
>
>
> *ORIE STEELE *Chief Technology Officer
> www.transmute.industries
>
> [image: Image removed by sender.] <https://transmute.industries/>
>
> --
> SPICE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spice
>