Re: [SPICE] Revised Charter

[Orie Steele <[e-mail]>]

Roman,

Henk, Mike and Orie have addressed your feedback, the current charter,
reflecting our changes based on your feedback can be found here:

https://github.com/transmute-industries/ietf-spice-charter/blob/main/charter.md

We think the charter is ready for community review, but less us know if you
have further changes to suggest.

Regards,

OS


On Wed, Feb 7, 2024 at 8:34 AM Michael Prorock <[e-mail]> wrote:

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

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>