I'm forwarding this message to SPICE https://mailarchive.ietf.org/arch/browse/spice/?gbt=1&index=TTgOt6qI3CzILzV4i34nLmkmeMc to the COSE list, as I believe it is relevant to this community.
---------- Forwarded message --------- From: Christopher Allen <[email protected]> Date: Wed, Feb 14, 2024 at 10:20 AM Subject: Re: [COSE] FW: Call for consensus on SPICE charter To: <[email protected]> Cc: Shannon Appelcline <[email protected]> ==[ 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)? I'm concerned that https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/ charter locks us into following the W3C Verifiable Credentials data model (of which I am have been an "invited expert" for many years), without sufficient review of requirements. Focusing on W3C VCs also likely risks locking us out of some architectures, including trusted hardware support, quorum-based multiparty threshold cryptography (a current NIST "first call" initiative https://nvlpubs.nist.gov/nistpubs/ir/2023/NIST.IR.8214C.ipd.pdf ), other forms of zk proofs, and hash-based elision for data-minimization and privacy. In particular about the latter, I believe there should be requirement for hash-based elision, I'm co-author with Shannon Appelcline on a "Problem Statement and Areas of Work for Deterministic Hashed Data Elision here: https://datatracker.ietf.org/doc/draft-appelcline-hashed-elision/ This document discusses the privacy and human rights benefits of data minimization via the methodology of hashed data elision and how it can help protocols to fulfill the guidelines of RFC 6973: Privacy Considerations for Internet Protocols and RFC 8280: Research into Human Rights Protocol Considerations. We need better ways to protect privacy, especially for sensitive data such as that found in many credentials, but also for sensitive data such as health/wellness, sensors/photos/audio, and AI . Hashed-data elision allows you to remove certain data while maintaining hashes that can be used to prove the existence of that data and that can themselves be signed, allowing any validation to remain verifiable, even after elision. ISO mDOC has a different form of hash-based elision, but it is not mandatory. I believe it should be mandatory in SPICE. If you do support the charter text: (2) Are you willing to author or participate in the developed of the WG drafts? If review of requirements to meet concerns of RFC 6973 & RFC 8280 are added to charter, or some form of elision is mandated. (3) Are you willing to review the WG drafts? Yes. (4) Are you interested in implementing the WG drafts? If improvements to meet RFC 6973 & RFC 8280 are added. ==[ end consensus check questions ]==
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
