Re: [SPICE] Revised Charter

[Denis <[e-mail]>]

Hi  Orie,

A quick feedback:

    "holder", an entity (person, device, organization, or software
    agent) that controls the disclosure of credentials.

A "Holder" is NOT a "person, device, organization": it is 
an*application* *running in a* *trusted environment *
(able to securely store and appropriately use cryptographic keys).

A person or an organization is unable to store (i.e. remember) and use 
the cryptographic keys
(i.e. because a brain is not capable to perform the necessary 
mathematical computations).

The same consideration applies for both an Issuer and a Verifier.

However, a Holder (application) is usually under the control of a person 
or of an organization.

In order to build a secure system, the Holder (application) MUST support 
some specific characteristics,
that MUST be verified by the Issuer, before the issuance of a digital 
credential.

_Remainder_: The fist sentence is still useless and should be removed:

    Digital credentials are essential to identity, authorization,
    licenses, certificates and *digitization use cases*
    that are part of modernization efforts targeting *efficiency*, and
    *transparency*, such as digital licenses or *certificates of origin*.


Denis

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