Re: [SCITT] Draft WG Charter

[Christopher Wood <[e-mail]>]

I took a look at the charter. Beyond the problem statement refinement happening in another thread, I wanted to comment on the proposed work items. My feedback is below. I’m happy to turn some of this into one or more PRs against the charter text if that’s helpful.

---

1. The WG will select (and potentially profile or augment) acceptable common identity format/formats that shall be used in the SCITT ecosystem. This will enable interoperability across geographical regions and also trace the identity chain seamlessly when a product comprises of multiple sub-products from multiple issuers. This includes a model of essential actors, such as the supply chain "issuer" (one which generates supply chain artifacts), and their duties in the ecosystem.

I think we should strive to punt on all identity-related issues and simply pick an abstraction that is extensible for different use cases. MLS has some useful text in their charter on this point that we might want to repurpose accoringly:

   While authentication is a key goal of this working group, it is not
   the objective of this working group to develop new authentication
   technologies. Rather, the security protocol developed by this
   group will provide a way to leverage existing authentication
   technologies to associate identities with keys used in the protocol,
   just as TLS does with X.509.

That would de-emphasize DID — and the baggage it carries — and allow us to keep issues of identity separate from the rest of the work.

2. The WG will define the envelope and common schema for carrying supply chain claims/endorsements.

This is a fine work item.

3. The WG will standardize the Transparent Registry requirements to generate homogeneity across multiple supply chains.

This doesn't seem like something the IETF can do since it ultimately boils down to policy. For example, some deployments of SCITT might choose to only require that a transparent registry produce countersignatures over claims without any historical data, whereas other deployments might want full the transparency service to provide a complete (global?) view of all claims registered with the service. There's definitely a spectrum of options here, and the choice of what requirements make sense depend on a particular deployment's threat model. 

I might rephrase this particular work item to something like the following:

   The WG will standardize profiles of Transparent Registry services and document their requirements and security properties.

4. A standard format for authenticity data returned from the transparent registry, such as proof, etc. The standard will enable independent verification of supply chain claims at a (much) later point on multiple platforms across multiple geographical locations.

This is a fine work item, but I would drop "on multiple platforms across multiple geographical locations".

5. The WG will develop standards for auditing the supply chain claims that are introduced in the transparent registry. This will, in turn, generate audit claims (results of the audit) which can be introduced in the same registry. Audit information can be queried by supply chain consumers (end customers) before making critical business decisions.

I don't understand why it's necessary for audit claims (what is an audit claim?) to end up in the registry. This again seems like a deployment specific requirement. Instead, I might rephrase this to something like the following:

   The WG will document ways in which Transparent Registry services can be audited for correctness against registered claims.

... or something. The intent here is to say "we'll describe how to audit, where auditing varies based on the service you're interacting with."

6. The WG will develop standards that define the notarization process and outline the core functions/actions that a notary will perform in the supply chain ecosystem.

Notary isn't a concept or role in the architecture document, so it's not clear to me what this work item intends to document. Can someone please clarify?

7. Standardize request-response interactions ("external API") and potentially other interaction models provided to various actors to interact with the supply chain ecosystem. This includes standardizing inter-component messages between supply chain building blocks to support easy reference implementations of SCITT building blocks by various organizations and easy industry-wide adaptation.

This seems pretty vague right now, so I suggest we punt this issue out of scope for now. To that end, I might rephrase this to something like the following:

   The WG will discuss extensions to the protocol that can assist other interaction models provided to various actors to interact with the supply chain ecosystem. Where such mechanisms appear sufficiently useful, the WG will re-charter to add relevant new work items.

---

Best,
Chris


> On Jul 2, 2022, at 12:18 PM, Eliot Lear <[e-mail]> wrote:
> 
> Yogesh,
> 
> This is a very good starting point.  I will have a few suggestions in a PR in the coming week.  I would ask that people take a look.  Things to do at this point:
> 
> 	• Confirm that the problem statement reflects the results of our last BoF,
> 	• Review the goals, non-goals, and work program
> Things not to do, at least on list:
> 
> 	• Pick at spelling or grammar, or nitpick wording.
> Eliot
> 
> On 01.07.22 11:29, Yogesh Deshpande wrote:
>> Hi all,
>> 
>> SCITT BoF proponents have prepared a WG charter draft based on the comments
>> since the last BoF (problem statement) and the discussions on list.
>> This preliminary charter draft is intended as a basis for discussion and as
>> a preparation for the upcoming SCITT BoF at IETF 114 (preliminary meeting details: 
>> https://datatracker.ietf.org/meeting/114/session/scitt
>> ).
>> 
>> The charter draft lives on github:
>> 
>> 
>> https://github.com/ietf-scitt/charter/blob/master/ietf-scitt-charter.md
>> 
>> 
>> Feel free to chime in via comments or suggestions for further improvement
>> by creating github issues or PRs on this repository.
>> 
>> Regards,
>> Yogesh
>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>> 
>> 
> -- 
> SCITT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scitt