Re: [SPICE] Feedback on SPICE charter

[Henk Birkholz <[e-mail]>]

Dear Roman,

thank you for your extensive review. It is a great help. We addressed 
almost all your comments in a first pass.

Changes are captured in a github branch on the charter text and a 
corresponding PR for visibility and targeted feedback and suggestions:

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

Please find detailed replies to your review in-line.


Viele Grüße,

Orie & Henk


On 12.10.23 18:08, Roman Danyliw wrote:
> Hi!
> 
> It's been very helpful to have a draft charter for discussion.  See https://github.com/transmute-industries/ietf-spice-charter/blob/main/charter.md.  I realize that we are still weeks before the BoF where key discussions need to occur and no consensus has been determined.  Additional editorial polish is also likely.  To contribute to the BoF planning, please find an early review of the charter.
> 
> ** Introduction Section
> 
> -- I read this section and wasn’t sure what IETF’s role was.  I was hoping to better understand the problem to solve so as to motivate the solution in later text.  The section left me with the impression that IETF standards are already deployed without an appreciation for the gaps.

First attempt to address is found in commit 04f116c.

> 
> -- Per “In order to meet privacy, security, and sustainability objectives, digital credentials need to be designed with awareness of computation and storage constraints associated with their use cases”, in the abstract that seems helpful.  However, what isn’t clear the totality of the objectives.  Subsequent text mentions “selective disclosure” and “unlikability”.  “Sustainability” is called out, but I can find no later references to it and design constraints tied to it.

Objective summary aggregated at a single point in Introduction is now 
found in commit b3b872e.

> 
> -- Per “The SPICE WG aims to support digitial credential formats based on existing IETF standards, and extend them to support stakeholders that are building compliance and automation systems based on industry adopted cryptography and protocols”, the setup is confusing for me.  Why would the SPICE WG support digital credential formats?  Should not it define them?  I’m not sure if this is editorial or nuanced scope statement.

Adjusted text to make it clear we are not defining credential formats, 
we are making a framework for others to do so with IETF standards is now 
also found in commit b3b872e.

> 
> -- “Digital credential” is being used as specialized term with a narrow scope which might not be obvious to casual reader.  For example, to some, an X.509 is a digital credential.  I would recommend a definition.

Added a definition for "Digital credential" in commit 635d829.

> 
> ** Goals Section
> 
> -- Nit.  WIMSE is BOF with no long-term standing for coordination so please remove it.

We removed WIMSE.

> 
> -- Per “Feedback from experts in other IETF working groups is gathered in the SPICE WG without creating fragments of credential work spread accross several existing places in the IETF.”  It isn’t clear to me how credential work is unified by this charter.  Is the pitch that SPICE reuses the building blocks of other IETF work to defined particular “digital credentials”?

Yes, we believe this was addressed in 04f116c, b3b872e, and 635d829. 
Still we added one small clarification on "Claims in IANA registry" in 
commit .

> 
> ** Goals/In-Scope Section
> 
> Two high-level questions:
> -- What’s the output?  Will it be a profile for CWT with additional properties (e.g., unlinkability) or (and?) will it be an entirely new “/token/framework”?  I see hints in the charter of both directions – the reference to EAT-as-a-framework suggests it will be a new derived format of something (i.e., EAT is not a CWT profile but reuses the claims registries) but the example of draft under work items cites https://datatracker.ietf.org/doc/draft-prorock-cose-sd-cwt/ which seems to profile CWT.

Intended output is an architecture document and additional documents 
related to specific properties, such as selective disclosure or 
unlinkability. Output documents are developed to address industry needs, 
e.g., selective disclosure and unlinkability of SBOMs. Corresponding 
changes to the charter are found in commit d7d5155.

> 
> -- Is the encoding format relevant and is it only COSE?  The text currently mentions “aligning JWT/CWT claims” and ensuring that JOSE/COSE is consistently applied.  Including draft-ietf-jose-json-web-proof is also mentioned.  However, a number of the example drafts all seem to be COSE related (draft-ietf-cose-merkle-tree-proofs, RFC9338, draft-prorock-cose-sd-cwt, draft-ietf-cose-key-thumbprint) except RFC9278.  In the “Relationship with W3C VCWG”, concerns with JSON, CBOR or other formats is mentioned.

We clarified the relationship between inspiring input documents and 
"desired properties" of digital credentials in commit 317ec4b.

> To the specifics:
> 
> -- Per “The work of the SPICE WG aligns JWT and CWT registered claim names for use with the 'Three Role Model' …”, what does it mean to “align claims”?  Does this mean register new ones?  Profile collections of them (i.e., specify the use of some subset of them for a particular purpose)?

This is probably addressed by previous changes, i.e., via statements 
around the need for registered semantics. We don't think profiles to 
ensure alignment are fundamentally necessary, although EAT as a 
framework is conceptually similar to "digitial credentials" as a profile 
of JWT/CWT.

