Re: [SPICE] Call for consensus on SPICE charter

[Denis <[e-mail]>]

The last version does not address all of the blocking feedback. In 
particular, several of my previous comments have still not been taken 
into account.

I have text suggestions that can be reviewed.See the seven points below.


*1) *Yes, it is a minor comment, but the first sentence of the charter 
could still advantageously be removed:

    "Digital credentials are essential to identity, authorization,
    licenses, certificates, and digitization use cases
    that are part of modernization efforts targeting efficiency and
    transparency".

*2) *The use of the right vocabulary is pretty important:

A "holder" is NOT "an entity (*person*, device, *organization*, or 
software agent)" but is a software *application* running under an 
environment.

A "verifier" is NOT an entity such as a *person*, since a person is 
unable to carry on cryptographicverifications.
It is also a software *application* running under an environment.

A verifier is also an application. It does not verify nor validate 
secured digital *credentials *but digital *presentations*.


OLD:

      * An "issuer", an entity (person, device, organization, or
        software agent) that constructs and secures digital credentials.
      * A "holder", an *entity (person, device, organization, or
        software agent) *that controls the disclosure of credentials.
      * A "verifier", an entity (person, device, organization, or
        software agent) that verifies and validates *secured digital
        credentials*.

NEW:

      * An "issuer", an application that issues digital credentials to
        holders *and takes care of the revocation status of these
        digital **credentials*.
      * A "holder", an application that requests digital credentials to
        issuers and derives from them *digital presentations* that can
        then be presented to a verifier.
      * A "verifier", an application that verifies and validates
        *digital **presentations*.

*3)* The wording "*proof of the digital **credential*" is unclear. 
Possession of a key or a *proof of knowledge of a key *needs to be provided
but this is insufficient if the key can be exported or used by one 
holder with the complicity of another holder, in particular when two 
holders accept to collude.

OLD:

    When *disclosed *by an *entity*, *a proof of the digital
    **credential *needs to be provided and verified,
    so that only the legitimate holder of the digital credential can
    take advantage of its possession.

NEW:

    When *presented *by a *holder*, a proof of *the ownership of *the
    digital *proof *needs to be provided *to a verifie*r,
    so that only the legitimate holder of the digital credential can
    take advantage of its possession, *including
    when one holder accepts to collude with another holder.*

An alternative wording and more accurate wording might be:

    When *presented *by a *holder*, a *proof of knowledge of a key*
    bound to the digital credential that has been used
    to create the digital presentation needs to be provided to a
    verifier, so that only the legitimate holder of the digital credential
    can take advantage of its possession, *including when one holder
    accepts to collude with another holder.*


*4)* Roman mentioned: "Add TEEP as a coordinating WG". However, the 
*TEEP working group* is still missing:

OLD:

    The SPICE WG, coordinates with RATS, OAuth, JOSE, COSE and SCITT
    working groups that develop documents related to the identity and
    credential space.

NEW:

    The SPICE WG, coordinates with *TEEP*, RATS, OAuth, JOSE, COSE and
    SCITT working groups that develop documents related to the identity
    and credential space.


*5) *Confidentiality is one of the many characteristics of security. 
"confidentiality" should be replaced by " security by design".


OLD:

    Privacy by design, *confidentiality*, and consent will be
    considered, and guidance will be given for each proposed standards
    in the program of work.

NEW:

    Privacy by design, *security by design*, and consent will be
    considered, and guidance will be given for each proposed standards
    in the program of work.


*6)*  Data collection limitation happens at the protocol level, while 
data minimization happens at the processing level of the data collected 
by the verifier.


OLD:

    Privacy and security considerations regarding redaction, linkability
    and selective disclosure will be developed for proposed standards in
    the program of work
    that offer data *minimization* capabilities.


NEW:

    Privacy and security considerations regarding redaction, linkability
    and selective disclosure will be developed for proposed standards in
    the program of work
    that offer data *collection limitation* capabilities.


*7) *  Roman mentioned: Clarify “HTTP/CoAP". The discovery protocol 
SHOULD NOT be based on CoAP and SHOULD NOT be limited to "CBOR-based 
digital credentials".
       The following words should be removed: "*/CoAP for CBOR-based 
digital credentials*". This removal is important.


OLD:

    A proposed standard Metadata Discovery protocol for JWT, CWT,
    SD-JWT, SD-CWT, CWP and JWP using HTTPS*/CoAP for CBOR-based digital
    credentials*
    to enable the 3 roles (issuers, holders and verifiers) to discover
    supported capabilities, protocols and formats for keys, claims,
    credential types and proofs.
    The design will be inspired by the OAuth "vc-jwt-issuer" metadata
    work (draft-ietf-oauth-sd-jwt-vc) which supports ecosystems using
    JSON serialization.

NEW:

    A proposed standard Metadata Discovery protocol_s_ for JWT, CWT,
    SD-JWT, SD-CWT, CWP and JWP using HTTPS to enable the 3 roles
    (issuers, holders and verifiers)
    to discover supported capabilities, protocols and formats for keys,
    claims, credential types and proofs. The design will be inspired by
    the OAuth "vc-jwt-issuer" metadata work
    (draft-ietf-oauth-sd-jwt-vc) which supports ecosystems using JSON
    serialization.

Denis


> 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 STEELEChief Technology Officerwww.transmute.industries
>
> <https://transmute.industries>
>
>