Re: [SPICE] Revised Charter

[Roman Danyliw <[e-mail]>]

Hi!

Thanks for all of the iteration to get to this text.  I have a few questions and comments.

** Per the “Background” Section:

-- “Some sets of claim names are registered with IANA and originate from the IETF, OIDF and other standards organizations.”

o Editorially, at no point in the text so far has there been any link made between “sets of claims” and a “digital credential”.  The introductory paragraph talks about “values” and “attributes” of claims.  I recommend some bridging text.

o As a reader, I’m not sure why I am being told this detail.  No subsequent text in the deliverables mentions that claims from other SDOs need to be used or that they are being built upon.

-- “IETF and IRTF working groups have developed foundational building blocks with BBS Signatures, RSA Blind Signatures, Verifiable Random Functions, or other Selective-Disclosure and collection limitation techniques.”

o Editorial nit.  IRTF doesn’t have WGs, it has research groups. The IESG will flag this.

o There are assertions of foundational building blocks but the text doesn’t narrative how this work would build on them.  One can infer that BBS/VRF/etc are the crypto that will be used.  The IETF WG references of “Selective-Disclosure” and “collection limitation techniques” is what?  Recommend either citing WGs or RFC/drafts if this link is important.

o I’m trying to keep the IETF/IRTF lanes clear.  Coordination with CFRG is noted later.  Is there coordination, or reuse?  What planned activities in this WG would alter the course of CFRG?

** Per the “Key Design Properties of Digital Credentials” section

-- What is the intended use of this section?  In what way does this text scope the planned work?  For example, will the WG deliver some version of those as part of the “A document specifying the selective disclosure of claims in a secure and privacy-friendly manner”? Are those related to the planned architecture deliverable?)

-- I’m a little confused by the framing of this section as being able design properties of “digital credentials” but the “In-Scope”/”Goal”/”Deliverable” sections aren’t linked to digital credentials.  Some editorial bridging is needed.

** Strongly recommend merging “In-Scope” and “Goals” sections.  Move the text currently in Goals to the end of the current “In Scope” text (i.e., reverse the order).  Editorially, charters typically first say what they will do and then describe who they will work with.

** Per the “Goals”

-- Per the text “Additionally, the SPICE WG will coordinate with other SDOs, such as ISO or W3C, on data model elements or protocols needed to support existing credential use cases”

o what is the thinking behind “support existing credential use cases”?  Are these new design goals?

o I observe that ISO is a very BIG organization.  IETF even has multiple liaisons for subsets of ISO.  Can this text be more specific about the relevant links?

** Per the “In-Scope”

-- Per the text “The SPICE WG will consider the use of TEEs (Trusted Execution Environments) for managing key material and digital credentials.”  Can that design be made now?  Can this be deferred for future charter scope?  I’m practically asking what “consider” means here.  It seems like a conditional scope (i.e., “we don’t know if we want to deliver this but we want it in scope”).

-- Per the text “Focusing on crisp technical specifications and producing separate informative guidance documents helps to keep technical interested parties involved”, I observe that the planned deliverables only include a single informative architecture.  Is that sufficient?  Perhaps that is the lesson learned?

** Per the Deliverables?

-- Will the meta-discovery document describe a single protocol? multiple protocols for discovery?  Does it build on any prior work protocol work (e.g., is it an HTTP API? COAP?)

-- Per a “document specifying the selective disclosure of claims in a secure and privacy-friendly manner”:

o What is the relation between this document and digital credential (the substance of the front matter)?  Is this providing a framework/set of claims to let others produce their own digital credentials with particular security properties?

o What is the relationship between the “security” and “privacy-friendly” properties and the more detailed key design properties?

o What is the encoding of the claims for this document? JSON and CBOR are noted in the lesson learned but not in the explicit scoping.

Roman

From: Orie Steele <[e-mail]>
Sent: Thursday, January 18, 2024 1:19 PM
To: [e-mail]
Subject: [SPICE] Revised Charter

Hello Spice Enthusiasts,

Our revised draft charter can be found here:

- https://github.com/transmute-industries/ietf-spice-charter/blob/8f140a014ed13a21ff308b4d48d745ead67d8c54/charter.md

Thanks to everyone who contributed text on github and through the mailing list.

As mentioned on our calls, I will submit a bof request with the draft charter text as of today.

If anyone has objections to the current charter text, please provide NEW and OLD suggestions through the mailing list (on a seperate thread), so we can finalize any remaining gaps.

If you support the current draft charter text, please reply to this email indicating that you support the current text.

I support the current charter text.

Regards,

OS


--



ORIE STEELE
Chief Technology Officer
www.transmute.industries

[Image removed by sender.]<https://transmute.industries/>