Re: [SPICE] Call for consensus on SPICE charter

[Manu Fontaine <[e-mail]>]

Had a quick call with Hannes. This is to clarify that I support work on
"internet credentials" and that, as an IETF newbie, I don't want to hold up
the process.

My expectation is that we'll be able to discuss different approaches and
perspectives once the work starts.

In particular, assuming the word "secure" remains in the WG name, I'd
expect zero-trust, attack surface minimization, and an entity-centric
security model to guide the work.

See you in Brisbane.
Manu



On Thu, Mar 7, 2024 at 7:11 AM Manu Fontaine <[e-mail]> wrote:

> Agree with Denis on the distinction between entity and application. It's
> always some code somewhere "acting on behalf" of an entity. Which is why we
> think the word "Agent" is more appropriate than application.
>
> To be able to verify (i.e. not trust) these Agents, they should run in
> TEEs per RATS.
>
> To minimize the attack surface, and optimize the scalability of these
> Agents, we should standardize binary-level formats and protocols.
> Standardizing multiple options increases attack surface and goes against
> security goals.
>
> Manu
>
> On Thu, Mar 7, 2024, 6:37 AM Denis <[e-mail]> wrote:
>
>>
>> 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 cryptographic verifications.
>> 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 STEELE Chief Technology Officer www.transmute.industries
>>
>> <https://transmute.industries>
>>
>>
>> --
>> SPICE mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spice
>>
>