Re: [SPICE] Revised Charter

[Orie Steele <[e-mail]>]

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

<https://transmute.industries>