Skip to main content

Minutes interim-2023-scitt-35: Mon 15:00
minutes-interim-2023-scitt-35-202310021500-00

Meeting Minutes Supply Chain Integrity, Transparency, and Trust (scitt) WG
Date and time 2023-10-02 15:00
Title Minutes interim-2023-scitt-35: Mon 15:00
State Active
Other versions markdown
Last updated 2023-11-20

minutes-interim-2023-scitt-35-202310021500-00

Agenda for today:

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