Re: [SPICE] Revised Charter

[Michael Prorock <[e-mail]>]

I have pulled those suggestions into a PR here:
https://github.com/transmute-industries/ietf-spice-charter/pull/23

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



On Tue, Feb 6, 2024 at 12:20 PM Michael Prorock <[e-mail]> wrote:

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