Re: [SPICE] Revised Charter

[Denis <[e-mail]>]

Hi everybody,

1) The following text which is currently placed in the background 
section should be moved in the Introduction section
to first stabilize the vocabulary:

    W3C has introduced a 'Three Role Model' in the 'Verifiable
    Credentials Data Model v2.0' specification.
      VCDM 2.0 (https://w3c.github.io/vc-data-model) with the following
    roles: a holder, an issuer and a verifier.
    The wording "Verifiable Credential" (VC) is used in VCDM 2.0. It
    implies the use of data serialization using JSON-LD.
    The wording "Verifiable Presentation" (VP) is used in VCDM 2.0. It
    implies the use of data serialization using JSON-LD.
    In this charter, the VC concept is captured using the wording
    "digital credential", while the VP concept is captured
    using the wording "digital presentation".

2) As an example, this will allow to correct the following sentence:

    When received by an entity, a proof of the digital credential needs
    to be provided and verified, so that only the legitimate controller
    of the digital credential can take an advantage of its possession.

and change it into:

    When received by an entity, a digital presentation needs to be
    provided and verified, so that only the legitimate controller of the
    digital credential can take an advantage of its possession.

3) The two most important sentences placed in the second paragraph of 
the charter are the following:

    A digital credential expresses claims or attributes about a subject,
    such as their name or age,
    made my an authority known as an issuer, such as a government agency.

    The term "holder" is used to describe an entity (person, device,
    organization, or software agent)
    that controls disclosure of credentials.

These two quoted sentences are not crystal clear. The key question is 
whether an holder means an individual
who possesses one or more digital credential or an application used by 
the individual to acquire digital credentials
from an issuer and to present digital presentations to verifiers.

In the "three roles model", is the holder a subject or an application 
used by the subject ?

  It is important to start with good foundations. Unfortunately, two 
important specifications are not aligned:

     a) In https://www.w3.org/TR/vc-data-model-2.0/#dfn-holders

    A role an entity
    <https://www.w3.org/TR/vc-data-model-2.0/#dfn-entities> might
    perform by possessing one or more verifiable credentials
    <https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential>
    and generating verifiable presentations
    <https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-presentation>
    from them.
    A holder is often, but not always, a subject
    <https://www.w3.org/TR/vc-data-model-2.0/#dfn-subjects> of the
    verifiable credentials
    <https://www.w3.org/TR/vc-data-model-2.0/#dfn-verifiable-credential>
    they are holding.

     b) In https://hyperledger.github.io/anoncreds-spec/#term:holders

    the holder is a software component (agent) used by an entity
    (person, organization, etc.) in possession of credentials
    <https://hyperledger.github.io/anoncreds-spec/#term:credentials>
    issued to them.
    Where “holder” is used in the specification we mean the software
    component.

     c) In https://hyperledger.github.io/anoncreds-spec/#term:subject

    A subject, also known as an identity subject, is the entity about
    whom the claims
    <https://hyperledger.github.io/anoncreds-spec/#term:claims> in a
    credential are asserted.
    In AnonCreds, the credential subject is not formally defined in
    credential
    <https://hyperledger.github.io/anoncreds-spec/#term:credential>.
    Rather, the issuance of a credential
    <https://hyperledger.github.io/anoncreds-spec/#term:credential>
    is always to a specific holder
    <https://hyperledger.github.io/anoncreds-spec/#term:holder>. The
    semantics of the credential defines the relationship between the
    holder <https://hyperledger.github.io/anoncreds-spec/#term:holder> and
    the subject, with the holder
    <https://hyperledger.github.io/anoncreds-spec/#term:holder>
    frequently being the subject.

My proposal is to replace these two quoted sentences by the following:

    The term "subject" is used to describe an entity, e.g. an individual
    or a professional, about whom claims,
    such as their name or age,in a digital credential are asserted.

    The term "holder" is used to describe asoftware agentrunning on some
    hardware or device placed
    under the control of a subject that manages (a) digital credential
    requests to an issuer and
    (b) presentations of presentation credentials to a verifier.

4) The charter could be shortened by removing the first sentence of the 
introduction:

    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.

It does not add anything useful. What is "transparency" ? What are 
"certificates of origin" ? Why are they related to credentials ?

5) In the "In-scope" section:

    The SPICE working group will develop a framework and recommendations
    for deploying digital credentials
    based on JOSE and COSE.

Comments have been sent on the mailing list to support ASN.1/DER for 
requesting a digital credential to an issuer,
hence JOSE and COSE might not be the only two syntaxes.

Remove "based on JOSE and COSE" and hence change into:

    The SPICE working group will develop a framework and recommendations
    for deploying digital credentials.

6) The background section includes:

    For example (...) the CWT registry has claims regarding devices,
    such as "Software Measurement Results",
    and "Certifications received as Digital Letters of Approval".

These claims are unrelated to subjects like human beings. Remove this 
part of the sentence.

7) The two following sentences are not bad in themselves but have 
nothing to do in a Backgroundsection:

    The SPICE WG intends to consume cryptographic systems produced by
    CFRG, similar to how those schemes are consumed in JOSE and COSE.
    The SPICE WG will not develop novel cryptographic schemes, but might
    provide comments on use cases for schemes under development in CFRG.

8) Correct this typo: the essential communciation patterns

9) The following sentence should be removed:

    The architecture will not define new key formats, credential
    formats, or protocols,
    but it will express how their evolution can support digital
    credential improvements over time.

As an example, a protocol supporting ASN.1/DER to request a digital 
credential to an issuer will need to be defined.
Digital credential formats and digital presentation formats for 
supporting BBS+ will also need to be defined.

10) The seven "Related Drafts" have never been discussed, nor agreed. 
They should not be included in the charter.

11) Typo: (Trusted Execution Environments))

Denis

> Hey Roman,
>
> We merged this PR on the informal call today:
>
> https://github.com/transmute-industries/ietf-spice-charter/pull/22
>
> The group believes we have addressed all feedback that is necessary to 
> address for the current charter.
>
> Regards,
>
> OS
>
> 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.
>
>     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.
>
>     -- “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.
>
>     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.
>
>     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?
>
>     ** 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?)
>
>     -- 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.
>
>     ** 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.
>
>     ** 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?
>
>     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?
>
>     ** 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”).
>
>     -- 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?  Perhaps that is the lesson learned?
>
>     ** 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?)
>
>     -- 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?
>
>     o What is the relationship between the “security” and
>     “privacy-friendly” properties and the more detailed key design
>     properties?
>
>     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.
>
>     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 STEELEChief Technology Officerwww.transmute.industries
>
> <https://transmute.industries>
>
>