Re: [SPICE] Call for consensus on SPICE charter

[Denis <[e-mail]>]

Hi Manu,

I guess that the definition of digital credentials you have in mind is 
rather different from the concept of "digital credentials" most people 
participating
to the SPICE BoF are willing to  develop.

It is not because a new WG might be created that it should be chartered 
along "confidential computing software agents", "with no privileged 
human insider at all" or "universal zero trust".
Up to now, "Dedicated agents to bridge them [i.e. digital credentials]" 
have not been pushed/presented/explained on the SPICE BoF mailing list.

Privacy is a concern for human-beings (i.e., not for "confidential 
computing software agents") and is one of the major concerns in the 
charter.

At the moment, the question is whether the time-slot reserved for the 
SPICE BoF at the Brisbane meeting will be the last BoF meeting or a 
first WG meeting.
Such decision might be taken by the SEC AD before the Brisbane meeting.

If you want to propose changes to the text of the charter, you need to 
propose precise text replacements (using OLD and NEW) or precise text 
additions .
Discussions in Brisbane about the text of the charter might be too late.

Denis

> Orie, let's discuss in Brisbane.
>
> If you remember from our previous (brief) discussions, we leverage 
> confidential computing software agents that exist independently of the 
> domain-centric model of the web (hence our interest in contributing at 
> the IETF). These agents act exclusively on behalf of the entities they 
> represent, with no privileged human insider at all, which is critical 
> for "universal" zero trust. They generate their own entity keychains 
> and encrypted information spaces, and exchange keys and 
> pairwise-encrypted CBOR messages/data without relying on HTTP or 
> asymmetric signatures (better performance and quantum resistance). 
> Hence our interest in CBOR-based internet credentials for any type of 
> entity.
>
> It's not that we "do not agree" with the current state of digital 
> credentials. Confidential computing is relatively new tech, and 
> current standards did not did not take (full) advantage of it. We plan 
> to support existing deployments by creating dedicated agents to bridge 
> them. We intend to share more as our work progresses.
>
> Manu
>
>
> On Mon, Mar 11, 2024 at 2:13 PM Orie Steele 
> <[e-mail]> wrote:
>
>     Manu,
>
>     I am confused by your comments.
>
>     If your work is not compatible with JOSE, COSE and HTTP.... aren't
>     you implicitly saying your work is dedicated to "new transports
>     and serializations" ?
>
>     From what I can see, this draft:
>     https://datatracker.ietf.org/doc/draft-bastian-jose-alg-ecdh-mac/
>
>     Works for some confidential compute credential use cases, and
>     JOSE, COSE and HTTP.
>
>     Happy to discuss in your upcoming side meeting at IETF 119.
>
>     If your proposal is that JOSE and COSE and HTTP are not good
>     building blocks for digital credentials...
>     You probably don't agree with the adoption trajectory of
>     digital credentials as they are being rolled out today.
>
>     ISO mDoc is based on COSE.
>     JWT/SD-JWT based W3C VCs are based on JOSE.
>     OpenID for VC and VP use HTTP, JOSE and COSE.
>
>     We got feedback on the use of HTTP for credential metadata
>     discovery from the OAUTH WG : )
>
>     The fact that the identity / key distribution layer is often
>     omitted from these has to do with support for existing systems,
>     that means not assuming "DIDs" or "a special flavor of x509".
>
>     The reason we narrowed to these technologies was to try to ensure
>     that the IETF WG would deliver something useful and relevant to
>     how digital credentials are being adopted.
>
>     TLDR; I don't think we need to make further adjustments to the
>     charter, and if folks want to debate approaches to milestones, I
>     am happy to do that in another thread.
>
>     OS
>
>     On Mon, Mar 11, 2024 at 12:37 PM Manu Fontaine <[e-mail]>
>     wrote:
>
>         I agree we should not create new transports or serializations,
>         but limiting to HTTP, JOSE/COSE would put our work out of scope.
>
>         If including them in the charter means that we won't discuss
>         other approaches once the WG is created, then we cannot
>         support the WG (as we won't be able to contribute).
>
>         In our case, the fact that we didn't put together a draft yet
>         is not that there wasn't enough time, but that we didn't have
>         enough bandwidth at our stage.
>
>         Manu
>
>         On Mon, Mar 11, 2024 at 1:06 PM Orie Steele
>         <[e-mail]> wrote:
>
>             I could live with those removals, assuming we don't end up
>             creating new transports or credential serializations.
>
>             I think it is a mistake to widen the scoping beyond
>             JOSE/COSE and HTTP.... We've not seen any drafts that have
>             discussed this.
>
>             If folks wanted to do that work, they have had plenty of
>             time to put together a draft... That could have influenced
>             milestones in the charter.
>
>             That said, we have discussed CTAP and Bluetooth APIs, are
>             they now in scope?
>
>             OS
>
>
>
>
>             On Mon, Mar 11, 2024 at 11:48 AM Denis
>             <[e-mail]> wrote:
>
>                 Hannes,
>
>                 As already stated, the deletion of the three terms
>                 would be fine with me.
>
>                 Considering the "laundry list", this list could be cut
>                 into two pieces:
>
>                 First piece:
>
>                     for JWT, CWT, SD-JWT, SD-CWT, CWP and JWP
>
>                 Second piece:
>
>                     using HTTPS/CoAP for CBOR-based digital credentials
>
>                 I propose to keep the first piece while removing the
>                 second piece.
>
>                 Henk and Michael, would you be able to confirm that
>                 you could "live with that removal" ?
>
>                 Denis
>
>
>>                 Denis, Roman,
>>
>>                 I do not think we need to define the terms in the
>>                 charter. The reason is the following: (a) limited
>>                 space, (b) we have dedicated documents to do so, and
>>                 (c) we need more time to discuss and agree on the terms.
>>
>>                 So, it is fine for me to remove the terms from the
>>                 charter text, which also makes it shorter.
>>
>>                 Ciao
>>
>>                 Hannes
>>
>>                 *Von:*Denis <[e-mail]>
>>                 <mailto:[e-mail]>
>>                 *Gesendet:* Montag, 11. März 2024 16:19
>>                 *An:* Tschofenig, Hannes (T CST SEA-DE)
>>                 <[e-mail]>
>>                 <mailto:[e-mail]>; Roman Danyliw
>>                 <[e-mail]> <mailto:[e-mail]>
>>                 *Cc:* [e-mail]; Christopher Allen
>>                 <[e-mail]>
>>                 <mailto:[e-mail]>
>>                 *Betreff:* Re: AW: [SPICE] Call for consensus on
>>                 SPICE charter
>>
>>                 Hannes,
>>
>>                     @font-face {font-family:Wingdings; panose-1:5 0 0
>>                     0 0 0 0 0 0 0;}@font-face {font-family:"Cambria
>>                     Math"; panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
>>                     {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2
>>                     4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
>>                     {margin:0cm; font-size:11.0pt;
>>                     font-family:"Calibri",sans-serif;}a:link,
>>                     span.MsoHyperlink {mso-style-priority:99;
>>                     color:blue;
>>                     text-decoration:underline;}p.MsoListParagraph,
>>                     li.MsoListParagraph, div.MsoListParagraph
>>                     {mso-style-priority:34; margin-top:0cm;
>>                     margin-right:0cm; margin-bottom:0cm;
>>                     margin-left:36.0pt; font-size:11.0pt;
>>                     font-family:"Calibri",sans-serif;}span.E-MailFormatvorlage20
>>                     {mso-style-type:personal-compose;
>>                     font-family:"Calibri",sans-serif;
>>                     color:windowtext;}.MsoChpDefault
>>                     {mso-style-type:export-only; font-size:10.0pt;
>>                     mso-ligatures:none;}div.WordSection1
>>                     {page:WordSection1;}ol {margin-bottom:0cm;}ul
>>                     {margin-bottom:0cm;}
>>
>>                     Hi Roman, Hi all,
>>
>>                      I had a chat with Denis about the three main
>>                     comments from below.
>>
>>                      In essence,
>>
>>                      1. On the terminology for
>>                         issuer/holder/verifier, Denis is fine to
>>                         leave the charter text as is since we will be
>>                         discussing and defining terminology in a
>>                         yet-to-be formed working group. The
>>                         terminology would most likely be part of an
>>                         architecture document.
>>
>>                 There is a misunderstanding here. Either we define in
>>                 the charter the three terms :"issuer" , "holder " and
>>                 "verifier" in a proper way, or we don't.
>>
>>                 If we define these three terms (which would be my
>>                 preference), I made a replacement proposal, since IMO
>>                 the current wording is incorrect
>>
>>                 If we don't define these three terms, this means the
>>                 removal of the current three bullets (and *I can live
>>                 with that removal *since this wording
>>                 will be defined in the Architecture document) .
>>
>>                      2. We both agree that the removal of the laundry
>>                         list of technologies is useful.
>>
>>                 i.e. for JWT, CWT, SD-JWT, SD-CWT, CWP and JWP using
>>                 HTTPS/CoAP for CBOR-based digital credentials
>>
>>                      3. Putting the “s” to protocol is also a minor
>>                         change that I have no problems with.
>>                      4. We both also agree that replacing
>>                         “confidentiality” with “security by design”
>>                         is a useful change to the text. What the
>>                         precise implications for protocol work are,
>>                         will be subject to the discussion in the
>>                         group anyway.
>>
>>                      If others can agree with these changes, I
>>                     believe we are done with the fine-tuning of the
>>                     charter text for SPICE. I would like to get
>>                     started with the real work!
>>
>>                 Denis
>>
>>                 PS. I would like a WG to be formed, but on stable
>>                 foundations.
>>
>>                     Ciao
>>
>>                     Hannes
>>
>>                     *Von:*SPICE <[e-mail]>
>>                     <mailto:[e-mail]> *Im Auftrag von
>>                     *Denis
>>                     *Gesendet:* Sonntag, 10. März 2024 10:23
>>                     *An:* Christopher Allen
>>                     <[e-mail]>
>>                     <mailto:[e-mail]>; Roman
>>                     Danyliw <[e-mail]> <mailto:[e-mail]>
>>                     *Cc:* [e-mail]
>>                     *Betreff:* Re: [SPICE] Call for consensus on
>>                     SPICE charter
>>
>>                     Roman,
>>
>>                     Thank you for your efforts to reshape the content
>>                     of the charter.
>>
>>                     However, I still have three concerns:
>>
>>                     *1)* No change has been done to these three bullets:
>>
>>                      1. An "issuer", an entity (person, device,
>>                         organization, or software agent) that
>>                         constructs and secures digital credentials.
>>                      2. A "holder", an entity (person, device,
>>                         organization, or software agent) that
>>                         controls the disclosure of credentials.
>>                      3. A "verifier", an entity (person, device,
>>                         organization, or software agent) that
>>                         verifies and validates secured digital
>>                         credentials.
>>
>>                     I propose the following changes:
>>
>>                      1. An "issuer", an application running under the
>>                         control of an organization that issues
>>                         digital credentials to its subscribers and
>>                         takes care of their validity status.
>>                      2. A "holder", an application used by a person
>>                         that requests digital credentials to one or
>>                         more issuers, store them and builds from them
>>                         digital presentations
>>                         that are then communicated to a verifier.
>>                      3. A "verifier", an application running under
>>                         the control of an organization that verifies
>>                         digital presentations received from a holder.
>>
>>
>>                     *2)* No change has been done to the last bullet
>>                     of the program of work.
>>
>>                      1. A proposed standard Metadata & Capability
>>                         Discovery protocol for JWT, CWT, SD-JWT,
>>                         SD-CWT, CWP and JWP using HTTPS/CoAP for
>>                         CBOR-based digital credentials
>>                         to enable the 3 roles (issuers, holders and
>>                         verifiers) to discover supported
>>                         capabilities, protocols and formats for keys,
>>                         claims, credential types and proofs.
>>
>>                     I propose to remove: "for JWT, CWT, SD-JWT,
>>                     SD-CWT, CWP and JWP using HTTPS/CoAP for
>>                     CBOR-based digital credentials " and to add an
>>                     "s" to "protocol"
>>
>>                     This would lead to the following shorter and
>>                     simpler sentence:
>>
>>                      1. A proposed standard *_for_* Metadata &
>>                         Capability Discovery protocol*_s_* to enable
>>                         the 3 roles (issuers, holders and verifiers)
>>                         to discover supported capabilities,
>>                         protocols and formats for keys, claims,
>>                         credential types and proofs.
>>
>>
>>                     *3)* Confidentiality is still present in the
>>                     following sentence:
>>
>>                              Privacy by design, *confidentiality*,
>>                     and consent will be considered, and guidance will
>>                     be given for each proposed standards in the
>>                     program of work.
>>
>>                     I propose the following change:
>>
>>                              Privacy by design, *security by design*,
>>                     and consent will be considered, and guidance will
>>                     be given for each proposed standards in the
>>                     program of work.
>>
>>                     4) A response to Christopher Allen who wrote:
>>
>>                              IMHO, throwing in words "security by
>>                     design", "privacy by design" is worthless, as
>>                     there is no real meaning or detail behind them.
>>
>>                     The wording "privacy by design" has been defined
>>                     by ISO last year:
>>
>>                     *privacy by design
>>                     *design methodologies in which *privacy is
>>                     considered and integrated into the initial design
>>                     stage and throughout the complete lifecycle of
>>                     products*,
>>                     *processes or services* (3.3) that involve
>>                     processing of personally identifiable information
>>                     (3.2), including product retirement (3.15) and
>>                     the eventual deletion (3.26)
>>                            of any associated personally identifiable
>>                     information (3.2)
>>
>>                            Note 1 to entry: The lifecycle also
>>                     includes changes or updates.
>>
>>                            ISO 31700-1:2023, 3.5
>>
>>                     The title of ISO 31700-1:2023 is : Consumer
>>                     protection — Privacy by design for consumer goods
>>                     and services — Part 1: High-level requirements
>>                     https://www.iso.org/obp/ui/#iso:std:iso:31700:-1:ed-1:v1:en
>>
>>                     The introduction of it mentions:
>>
>>                              “Privacy by Design” [(PbD)] was
>>                     originally used by the Information and Privacy
>>                     Commissioner of Ontario, Canada. [Dr. Ann Cavoukian]
>>                              with the goal that the individual need
>>                     not bear the burden of striving for protection
>>                     when using a consumer product.
>>
>>                               Privacy by design refers to several
>>                     methodologies for product, process, *system*,
>>                     software and service development ...
>>
>>                     The "Seven Foundational Principles of Privacy by
>>                     Design", as originally described by Dr. Ann
>>                     Cavoukian in the 1990's are important.
>>                     More information is available
>>                     here:https://hillnotes.ca/2021/12/09/privacy-by-design-origin-and-purpose/
>>
>>                     I agree with Christopher that RFC 6973 and RFC
>>                     8280 are not perfect; however, it would not hurt
>>                     to mention them ... whereas they are not essential.
>>
>>                     Denis
>>
>>                         On Fri, Mar 8, 2024 at 7:38 PM Roman Danyliw
>>                         <[e-mail]> wrote:
>>
>>                             Thanks for all of the additional feedback
>>                             on 00-01 charter.  I’ve published a new
>>                             version 00-02 to address some of the
>>                             feedback.
>>
>>                              Version 00-02
>>
>>                             https://datatracker.ietf.org/doc/charter-ietf-spice/00-02/
>>
>>                             Diff between 00-01 and 00-02
>>
>>                             https://author-tools.ietf.org/iddiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spice%2Fwithmilestones-00-01.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spice%2Fwithmilestones-00-02.txt&difftype=--html
>>                             <https://author-tools.ietf.org/iddiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spice%2Fwithmilestones-00-01.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-spice%2Fwithmilestones-00-02.txt&difftype=--html>
>>
>>                         I block if there are not specific mentions of
>>                         support for these two RFCs, ideally in
>>                         the Goals section.
>>
>>                         On Tue, Mar 5, 2024 at 10:09 AM Christopher
>>                         Allen <[e-mail]> wrote:
>>
>>                             On Mon, Mar 4, 2024 at 3:45 PM Roman
>>                             Danyliw <[e-mail]> wrote:
>>
>>                                 You previously raise concerned with
>>                                 the some part of the charter text. 
>>                                 It would be helpful if you could
>>                                 review the 00-01 and indicate if your
>>                                 initial concerns were addressed or not.
>>
>>                         …
>>
>>                                 * I'd like to see explicitly in the
>>                                 Information Architecture work
>>                                 that there will be a review of RFC
>>                                 6973: Privacy Considerations for
>>                                 Internet Protocols and RFC 8280:
>>                                 Research into Human Rights Protocol
>>                                 Considerations against that
>>                                 architecture. *I WILL BLOCK* if
>>                                 review and attempts to meet the goals
>>                                 of those RFCs are not included at
>>                                 least in the Program of Work
>>                                 Information Architecture item of
>>                                 charter *(though I'd prefer to see
>>                                 these RFCs also be more explicitly
>>                                 listed in the Goals section).*
>>
>>                         IMHO, throwing in words "security by design",
>>                         "privacy by design" is worthless, as there is
>>                         no real meaning or detail behind them. These
>>                         two RFCs are not perfect, but at least they
>>                         more fully articulate the requirements.
>>
>>                          -- Chirstopher Allen
>>
>>
>>
>>
>
>                 -- 
>                 SPICE mailing list
>                 [e-mail]
>                 https://www.ietf.org/mailman/listinfo/spice
>
>
>
>             -- 
>
>
>             ORIE STEELEChief Technology Officerwww.transmute.industries
>
>             <https://transmute.industries>
>
>             -- 
>             SPICE mailing list
>             [e-mail]
>             https://www.ietf.org/mailman/listinfo/spice
>
>
>
>     -- 
>
>
>     ORIE STEELEChief Technology Officerwww.transmute.industries
>
>     <https://transmute.industries>
>