Re: [SCITT] Draft WG Charter

[Orie Steele <[e-mail]>]

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

...

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

...

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

I agree with this framing.

And welcome PRs on these.

Regards,

OS

On Wed, Jul 13, 2022, 4:48 PM Christopher Wood <[e-mail]> wrote:

> 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
>
> --
> SCITT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scitt
>