SCITT Meeting 27.Feb.2023

Minute Taker: Hannes Tschofenig

Steve mentioned that the term "Transparency Services" was preferred
(instead of registry, ledger, ...)

Dick: Transparency Service maintains the registry.

Steve: There are different components, such as notary, storage, policy.
What are we using for the overall concept?

Roy: TS works for me.

Dick: TS has some policy involved on what it allows to store in the
registry

Roy: Yes. If there is multi-tenancy then the TS has to keep track of who
owns what.

Henk: Created a PR that incorporates the proposed terminology.
I created issue #15, which includes the inconsistency between log,
ledger and transparency registry.

The TS includes

• the append-only log,
• the generation of the receipt, and
• the registration policies (a gateway function that limits the use of
  the TS).

Dick: The TS has some policies of what it records and it constraints
what can put into the TS.

Henk: There are limits of what the TS can verify. For example, if an
issuer says that there is a text and instead it put a video in there.

Dick: The registry could actually contain a false statement.

Roy: The notary does not read the contract.

Dick: I understand but question the benefits to the consumer.

Roy: The notary will check the identity of the issuer and it will not be
the job to verify the content, for example to verify the SBOM for a
missing element.

Dick: Can a notary specify whether certain content types are permitted
or not permitted?

Roy: There are two policies, one for the issuer and there may be other
roles for the content type at a different layer or even at a different
registry (but we haven't gotten to that layer yet).

Dick: Are you saying that you go to one registry for one type of
information and to another registry for different information?

Roy: Yes, that's a possible implementation.

Cedric: Explains how the term Transparency Service was proposed.

ACTION ITEM Roy: summarizing the major discussion points and send them
to the ML (including input from Cedric)

Roy: Is the eNotary single instance or multi-instance (for scalability
reasons)?

Hannes: The cardinality of the entities inside the TS are not described
(yet).

Ray: I don't agree with the entities the TS consists of.
There is no identity information. The TS lets others look at the
append-only database. The eNotary should not be a gate keeper.

ACTION ITEM Ray: promised to create a drawing with an identity service,
a storage service, etc.

Steve provides further explanation of the drawing referring to
https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/7
is expanded upon here:
https://scitt.io/distributing-with-oci-scitt.html#distributing-with-oci-registries-with-scitt-enhancements

Roy: Don't use identity here.

Ray: You will have to use identity thought about somewhere. Even if it
is not "in-scope", Identities (handling roles) have to be captured in
the main architecture diagram

Steve explains that the eNotary authenticates the issuer and makes
decisions about what identity it trusts.

Discussion between Ray and Roy.

Steve: The registration policy can be made open but it is up to the
operator to decide whether it wants to do so.

Ray: Putting too much into the eNotary is a problem. You have to be an
authorized user to the system before submitting something.

John Andersen: Suggests multi-instance eNotary systems to bypass gateway
keeping issues.

Roy: We have to discuss this issue.

Neal: Roy covered much of what I wanted to say, better than I could
have. eNotary needs to do gatekeeping - of JUST the identity and
permissions to post to the ledger, before anything goes on ledger.
Doesn't vet the content itself, beyond perhaps some sort of "type" of
post.

Neal to Ray: I think we largely agree and you're just misunderstanding
the meaning we have of "transparency service" - see "transparency log"
literature. Neither the the eNotary nor the "service" vouch for
truthiness of the statements.

TBD: Missed some points in the discussion between Steve, Roy, Ray, and
Neil in the discussion about the figure of issue #7 at
https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/7

Hannes suggested to discuss the PR on the mailing list.