Re: [SPICE] Call for consensus on SPICE charter

[Denis <[e-mail]>]

Hi Paul,

A few responses to Roman's email:

> 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.
>
Obviously privacy will be considered and hence this is not necessary to 
mention these two RFCs.
Furthermore, RFC 6973 is rather "old"  i.e., more than 10 years (2013) 
... and would need to be updated.

It provides guidance for document authors in the form of a questionnaire 
about a protocol being designed.
It had the merit to attempt to define a few privacy terms like 
Unlinkability.

Unfortunately, the current definition of Unlinkability would need to be 
updated.

*Unlinkability*:  Within a particular set of information, the inability 
of an *observer *or *attacker *to distinguish whether two
                           items of interest are related or not (with a 
high enough degree of probability to be useful to the *observer *or 
*attacker*).

This property is critical when there is a *collusion *between relying 
parties (i.e., in that case there is no "*observer*", nor "*attacker*").

>
> *(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”?
>
Why should only "confidentiality" be mentioned ? It should be noticed 
that the usual three security pillars (I, C, A) are insufficient in an 
ecosystem
(i.e. in a  distributed environment). At least, two additional "security 
considerations" need to be addressed: Untrackability and Untraceablity.

  * Untrackability (i.e., "Big Brother" prevention) needs to be
    considered when an issuer is being involved.
  * Untraceablity (i.e., not knowing the source of a trusted data but
    knowing that the data came from a trusted source) also needs to be
    considered.
    (group signatures are able to support this property).

Current measures to protect cryptographic keys (confidentiality, 
integrity and key export prevention) are insufficient. This is why TAs 
and TEEs must be considered.

The wording "Privacy by Design" has been introduced by Dr. Ann 
Cakoukian, the ICO of Ontario, Canada (Information and Privacy 
Commissioner).

She defined seven principles that can be found here: 
https://hillnotes.ca/2021/12/09/privacy-by-design-origin-and-purpose/

    *Principle 5 – End-to-end security: full lifecycle protection* PbD,
    having been embedded into the system prior to the first element of
    information being collected,
    extends securely throughout the entire lifecycle of the data
    involved – strong security measures are essential to privacy from
    start to finish.
    This ensures that all data are securely collected, used, retained,
    and then securely destroyed at the end of the process, in a timely
    fashion.
    Thus, PbD ensures cradle-to-grave, secure lifecycle management of
    information, end to end.

Security is included in the 5 th "Privacy by Design " principle.

Now, if in the credo of Dr. Ann Cavoukian, you replace the word 
"privacy" by the word "security", you obtain an explanation of what 
"Security by Design" may mean:

    Security must be incorporated into networked data systems and
    technologies, /by default/. Security must become integral to
    organizational priorities,
    project objectives, design processes, and planning operations.
    Security must be embedded into every standard, protocol and process
    that touches our lives.

Either, remove the word "Confidentiality" or replace it by "Security by 
Design".

Note that currently the same sentence includes "and *consent *will be 
considered". Consent is an important step but before it there needs to 
be a "choice" step before it.
Replacing "and *consent *will be considered" by "*choice* and *consent 
*will be considered" would not hurt. :-)

> *(**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?
>
AFAIC, my proposal was to drop *"CoAP for CBOR-based digital 
credentials"* for two reasons:

  * The protocols should not be limited to "*CBOR-based digital
    credentials "*
  * I wonder whether CoAP should be used as it is suited for 8 bits
    computers that have limited cryptographic performances and power
    consumption limitations.
    I wonder whether low power processors without a keyboard and without
    a display will be usable in the context of selective disclosure of
    claims.

I just noticed a sentence that previously did not caught my attention in 
the "Program of work" :

    The design will be inspired by the OAuth "vc-jwt-issuer" metadata
    work (draft-ietf-oauth-sd-jwt-vc
    <https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/>)
    which supports ecosystems using JSON serialization.

draft-ietf-oauth-sd-jwt-vc-03 does not include any "discovery" protocol. 
This sentence should be removed.

I am wondering if the following sentence should remain: "*General Key 
discovery is out of scope for this WG*".
Do we already have a key discovery protocol when ring signatures are 
supported by a set of issuers ?


*Note: (4) is missing in the ordered list*

> *(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?
>
It is possible to have first :

  * a (simple) discovery protocol to find where the information that is
    looked for is located (it can involve multiple steps) and then
  * a (more complicated) collection protocol to collect different kind
    of metadata from the discovered distribution points.

I would appreciate to add an "*s*" to "protocol" both in the "Program of 
work" and the "Milestones":

Change :

  * A proposed standard covering Metadata & Capability Discovery
    protocol for ...

into:

  * A proposed standard *covering *Metadata & Capability Discovery
    protocol_*s*_ for ..

Change:

  * 03/2026 - Submit a document as a proposed standard covering Metadata
    & Capability Discovery protocol to the IESG for publication

into

  * 03/2026 - Submit a document as a proposed standard covering Metadata
    & Capability Discovery protocol_*s*_ to the IESG for publication

> (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.
>
Since Watson was the author of this concern, I let him propose how to 
resolve this point.
Personally, I don't have a problem with this "duplication".

Denis

> Regards,
>
> Roman
>
> *From:* Roman Danyliw <[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 
> <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 
> <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 <http://www.transmute.industries>
>
> Image removed by sender. <https://transmute.industries/>
>
>