Agenda for today:

• Identity discussion
• Redefinition of Feed PR
• SCRAPI OpenAPI definition

Identity discussion

Isaac proposed:
So we have: for company identification, SCITT should —

1. Invent its own scheme
2. Identify a sufficiently workable existing scheme and mandate
   ("MUST") its use
3. Identify a sufficiently workable existing scheme and recommend
   ("SHOULD") its use
4. Stay silent on the matter; multiple schemes are allowed, with some
   plausible examples given but without an identified preference

• Ray: Could we have something like a DID document that has various
  types of identity in there? DUNS, whatever you want. SCITT could
  provide a kind of facility to store/verify that identity
  information. There are a number of schemas we can recommend.
  So we could do something like 1 AND 4: don't invent anything brand
  new but make a clear way of communicating identfiers
• Dick: The standard insists that statements be authenticated. PLUS If
  we are going to make the registry available to the public they will
  need to find/vet/verify company information. Those 2 between them
  require something a little more than 'staying silent'
• Roy: There are multiple layers here: it doesn't really matter if the
  identity entry on a statement is exactly the same as the RBAC layer,
  and certainly not the same as the ledger ID.
• Neal: The notion of 'company' is tricky. The kinds of 'entity' we
  want signing an SBOM or the like needs to be flexible, and include
  product teams, or acquisitions, and so on.

• | Steve: 'Company' is an example of one of the types of identities we use. Company is a placeholder for Company | Project | Person. In the registration policies of a TS you can specify which types or specific Identities the SCIT instance allows. One of the huge value props of SCITT is that you timestamp everything and the statement is signed at a point in time, so we can cope with those evolutions of real world vs system IDs |

• Neal: The current doc uses the term issuer. Is there something
  different that goes into the feed.

• Roy: Who owns the product? Needed to know the policy of the trusted
  root changed on the ledger (append-only log).
• Dick: no objection with replacing company id with entity id. Propose
  striking Company ID, and use Entity ID.
• Roy: differentiating between a product and a human. Having email on
  a product doesn't make sense. Nervous killing the ideas
• Steve: In SCITT a Feed is just a string, so how do we identify and
  differentiate the 'product' from the owner' of the product? Can we
  add texture to this by also making the FeedID (and/or root Artifact)
  a Statement of its own?

• Roy: gets into questions of squatting. Get into a space where a
  bunch of global companies can make comments about different feeds.

  We need to enable people to find the volunteered linkage between
  ‘ledger’ identities and real identities, including
  1: Create a strong syntax for carrying entity identification, with
  enough (meta)data to resolve it - eg [{DNS: example.com},{DUNS:
  12345678}]
  4: Ensure the syntax can support any of the schemes

Open question

• Feed identity points to a structure or statement that contains
  metadata
• Feed identity which is a serialised composite of {type:id:meta}
• Dick: agree entities can be anyone/anything. Need to be concious to
  support any entity can produce and make "comments" (statements) on a
  registry (append-only log)
• Yogesh: Can have a feed identity that can be a composed identity
  (association of the "vendor") and version. Can give an example,
  where the feed is flexible (bstr). Up to the owners to identify
  them.
  On the company, can give examples for uniqueness, and need to set
  the context.
• Summary: have general concensus to enable people to discover time
  based signed statements, you can tell the difference. We must not
  have the ledger identity be forced to be a real world identity.
  SCITT needs a scheme to support the syntax, to enable different
  verticals and ecosystems.

Closed the queue to move forward on other agenda items.

SCRAP API

SCRAPI OpenAPI definition

• Orie: reviewing the PR. Signing entity = identity. Lines 21-26
  discover key material for the service. Using the receipt to disocver
  the keys. The issuer can have an identity that's URL based. Can
  address what keys were used to verify signed statements.

  • The statements endpoint
  • Receipts endpoint - to retrieve statements that have been made
    transparent
  • References to the architecture document.
  • Updated the terms from entry to issuers --> statements -->
    receipts
  • Line 37 adds the concepts of feeds. An association of
    statements. You might have a URL that shows me the feeds or
    elements of a specific feed on this Transparency Service.
  • A lot of different ways you can handle authorization with
    resources on the server.
  • There's an example of possible feeds. /oas/schemas/Feeds.yml
    (Just an example for reference) (CPE, Purl, GS1 Digital Link)
    (Reference links in the PR)
  • GS1, used by barcodes, are one of the better ones for reference.

• Jon - keeping with rough concensus through running code, testing out
  the emulator will help bring focus

• Dick - understanding that identities need to be represented by a
  url, not a uri. A purl can be an invalid url. Thinks you'll need to
  make that something else. URIs may be a bit more broader for
  opportunities (option 4 to allow anything)
• Yogesh - question to Orie about the design consumption.
• Orie - You can construct URIs, transparency service resources will
  have some identity based on where there hosted, unless we're talking
  about non http(s) resources. Some of those id will be composite of
  other urls. Took identifiers (purl ...) as examples, not limited to
  those. Expose resource IDs that are not specific to the specific TS.
  When seeing a GS1, you can ask the TS if it's seen similar
  statements.
• Ray - clarifying: is the id proposed be the feed id on signed
  statements?
• Orie - might be yes or no. Feed Ids show up in two places. The
  resource, the signed statements had to be submitted to make these
  feeds have any data under them. They could repeat the ID.
  The transparency service gets to decide how many feed IDs can be
  maintained.
• Ray - are the feed ids examples of external types?
• Orie - CPE is an example, where many different TSs may have similar
  IDs for correlation. CPEs exist today. When we create identities in
  SCITT, we're creating new identifiers, a structure for URLs for
  others to consume. Creating an entire namespace.
• Ray - The feed can be a digital thing, where you get a copy of it.
  And a real thing, where you have instances of it.
• Steve: Exactly as Ray said, you start with a piece of software, then
  you want to release it, then every copy is an exact copy. Next, you
  have physical items, and those are NOT exact copies, or documents,
  which start as identitcal copies but may differetly version over
  time. So we need a structure that accommodates these options that
  allow a collection of statements over time about a thing, and we
  have to leave it up to the industry/user how they define what a
  thing is.
• Jon - Can we look to review/approve the PR
• Yogesh - can folks put the comments in the PR: SCRAPI OpenAPI
  definition and look to close by next Monday's meeting