Collection was created to be a superclass of both ContextualCollection and Document because they have shared traits and are both containers. SBOMs do have external maps (because they indirectly inherit from Collection and external maps are attached to Collection).
The "verifiedUsing" (today) isn't how you verify the element but the thing that the element is describing. For example, a File element's verified using is the hash of the file, not of the File element. We do not currently have a way (outside of a Document) to generate a hash of an element, this is why the model for referencing external element is bound to Document, because without that we have no way of a) knowing where to fetch the element from and b) verifying its integrity. We had a discussion a couple of weeks ago about how this might be possible (canonicalization of elements and hashing of the canonicalized form) but that has its own challenges, and we didn't conclude that conversation. If we can define a way to guarantee integrity of individual elements and how to fetch them then yes Document becomes far less interesting. I also believe this is only an exchange problem, once you've fetched a Document and verified its integrity the elements within it can standalone and you can query over the graphs between them completely ignoring Document. I'm unconvinced the SBOM should be a unit of exchange, the SBOM will often reference other things that you want to transfer along with the SBOM (identities, licenses, etc.). Having the unit of exchange being Document (and there's no reason you can't have a Document that only contains an SBOM if you want) gives you the flexibility of transferring multiple independent elements in a single exchange. Regards, William Bartholomew (he/him) - Let's chat<https://outlook.office.com/findtime/[email protected]&anonymous&ep=plink> Principal Security Strategist Cybersecurity Policy - Digital Diplomacy From: David Kemp <[email protected]> Sent: Thursday, November 4, 2021 10:06 AM To: William Bartholomew (CELA) <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [EXTERNAL] Re: [spdx-tech] Collection member Elements You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<http://aka.ms/LearnAboutSenderIdentification> On Tue, Nov 2, 2021 at 4:46 PM William Bartholomew (CELA) via lists.spdx.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.spdx.org%2F&data=04%7C01%7Cwillbar%40microsoft.com%7Cda777766cefb45e86cdd08d99fb567d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637716423761522107%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=94%2BnKp3vs7hga1UYUB3Qtejy%2Fd3ZVpBkHn5XWXaMctg%3D&reserved=0> <[email protected]<mailto:[email protected]>> wrote: 1. Is a "Collection" an object containing 1 or more "Elements"? Technically 0 or more elements. This is a base class that provides the ability to contain elements, identify root elements, and to attach namespace and external maps. 2. Is a "ContextualCollection" an object containing 1 or more "Elements" that are in some way or the other related? It inherits from "Collection", so it inherits being able to hold 0 or more elements (and the other abilities described above). It adds the logical restriction that the elements are in some way or the other related. Collection was created in the proposed logical model to be a superclass of ContextualCollection. I don't believe a logical restriction that "elements are in some way related" can be articulated well enough to distinguish one from the other. A Package type definitely has related elements because they are presumably part of a single software distribution. But I believe that "unrelated" elements like the example provided earlier become related as soon as, and simply because, they are put into a collection (e.g., random files put into a directory). An identity and a file might have nothing to do with each other. If you create a "non-contextual collection" with those two elements, and sometime later the identity signs the file, does the collection (unchanged from before, with the identical two elements) become contextual as a result of a detached signature existing somewhere else? 3. Is a "Document" a "Collection"? It inherits from "Collection", so it inherits being able to hold 0 or more elements (and the other abilities described above). It provides a "unit of exchange" when you are sharing SPDX documents with others. Today, this is the level where we'd calculate the hash of the exchanged document. In the future if we solve being able to hash individual elements the need for Document may diminish but we'd have to look through the use cases to determine if that's true. I believe an SBOM (inherited from BOM, ContextualCollection, Collection, and the abstract Element in the proposed model) should be a unit of exchange. An SBOM should have ExternalMap (I think it should be called ExternalElement) without requiring the SBOM to be enclosed in a Document, and that would be possible by attaching "externalMap" (externalElements) to Collection and getting rid of definingDocument. The Collection itself (e.g., an SBOM) is an Element which has "verifiedUsing". So the ability for collection member Elements to be covered by a single Collection hash doesn't depend on the existence of Document. (As a separate topic, it doesn't make sense for an Element to have a hash of itself. It does make sense to have a signature property of itself. A hash value would only be present in a reference to an externalElement and would be compared to the computed hash of the referenced Element. Different references could use different hash algorithms. In contrast, a reference to a signed Element wouldn't contain any value to compare, it would just validate the retrieved signature using that signature's algorithm. Thus, verifiedUsing needs more work.) Regards, William Bartholomew (he/him) - Let's chat<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Foutlook.office.com%2Ffindtime%2Fvote%3Fbook%3Dwillbar%40microsoft.com%26anonymous%26ep%3Dplink&data=04%7C01%7Cwillbar%40microsoft.com%7Cda777766cefb45e86cdd08d99fb567d4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637716423761532101%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jyus6Gdgk03yD%2FNIgkYwG7fKQLwD5ubgLayUFIOuMQA%3D&reserved=0> Principal Security Strategist Cybersecurity Policy - Digital Diplomacy Regards, Dave -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4231): https://lists.spdx.org/g/Spdx-tech/message/4231 Mute This Topic: https://lists.spdx.org/mt/86776587/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
