Re: [SPICE] Revised Charter

[Orie Steele <[e-mail]>]

Hey Roman,

We merged this PR on the informal call today:

https://github.com/transmute-industries/ietf-spice-charter/pull/22

The group believes we have addressed all feedback that is necessary to
address for the current charter.

Regards,

OS

On Thu, Jan 18, 2024 at 4:44 PM Roman Danyliw <[e-mail]> wrote:

> 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: Image removed by sender.] <https://transmute.industries/>
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>