Minutes 2023-12-11

Procedural note: We did take good minutes for the last 2 meetings but
forgot to press the right buttons to upload them to Datatracker

Scribes: Orie Steele, Steve Lasker

Agenda

• WGLC for Use Cases doc

  • Are we confident in the Use Cases doc now?
    • https://github.com/ietf-wg-scitt/draft-ietf-scitt-software-use-cases/pull/11
    • Orie: Not ready, needs review to be applied or dismissed or
      otherwise addressed.
    • Steve: will review today
    • Ray: use cases are evolving too fast, we should publish the
      use cases last, not first!
    • Dick: The FDA eStar form has some excellent use cases that
      SCITT may satisfy. Here is the eStar form:
      https://www.fda.gov/media/152429/download
    • Orie Steele also
      https://www.fda.gov/medical-devices/how-study-and-market-your-device/estar-program

• Status of architecture doc, recent PRs and open issues

  • Steve: Clearing up remnants from -118: reg_info; further
    consdation on claims header; questions around DID-Web

• Prepare for SCRAPI

  • https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/139
  • Orie: We will need to clean up architecture to publish it on
    time, I am removing content that will block architecture from
    progressing.

• Some Header Re-Shuffeling

  • https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/pull/140

• Key binding Registration

  • https://github.com/ietf-scitt/draft-birkholz-scitt-scrapi/pull/9

Items for input:

1. Do we want to remove SCRAPI from the architecture BEFORE we've
   actually finished (meaning we have to keep 2 docs in sync) or leave
   it in current basic form and pull it out later?
   Orie: simplifying the document is better, and people are expecting
   the SCRAPI stuff to move.
   Steve: agree to simplify the architecture and delegate all API
   changes to SCRAPI

• Status of SCRAPI

Moving forward to adopt.

Orie: PR 9 introduces special claims that have significance and meaning.
Specifically need to think whether we're in a 2-party or 3-party
scenario WRT Issuer/Subject/Audience. In the 3-party model you don't
necessarily know who is going to be verifying your claims...so if SCITT
has a use case for registering a credential issued by one party but
registered by a middle party (eg integrator/distributor) we have key
binding properties in the system. This may lead to us needing to be awre
of these 'confirmation claims' ("I have seen this public key from this
other Issuer further back in my supply chain").
Request that SCRAPI support these types of 3-party operations in both
online and offline credential presentaiton
Link here:
https://github.com/ietf-scitt/draft-birkholz-scitt-scrapi/pull/9

Steve: I have questions if we're bringing in RBAC to SCITT, which we've
said was out of scope.
Consider the integrator role, where an issuer issues statements about
their software product, but then, another company wants to consume
that... they register that software on their instance... is their
identity required? I don't understand why the party that is registering
the statemnt must be captured.... is it optional or required?

Orie response:

• RBAC is an orthogonal concept. TS can implement authorization how it
  chooses.
• Without ecplicit support in the spec it seems hard for the
  Transparency Service to be able to support 3-party systems...how
  would they trace the links? How would they find/enforce submission
  of key binding certificates?
• Steve: understanding it's optional, and not related to RBAC, which
  can be optionally evaluated by the registration policy.

Jon suggests that several members of the group have in the past
epxressed a need for various types of delegation or
through-representation which would require something like this to be
(optional) in the spec, otherwsie the only place to represent key
bindings would be in the policy or log of the Transparency Service
itself, which isn't really tenable.

Ray Lutz: There are 2 kinds of 'delegation' at play here:

1. where you're representing a real-world representations of
   relationships (which may or may not be 'delegation' as such)
2. where you're allowing an entity to submit to SCITT on your behalf

Orie: Would like to discuss JSON encoding of CBOR in SCRAPI.
Jon: The experience of implementing SCITT, using CBOR/COSE. The
experience for representing COSE/CBOR is great, particuarly compared to
ASN.1, no squabble with COSE/CBOR generally used. The question for the
REST APIs has surfaced. There's a lot of machinery along the way that
isn't aware of COSE/CBOR. The internal teams have reverted to base64
encoding. It's been a convienant way to get it across APIs. DataTrails
now passes CBOR across the wire, but it does make it difficult to use
standard tooling. We could consider not creating cananonical APIs.

Orie: +1 Jon, its been necessary to use JSON to make SCRAPI easy to use.
In the implementations done by Transmute, it's been helpful to use JSON,
and include base64 encoded binary messages for posting APIs. Having the
text armoring around the API makes it easy to use. Previously discussed
how many mediatypes may be relevant. Should start looking at specifying
some mediaTypes for json encoding.

Jon: Agreed.

Ray: Can we summarize why CBOR/COSE is required, where JSON can be used
directly?

Orie: We chose CBOR/COSE because its part of the design and
interoperability we think is critical to tackling the problem / use
cases.

Orie: I would be fine having CBOR/COSE mandatory, and JSON optional.

Ray: I support JSON due to the wide adoption and plethora of tools
available, but I understand the COSE or some other format might be
needed for the certificates. There should be at least a top level
wrapper which says what and version is contained in the content block.
That content can be more JSON or many be COSE or JOSE. This is a good
idea for flexibility and making sure that readers don't need to know
what is inside to know if they can deal with it. I will comment on the
PRs, etc.