Re: [SPICE] Revised Charter

[Denis <[e-mail]>]

Hi Orie,

More feedback on the proposed Charter :

The SPICE working group will:

          * Register claims that are in JWT in the CWT registry to
            enable digital credentials to transition from one security
            format to another.
          * Develop a framework and recommendations for deploying
            digital credentials based on JOSE and COSE.
          * Develop profiles of CWT/CWP, JWT/JWP (Digitial Credential
            Profiles) that enable the semantic interchangeability
            required by use cases, for example, the SPICE working group

The "registration of claims" should not be the first goal. It may 
however be useful in later step.
It is also important to notice that the registration of claims by IANA 
will be unnecessary when JSON-LD will be used.

The first goal should be :

    *Develop a framework and recommendations for deploying digital
    credentials* _*and digital presentations*_ (full point)

This Framework SHALL not be dependent upon the use of JOSE and COSE. As 
an example, there are good reasons to support one ASN.1/DER based protocol.

"Semantic interchangeability" should not be a goal. A claim defined in 
the IANA registry does not need to be semantically interchangeable with 
a claim defined by a URI.
Remove: "that enable the semantic interchangeability required by use 
cases, for example, the SPICE working group".

Denis

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