Re: [SPICE] Revised Charter

[Roman Danyliw <[e-mail]>]

Hi!

Thanks so much for this PR and the related discussion.  I have a bit more feedback:

(1) Editorially, this overall charter text is too long and includes things that I don’t believe help constrain the scope.  I wanted to be constructive with a proposal but I didn’t know how to best convey proposed editorial changes on a PR with an explanation.  I made a GDoc with track changes/suggestions, https://docs.google.com/document/d/1mmaB4Ll8jEpgmuoGNLwks51Set5yxLX7Cc3btq4q_9k/edit?usp=sharing.  If this is not usable, I can find a different way to pass along the changes.

A few motivating ideas include reducing the background and reducing the number of times parts of the architecture defined.  I also proposed the removal of all individual documents as I wasn’t sure how “related documents” helped narrow the scope.

(2) The “Goals” section includes a long list of “topics will be considered in the milestones”.  While I can see how these would be important properties of digital credentials, it wasn’t clear to me who they constrain the future solution.  For example:

-- What does "consider" mean? Using a dictionary definition, "consider" means the solution wouldn't have to deliver any of these properties.

-- Are these properties going to be provided by unique specifications produced by the WG?

-- These topics are described in a level of detail that would make it challenging to assess whether the property was realized.  For example,  "Confidentiality (ensuring information is protected from unauthorized access" is the textbook definition of confidentiality.  What is "unauthorized" in the context of the architecture framed above?  "Availability (efficiently information processing, minimizing data in flight ...", what's "efficient enough", how many bits "in flight" is too many or few?

I wonder if this list could be much shorter?  Perhaps some reduced set of properties can be woven in the text to describe the desired framework.

(3) Per the “Meta Discovery”:

-- As design guidance or constraining the solution space, the current text would benefit from refinement.  It doesn't commit to HTTP; or define or commit to supporting constrained device

--  Per the link draft-ietf-oauth-sd-jwt-vc, my superficial read of the abstract suggests that it is a “data format”.  Is that work that will be done here too?  I’m confused primarily because the current charter text talks about HTTP and device types but the OAuth document seems more concrete on the support token type, omits the protocol and device types

-- Per the “not limited to JSON”, what ecosystem does this text intend to support? Is it only the artifact described in the “selective disclosure of claims” program of work?

(4) Per the “Selective Disclosure of Claims”, I had trouble understanding what kind of solution is being described. Specifically, I wasn’t sure what underlying technologies were being built on.

-- JOSE/COSE was mentioned in the “Goals/In Scope” section.  Is that a dependency?

-- Is this deliverable defining new token format?  Augmenting the CWT claim registry?  Adding claims into the COSE registries?  CBOR tags?

