Re: [SPICE] Revised Charter

[Michael Prorock <[e-mail]>]

Thanks Roman,
That google doc is extremely helpful.

Orie (and list) I will take a stab at a PR that reflects this feedback.

Mike Prorock
CTO, Founder
https://mesur.io/



On Tue, Feb 6, 2024 at 11:52 AM Roman Danyliw <[e-mail]> wrote:

> 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]> 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]
> *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
>
> [image: Image removed by sender.] <https://transmute.industries/>
> --
> SPICE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spice
>