Skip to content

Latest commit

 

History

History
128 lines (116 loc) · 11.5 KB

2021-04-06.md

File metadata and controls

128 lines (116 loc) · 11.5 KB
Raw

SPDX Tech Team Meeting, April 6, 2021

Attendees

  • Sean Barnum
  • William Bartholomew
  • Henk Birkholz
  • William Cox
  • John Horan
  • Jim Hutchinson
  • Rose Judge
  • Nisha Kumar
  • Bob Martin
  • Gary O'Neall
  • Jeff Schutt
  • Thomas Steenbergen
  • Kate Stewart
  • Kay Williams
  • Steve Winslow
  • Alexios Zavras

Agenda

  • Model Serialization

    • Bob: Do we need to support all existing formats Not want to hobble all the existing formats. There are things that humans want to see.
      • William: Don't think we've introduced modeling concepts that aren't in SPDX today, don't think the new model should have elements.
      • Sean: How much of the serializations in the relationships (1:n) that would prevent? Don't prevent multiple serializations needs to be ground truth.
      • Gary: https://github.com/spdx/spdx-spec/blob/development/v2.2.1/examples/SPDXSpreadsheetExample-v2.2.xls Tag:Value may have issues due to the lack of ability to represent hiearchy
      • Sean: It is possible in tag:value - tuples to tag:value should be possible. JSON LD & YAML are reasonably readable.
      • Gary: We'll need to discuss this with a real example.
      • Henk: JSON looks like tag:value today. Don't want to burden to support everything, one Mandatory To Implement (MTI).
    • Gary: Needs to be at least one conversion tool that produces everything.
      • Sean: Need to figure out which serialization and then build out tool.
      • Gary: What is mandatory? For this group? or for every conformant tool?
      • Sean: For any implementer adopter to spec, must support at least one specific.
      • Gary: There should not be an MTI
    • Bob: We should look at MTI in a different way, make sure model can serialize to one MTI, and then show that the translation will go to the others. Decompose the problem. This is a requirement on the model and spec writers so we can continue to support multiple options that tools to use. Since we're changing the definition of MTI - we shouldn't use it.
      • Kate: If can't translate then a problem on model? Bob: Possibly.
      • Nisha: JSON LD - tools may not be able to parse spec at this point.
      • Sean: JSON LD is a subset JSON. LD can help with model translation, and inferencing, and automated translations.
      • Gary: SPDX today supports JSON-LD and JSON , but using different structure.
      • Bob: If JSON LD is serialized, it should have the rigor we need for model.
      • Sean: It is broadly used behind the scenes.
    • Henk: Integrity articulates there should be one "goto toolchain" to do signing and validation - requires a single canonical representation for consistency.
      • Gary: in JSON LD - this was discussed in 2.1; but we had community that reviewed extra fields, which landed on JSON. Fair to discuss again for 3.0, but it has been discussed.
      • Sean: JSON LD Expanded Form to Compacted Form and rest can be hidden.
      • William - I don't know that "one tool" for integrity will be practical, as companies have different technology stacks and requirements. We should have a strong spec, a reference implmentation, and a set of validation tests that people can use.
      • Alexios: https://w3c.github.io/json-ld-syntax/ latest version of JSON-LD (published last week), has the examples in both compacted and expanded format
      • Henk: The PoC code that we currently is at: https://github.com/mcr/sbom-cose - a good home could be spdx space on github.
    • CONCLUSION:
      • Model --> with at least 1 serialization format --> specific serialization is TBD.
      • Default serialization --> others supported --> may need a serialization specification
    • Thomas: concerned about two version numbers in play.
    • Sean: Base serialization of model would be a ground truth; separate base truth of serialization.

  • Continue discussion of how to handle profiles in spec.

    • Steve: Conversation, how document profiles and relate to each other. Rest of TBD.
    • Alexios: Lets clarify first, what a profile mean?
    • Sean: Are we conflating Profile what a Model and Spec illustrates. Profile is a subset.
    • Alexios: This is more what we were calling "view" for subset. "Profiles" were extensions of specific interest/context.
    • Nisha: Few fields in base profile and optional fields that can be added to the document which conforms to a specific profile.
    • William: Definition into 2 parts: object fields specific to context. Implementation perspective - broad agreement on definition, not necessary
    • Kay: model = all profiles; profile = subset of model
    • Sean: Cardinality constraints on class, will need to be specified in profiles, as additional constraints. Model will need to be flexible to support various profiles. "usage contexts".
    • Kay: Compliance points align with profiles.
    • Henk: Profile can requires extension points to model, but then need to extend the model.
    • Kay: volunteered to write up the profile, compliance point, and usage contexts.
    • Alexios: email needs to be revisited - to align with this clarification. Each profile is a subset of the model (aka view).
    • Sean: propose template can be used to specify a profile as well. Our model has multiple namespace (ie. core, software namespace, ...) These are component areas of the model. Model is union of all namespaces. Namespace: class; profile reference within a namespace.
    • Gary: implications of one model change? Sean: Not really Gary: Understand how namespaces would work in RDF, but I don't see how it would work for non-RDF schemas.
    • Thomas: Security vs. Defects vs. Vulnerabilities. Ok for model to reflect Defects (superset namespace), but vulnerabilities (profile) is what folks understand. May need to break this into views.
    • Kate: What are the names we are using?
    • Gary: We still have to define the model changes for the specific "namespace", and we have to translate that into serialization specific schemas (the start of last week's conversation). Concern about complexity when supporting more than one namespace and profile.
    • Take this back to email list.

Notes from Chat

  • 11:09:13 From Nisha Kumar to Everyone : Do we have any n:1 relationships?

    • 11:09:43 From Kate Stewart to Everyone : We’ve tried to avoid them. 1:n is extension at this point.

  • 11:09:47 From Gary ONeall to Everyone : https://github.com/spdx/spdx-spec/tree/development/v2.2.1/examples

  • 11:12:29 From Nisha Kumar to Everyone : Sounds like we have a tree. There are many serialization formats for a tree data structure. For spreadsheets, perhaps each traversal of the tree is 1 row?

  • Traditionally, it would be called “default serialization” in the way we are proposing to use it

    • 11:34:29 From Gary ONeall to Everyone : Henk - if there should be a single tool, we have a repo for tools at GitHub/spdx - we could add the tool there
    • 11:34:49 From Gary ONeall to Everyone : We also have an online version of the SPDX tools which has a REST API
    • 11:35:02 From sbarnum to Everyone : I concur on the inherent relationship between serialization and integrity
    • 11:35:24 From Gary ONeall to Everyone : We just need volunteers to write the tool ;)
    • 11:35:50 From sbarnum to Everyone : Integrity requires a single canonical representation for consistency
    • 11:36:42 From William Bartholomew to Everyone : I don’t know “one tool” will be practical, companies have different technology stacks and requirements. We should have a strong spec, a reference implementation, and a set of validation tests people can use.

  • 11:38:39 From Alexios Zavras to Everyone : https://w3c.github.io/json-ld-syntax/

  • 11:39:44 From Henk Birkholz to Everyone : @Gary: the poc code that we currently have is at https://github.com/mcr/sbom-cose

    • 11:40:29 From Henk Birkholz to Everyone : a good home could be the spdx space on github, should come back 2 this l8r

  • 11:41:08 From William Bartholomew to Everyone : OT: Has Integrity talked about/looked at the new sigstore/cosign

    • 11:46:03 From Henk Birkholz to Everyone : sigstore came a bit late to the game, but it was discussed, we agreed to go with a dependency to a toolchain and not a dependency to a service for now. The sigstore concept of hash trees can easily be incorporated. sigstore is in its early stages on that, but it seems rather straight forward

  • 11:49:08 From Gary ONeall to Everyone : Here's the JSON-LD context that goes with the JSON format we're using in 2.2: https://github.com/spdx/spdx-spec/blob/development/v2.2.1/ontology/spdx-ontology.context.json

  • 11:56:41 From Kay Williams to Everyone : Model = all profiles

    • 11:56:48 From Kay Williams to Everyone : Profile = subset of model
    • 11:57:04 From Kay Williams to Everyone : Profiles can extend other profiles
    • 12:00:51 From Nisha Kumar to Everyone : I like “usage contexts”
    • 12:01:49 From Kay Williams to Everyone : Compliance points align with profiles

  • 12:13:59 From Gary ONeall to Everyone : We seem to be discussing a very different approach to defining the spec - I'm not sure what "core" means anymore

    • 12:19:02 From Gary ONeall to Everyone : I can see how the namespaces would work in RDF, but I don't see how it would work for non-RDF schemas
    • 12:20:41 From Gary ONeall to Everyone : My interpretation of this discussion - we just renamed profiles to namespaces and introduced a new concept called profiles
    • 12:21:08 From Gary ONeall to Everyone : We still have the issue of how we define the namespaces (what used to be called profiles)
    • 12:21:26 From Alexios Zavras to Everyone : we split old-profiles into namespaces (definitions) and profiles (SHACL part)
    • 12:22:48 From Gary ONeall to Everyone : I like the idea of splitting out the SCHACL part
    • 12:23:34 From Gary ONeall to Everyone : Note: most schemas outside of RDF do not have the concept of sub-properties
    • 12:23:34 From Alexios Zavras to Everyone : SHACL == profile; the conditions that have to be satisfied
    • 12:24:38 From Gary ONeall to Everyone : We still have to define the model changes for the specific "namespace"
    • 12:25:02 From Gary ONeall to Everyone : And we somehow have to translate that into serialization specific schemas (the start of last week's conversation)

  • 12:26:03 From Gary ONeall to Everyone : Clarification from Sean - Are you suggesting if there is a change in a property for a namespace, they redefine that property within that namespace and use a subproperty relationship?

    • 12:28:19 From Gary ONeall to Everyone : There is a complexity when supporting more than one namespace and profile
    • 12:29:52 From sbarnum to Everyone : @gary I am not suggesting a profile redefine any classes or properties. But they can assert constraints on them that differ from the default constraints in the model as long as they are a narrowing of the model constraints and not a broadening
    • 12:30:49 From sbarnum to Everyone : Oh, rereading your question, maybe I misunderstood it

Future Agenda Topics

  • Integrity update & implications on signing and validation.
  • FSFE - having profile that relates to the orginator of code, pull in legal. FSFE - structuring of metadata, manual use of SPDX standard. Invite - ( Steve, ReUSE folks )
  • Legal Profile - contents
  • Core Profile - content writeup
  • Identity modeling