Re: [SPICE] Call for consensus on SPICE charter

[Manu Fontaine <[e-mail]>]

Denis, I understand this, and I already said we don't want to "block"
anything. We just won't be able to contribute if something in the charter
blocks future discussions of our approach.

My understanding from my call with Hannes was that the charter was just the
beginning of the work, so we hope to keep the door open.

Our perspective is that web-based credentials inherit the (poor) security
properties of the domain-centric web, which is why we pursued a new
entity-centric model (hence the IETF and not the W3C).

We have a blueprint, a first version that works (with stunning security
properties), and we're interested in sharing more and collaborating in the
coming months. It's unfortunate that our timing does not align better, but
it's dictated by actual work by a small team. We can't rush it.

M

On Mon, Mar 11, 2024, 6:35 PM Denis <[e-mail]> wrote:

> 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]>
> <[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]>
>>> <[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]> <[e-mail]>
>>>>> *Gesendet:* Montag, 11. März 2024 16:19
>>>>> *An:* Tschofenig, Hannes (T CST SEA-DE)
>>>>> <[e-mail]> <[e-mail]>;
>>>>> Roman Danyliw <[e-mail]> <[e-mail]>
>>>>> *Cc:* [e-mail]; Christopher Allen
>>>>> <[e-mail]>
>>>>> <[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) .
>>>>>
>>>>>
>>>>>
>>>>>    1. 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
>>>>>
>>>>>
>>>>>    1. Putting the “s” to protocol is also a minor change that I have
>>>>>    no problems with.
>>>>>    2. 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]> <[e-mail]> *Im
>>>>> Auftrag von *Denis
>>>>> *Gesendet:* Sonntag, 10. März 2024 10:23
>>>>> *An:* Christopher Allen <[e-mail]>
>>>>> <[e-mail]>; Roman Danyliw <[e-mail]>
>>>>> <[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
>>>>>
>>>>>
>>>>>
>>>>> 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 STEELE Chief Technology Officer www.transmute.industries
>>>>
>>>> <https://transmute.industries>
>>>> --
>>>> SPICE mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/spice
>>>>
>>>
>>
>> --
>>
>>
>> ORIE STEELE Chief Technology Officer www.transmute.industries
>>
>> <https://transmute.industries>
>>
>
>