Re: [SPICE] Call for consensus on SPICE charter

[Orie Steele <[e-mail]>]

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