> 
> -- The intent is also to apply lessons learned from the development of W3C's 'Securing Verifiable Credentials using JOSE and COSE' specification.  What are those lessons learned? Could they be converted to design guidance described here?  Discussed at the BoF?

Added an itemized list of lessons learned in commit 61c488a.

> 
> ** Goals/Out-of-Scope Section
> 
> -- Per “The working group will NOT be limited to JSON-LD data models, but to the extent that JSON-LD is compatible with JWT regsitered claims and private claims, the W3C Verifiable Data Model remains supported, as described in https://www.w3.org/TR/vc-jose-cose”, there seems to be a lot of guidance here.  Could this be simplified?  My read is “When work is done in SPICE, JSON-LD won’t be used.  No attempt will be made for compatibility.  However, newly registered claims may have broader applicability”
> 
> -- Per “The working group will NOT address specific credential use cases, such as "personal credentials" or "software supply chain". Instead, the SPICE WG will reuse existing work or incorporate emerging work items produced by other IETF working groups, such as SCITT, OAUTH”, the first sentence is clear to me.  The second is not.  What does it mean to “reuse existing work” in the context of a discussion on use cases?

Made the Out-of-Scope Section more concise and moved SDO interaction to 
Goals in commit b37df94.

> 
> ** Motivating Use Case section
> 
> I struggled with the length and intent of this section.  What does inclusion here commit the IETF to doing?  Does the SPICE WG need to ensure its “output” satisfies each and everyone of these bullets despite the earlier text says the “WG will NOT address specific credential use cases …”?  Will future documents be declared as in-scope because they are needed by a community/technology/initiative/goal listed here?  I strongly recommend removing this section and replacing it with the design properties these use cases need and/or some shorter digest of them in the introduction.
> 
> As an aside, the IESG recently provided a similar message (of less use case text) on the VCON charter review.  See https://datatracker.ietf.org/doc/charter-ietf-vcon/ballot/.
> 
> This material was useful for the BoF request and might be reused during the IETF 118 BOF.

We removed motivating use case Section and added key design properties 
Section instead in commit dd279eb.

> 
> ** Motivating Factors for conducting this work at IETF
> 
> Please remove.  This was helpful in motivating the BoF request, but not in a charter.  Consider if coordination with the IRTF (is it CFRG?) is a specific goal.

We removed Motivating Factors and added CFRG to the first items of goals 
in commit 6253b71.

> 
> ** Work Items
> 
> -- As a general comment, unadopted individual drafts when used in charter text need strong caveats.  If they stay, they need language similar to “(draft-xxx may be used by the WG as a starting point)”.

We added a bit expositional text and reshuffled some content to key 
design properties in commit 6f02861.
Maybe we need to do more here?

> 
> -- It has a “TBD” in it, so I don’t mean to press, but “Identity Specification inspired by” needs clarity.

Work Items and Inspiring Input Documents Sections are cleaned up and 
reshuffled a bit, plus no more TBDs in commit be0d11f.

> 
> -- Per the OAuth document language, I’m not sure what do here beyond calling out that it is highly unusual in the SEC area for documents to move WGs after adoption.  On a technical level, I don’t entirely follow how the scope described here motivates the decisions of where those (and likely future) documents might land.  I would like to tease that out on the BoF.  I’m putting a marker down here that this text will need revision if this charter is to advance.  In such cases where something can be potentially done in two WGs, and WGs are being rechartered, the IESG typically says “have the conversation first and then modify the charter text.”  The closest we have is in the SUIT charter (https://datatracker.ietf.org/wg/suit/about/), “In addition, either the SUIT WG or the RATS WG will produce: A set of claims for attesting to firmware update status.”  In this case, there was no prior WG adoption of a document.

Lets discuss at the BoF. Or is there anything you would like to change 
explicitly, beforehand?

> 
> ** Milestones
> 
> -- There is a markdown formatting issue with linebreaks
> 
> -- The IESG has in recent charter reviews has been particular about wanting to see the intended status of the document (i.e., proposed standard vs. information) explicitly stated
> 
> -- There is no milestone for the “TBD identity specification”.  Whatever is listed in the work items, should have a corresponding milestone
> 
> --  Please add notional dates
> 
> ** Why IETF Section
> 
> Please remove.  This was helpful in motivating the BoF request, but not in a charter.
> 
> ** Relationship with W3C VCWG Section
> 
> Please remove.  Unless I missed something, the text currently reads like there won’t be much coordination and the IETF will be developing something different.

We cleaned up and improved the Milestone Section (,added some 
preliminary guesses on dates), and removed "Why IETF" & "Relationship 
with W3C VCWG" Section in commit 000bcf3.

> 
> Regards,
> Roman