Ballot for charter-ietf-spice
Block
Yes
No Objection
No Record
Summary: Has 2 BLOCKs. Has enough positions to pass once BLOCK positions are resolved.
Ballot question: "Is this charter ready for external review?"
I support Roman's BLOCK. In addition, > Milestones This is the same issue as in the concurrent RADEXT recharter. The Program of Work now contains three distinct deliverables (Architecture, SD-CWT, Metadata & Capability Discovery), each of which should have associated target dates. A recharter without milestones is not ready for external review.
"SPICE", paragraph 2 > The SPICE WG will develop digital credential profiles that support various use > cases. Requirements for proposed standards in the program of work will be > established in coordination with the aforementioned working groups. The > profiles developed by the SPICE WG will enable digital credentials to leverage > existing IETF technologies. The phrasing "Requirements for proposed standards in the program of work will be established in coordination with the aforementioned working groups" is unusual. IETF WGs establish their own requirements through WG consensus; other WGs provide review and input but do not jointly establish requirements. The intent (coordinate closely) is correct; the expression is not. Consider: "Requirements for proposed standards will be developed with input from and in coordination with related WGs, including OAuth, JOSE, COSE, RATS, and SCITT." "SPICE", paragraph 1 > - General Key discovery is out of scope for this WG. There are several > mechanisms for distributing or discovering key material (e.g., > https://openid.net/specs/openid-connect-discovery-1_0.html). Embedding a live URL from an external organization into a charter is unusual and problematic — URLs can become stale, resources can move or disappear, and this reference has no stable identifier (no RFC number, no SDO document number). If the intent is to illustrate existing mechanisms, reference an RFC (e.g., RFC 8414 for OAuth Server Metadata, or RFC 5785 for well-known URIs) rather than a vendor/SDO URL. Alternatively, simply state that key discovery mechanisms are out of scope without listing examples.
The SPICE WG will define a limited number of widely-applicable claims for credentials that extend beyond the set defined in core specifications that will facilitate deployments of SPICE use cases, including any encodings necessary to represent those claims in a JWT or CWT. -- What is the link between this text and the program of work? -- What are the SPICE use case that need claims that aren’t covered by the “core specifications”? Doesn’t the text “The SPICE WG will develop digital credential profiles that support various use cases” shape the workflow to be to identify the use case and then create the profile for it? Given the that there are no “core specifications” done, what’s the residual gap being filled? -- Is this new charter text to make the already adopted, in WG-last call document, draft-ietf-spice-oidc-cwt in scope (not the responsible AD, but my read is that it is)? -- If that isn’t the workflow, doesn’t this new scoping text allow the WG to define arbitrary claims relevant to JWT and CWT if they are related to digital credentials? Can this be narrowed a bit?
** Thanks for the work on this charter. I appreciate that I triggered charter discussion with my ballot on https://datatracker.ietf.org/doc/draft-ietf-spice-glue-id/ballot/#draft-ietf-spice-glue-id_roman-danyliw. If this -01-00 version was intended to address that feedback, a bit more polish is needed. Irrespective of my BLOCK feedback on the wide scope, it isn’t clear to me how establishing a URN namespace translates to “widely applicable claims”. If this text isn’t intended to address that DISCUSS, please ignore. ** Per “… on digital credentials will be developed in coordination with relevant IETF WGs (e.g., TEEP)”, please find a new reference as TEEP has been closed.
Section Goal, para 4: Suggest changing 'core specifications' to 'existing cryptographic primitives' (this will tie it back to para 2. Section Goal, ref to TEEP: Merely removing the parenthetical is my suggestion. Program of work: Obviously these can easily be turned into milestones.
Thanks for the rechartering work and for being specific on the intended publication status of the work items. Some comments though: - introduce the WG acronym - introduce the expansion of SPICE in the charter - unsure what ` emerging IETF technologies` mean ? Current draft(s) ? It is rather vague ;-) Suggest using only 'IETF technologies' without any 'existing' or 'emerging' - what does 'inspire' means in `SPICE will be inspired by the conceptual data model of the W3C VC` ?