On Tue, Nov 2, 2021 at 4:46 PM William Bartholomew (CELA) via lists.spdx.org <[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://outlook.office.com/findtime/[email protected]&anonymous&ep=plink> > > Principal Security Strategist > > Cybersecurity Policy – Digital Diplomacy > Regards, Dave -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4230): https://lists.spdx.org/g/Spdx-tech/message/4230 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]] -=-=-=-=-=-=-=-=-=-=-=-