-- The existing JOSE charter (https://datatracker.ietf.org/wg/jose/about/) already has in scope:

-- "Standards Track document(s) specifying representation(s) of JSON-based claims and/or proofs enabling selective disclosure of these claims and/or proofs, and that also aims to prevent the ability to correlate by different verifiers."
-- Standards Track document(s) defining CBOR-based representations corresponding to all the above, building upon the COSE and CWT specifications in the same way that the above build on JOSE and JWT.

In what way will this selective disclosure document be different from a JWP?

-- Is this work going to profile other/existing token formats to describe how to extend/augment them into being digital credentials?  Put into another way, is this working going to specify a new “envelope” for selective disclosure of claims (e.g., alternative to JWP), or is it going to profile/reuse an “envelope” (e.g., JWP) described elsewhere and provide guidance on how specific industries can add their own claims into it to construct digital credential?

(5) Editorial. In whatever way this program of work text is refined, that needs to be summarized back in the “Goals” section.

Regards,
Roman

From: Orie Steele <[e-mail]>
Sent: Friday, January 19, 2024 2:05 PM
To: Roman Danyliw <[e-mail]>
Cc: [e-mail]
Subject: Re: [SPICE] Revised Charter

Roman,

Thank you for your detailed comments.

I have raised this PR which I believe addresses all of them:

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

However, some of your comments are questions, which I feel it is better to answer on the list, in case no text change is needed to address them.

Inline for the rest:

On Thu, Jan 18, 2024 at 4:44 PM Roman Danyliw <[e-mail]<mailto:[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.

I have added some text to the introduction to address this.


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.

I added references to the existing registries, and highlighted that JWT claims focus on people, whereas many of the CWT claims focus on devices.

The background context for this is that we think that organizations other than the IETF, will likely need to describe claims, because a single global registry won't fit all of them... and would likely overwhelm the designated experts who might not be able to evaluate if a new claim in needed for every element in the periodic table, or for every organic chemistry molecule, or for claims specific to a regional government.


-- “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.

Thanks, I have clarified that IRTF has research groups.


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.

I have added citations.


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?

I clarified how we think SPICE will consume work from CRFG, and how we might provide comments on use cases, for example:

A use case for BBS Blind Signatures is privacy preserving credentials, such as proving that a human passed a captcha previously and should not be challenged again, like is done with privacy pass.


** 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?)

Yes, these are essentially topics we think the architecture will address, and that SOME credential formats can support.

There has been a lot of discussion about limiting credential formats to just the ones that can do all of these (SPICE will only work on BBS verifier-verifier unlinkable hardware isolated TEE credentials), but that position does not have consensus in my opinion.


-- 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.

I hope I have addressed this.


** 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.

Done.


** 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?

An example of an existing digital credential could be the identity credential based on SD-JWT or ISO mDoc described here:

- https://github.com/WICG/identity-credential

If SPICE develops SD-CWT, we would hope that it was influenced by the work that it is attempting to improve on.

However, unlike WIMSE, we are not trying to make a credential that is "only for workloads" or "only for people".

As an analogy, WIMSE credentials being "only for workloads" are inspired by attempts to use "JWT and DPoP" which are similarly an "existing credential use case".


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?

I removed direct references to other organizations, which I imagine might raise new objections however I will counter with this argument:

Unless you are an active member of those organizations, and those organizations are building digital credentials, and you are contributing to both groups, I don't see a lot of value in calling out that the organizations exist.

I think Manu Fontaine has been most vocal on the desire to reference TCG and CCC, but I don't understand how he plans to coordinate SPICE related deliverables (as described in the charter) with those groups, so I will let him argue to add this back : )

Similarly Denis has mentioned ISO, I am not aware of anyone who is actively contributing to the ISO work on mDoc / mobile drivers licenses / covid vaccinations that is also planning to contribute to SPICE, but I think they are welcome to contribute regardless of if ISO is mentioned directly by name.


** 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”).

I removed this, it's been a recurring point of contention. Some folks feel that TEE is essential, others don't. I don't see the sentence adding any value to the charter, and I do see it continuing to cause confusion.

I did move some references to it to the "design considerations" of the digital credentials section.

-- 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?

I think so.

Perhaps that is the lesson learned?

Much of the charter debate has reinforced this point.

It is easy to talk about the "philosophical value" of digital credentials, or even "desirable privacy properties", without discussing how to build anything that can be implemented.

I would say that this will remain the primary risk of the architecture deliverable.


** 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?)

Short answer is we don't know.

It seems very likely that HTTP will be a component, but we don't want to preclude other transports such as QR Codes, NFC, Bluetooth, etc...

The point of this document is not to address all of these, but to provide a concrete way to discover the optionality that exists in the wild today.

I added some related drafts that we have worked on trying to characterize this challenge.

-- 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?

Yes, I added some references, and extra text to try to make this clearer.


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

I think it's mostly just repeating the design properties, I think the new text addresses this.


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.

At this point, we don't seem to be able to agree to pick just one, but there does seem to be consensus to pull the useful digital credential parts from each, and harmonize them.

As an example, SCITT built "receipts" which SD-JWT does not support, OAuth built SD-JWT which COSE does not support, so SCITT cannot use it.

Both rely on the `iss` , `sub` and `cnf` claims, which are supported in JOSE and COSE, and are essential to the "3 roles", issuer (AS), holder (client) (of credentials, maker of presentations) and verifier (RP)...

Another example would be how JWT supported claims in headers, but CWT did not until recently, and when that feature was added, we learned that kccs had already ported part of it... for those who want the details:

- https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/22/
- https://datatracker.ietf.org/doc/draft-ietf-cose-cwt-claims-in-headers/10/

in https://www.iana.org/assignments/cose/cose.xhtml#header-parameters

The claims disclosure document, will address this kind of challenge, when deploying credentials based on CWT and JWT, in a similar way to how EAT attempted to address this in:

https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-25#name-the-claims

Hopefully these comments are helpful, if you like I can merge the PR or I can leave it open and make adjustments in case you have further comments.

Regards,

OS


Roman

From: Orie Steele <[e-mail]>
Sent: Thursday, January 18, 2024 1:19 PM
To: [e-mail]<mailto:[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/>


--



ORIE STEELE
Chief Technology Officer
www.transmute.industries

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