Last week we discussed ExternalReference, drew some combinations of elements on the model, and made the "elements" field of ExternalReference plural so that all of the elements in a document are included in a single ExternalReference.
Later, Sebastian and I discussed canonicalization, particularly whether the element store is complete without document retrieval, and the role of detached signatures. Those discussions led to the conclusion that whatever other types of data an Element's externalReference property may refer to, it should NOT refer to a payload. Consider the element drawing: There are 5 elements of *any* type that have some kind of connection (not "relationship"): - Element 1 could be an Annotation whose subject is 2 and was created by identities 3, 4, and 5. - Element 1 could be a Relationship created by 2, from 3, to 4 and 5 - Element 1 could be an SBOM with Files 2, 3, and 4, created by 5 Those elements can be put in Payloads (serialized SPDX documents) in *any* combination, for example: - A single payload with elements 1,2,3,4,5 - Two or more payloads where one payload may reference elements in other payloads - Five payloads, each containing a single element and zero or more references to other payloads Remember that the reason for serializing more than one element into a payload is to allow information within a payload to be shared (reducing its size) and to allow a single payload integrity to provide integrity for each of its elements. The picture shows "H" on each reference to a payload, indicating a hash or signature over the element(s) in the payload. But the value (and hash/signature) of an element cannot depend on which of many payloads that element may be serialized in. Therefore the externalReference property of an element cannot refer to a payload (the externalReferenceType (currently TBD) cannot be "PAYLOAD" or "SPDX_DOCUMENT" or whatever type would have been used for payloads. The drawing shows three ways of serializing five elements. The first has no payload references, the second and third have a single reference. The SpdxDocument Element is the single element type that describes a payload. An SpdxDocument MAY be created to describe any payload, but it only MUST be created in order to support references from one payload to another. In the diagram, only two SpdxDocument elements MUST exist (for payloads [2,4,5] and [1,5]). A decision to not create an SpdxDocument element for a payload does not "make a commitment to future use cases". If the creator of payload [2,4,5] did not create SpdxDocument [2,4,5], then the creator of payload [1,3,(6)] can create SpdxDocument(6) that describes the referenced payload. The consequence of not having the creator's SpdxDocument included in payload [2,4,5] is that there is no creator's signature to allow original source verification. The proxy signature by the creator of payload [1,3,(6)] can still be verified by anyone who references or uses that payload. In summary, the payload external reference information (element list, payload download/query information, and integrity information) belongs exclusively in the SpdxDocument element and must not be included in any other element type. Regards, David -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4755): https://lists.spdx.org/g/Spdx-tech/message/4755 Mute This Topic: https://lists.spdx.org/mt/93289465/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
