William,
*UnitOfTransfer #1*.
It has a globally-unique namespace, the 4 default properties for that
namespace, and 6 element values (package, relationship, annotation, 2
files, and an identity). No document element. The namespace and default
properties are like the JPEG header.
{
"namespace": "http://sbom.acme.com/AX7CqA-I/";,
"specVersion": "3.0",
"created": {"by": ["i1"], "when": "2021-11-8T14:15:16+00:00"},
"profiles": ["Core", "Software"],
"dataLicense": "CC0-1.0",
"elements": [
{
"id": "foo-metadata-rev1",
"type": {"package": {}},
"name": "foo"
},
{
"id": "foo-contents-rev1",
"type": {"relationship": {"type": "CONTAINS", "from":
"foo-metadata-rev1", "to": ["hello-file", "world-file"]}}
},
{
"id": "annotation-rev1",
"type": {"annotation": {"type": "REVIEW", "subject":
"foo-metadata-rev1", "statement": "Annotation example"}}
},
{
"id": "hello-file",
"type": {"file": {}},
"name": "hello"
},
{
"id": "world-file",
"type": {"file": {}},
"name": "world"
},
{
"id": "i1",
"type": {"identity": {"type": {"organization": {}}, "email": "
packa...@acme.com"}},
"name": "Acme Package Manager"
}
]
}
*Unit of transfer #2*, defining a Notary namespace.
It contains two relationship elements. It also references 6 elements from
UoT #1. it has no document element.
{
"namespace": "sha256:0kEfWkpXWZWQCk87lYeAoC1jCrt4g2nFr7ctzYAQqf8/",
"specVersion": "3.0",
"created": {"by": ["acme-1493:i1"], "when": "2021-12-23T10:00:00+00:00"},
"profiles": ["Core", "Software"],
"dataLicense": "CC0-1.0",
"elements": [
{
"id": "foo-contents-rev2",
"type": {"relationship": {"type": "CONTAINS", "from":
"acme-1493:foo-metadata-rev1", "to": ["acme-1493:hello-file"]}}
},
{
"id": "foo-contents-amend-rev2",
"type": {"relationship": {"type": "AMENDS", "from":
"foo-contents-rev2", "to": ["acme-1493:foo-contents-rev1"]}}
}
],
"documentRefs": [
{
"namespace": "acme-1493",
"elements": ["foo-metadata-rev1", "foo-contents-rev1",
"annotation-rev1", "hello-file", "world-file", "i1"],
"verifiedUsing": {"hashes": {"md5":
"6be192b1243a593ab0b690230c3ba842"}}
}
],
"namespaceMap": {
"http://sbom.acme.com/AX7CqA-I/": "acme-1493"
}
}
In the logical model there is no difference between containing and
referencing, elements are just "associated". In the physical model contain
and reference are quite different.
For hashes, you don't attach a hash to anything. If you have the bytes of
UoT #1 in your hand, you hash those bytes yourself, and compare them to the
hash value(s) contained in UoT #2's documentRef. For signatures, the
signer would wrap IoT#1 with a JWS or XML-dsig signature, or the signature
values would be "detached" and communicated separately from the UoT.
The dashed "serialization" envelope was my way of illustrating the physical
model on the same page as the logical model, without it being a logical
model itself. Maybe there's a better way of showing that.
Dave
On Thu, Mar 10, 2022 at 10:05 PM William Bartholomew (CELA) <
will...@microsoft.com> wrote:
> Thanks for summarizing this David, if you have a chance could you show
> what a unit of transfer file would look like (JSON, YAML, ... any is fine).
> I've put a few comments in below.
>
> Sent from Outlook <http://aka.ms/weboutlook>
>
> ------------------------------
> *From:* Spdx-tech@lists.spdx.org <Spdx-tech@lists.spdx.org> on behalf of
> David Kemp via lists.spdx.org <dk190a=gmail....@lists.spdx.org>
> *Sent:* Thursday, March 10, 2022 5:41 PM
> *To:* SPDX-list <Spdx-tech@lists.spdx.org>
> *Subject:* [EXTERNAL] [spdx-tech] Serialization, Integrity and the
> logical model
>
> For the punch list and signature/hash discussions:
>
> * Elements are metadata about "things".
> * A unit of transfer is a thing like a file or package
> * A unit of transfer contains serialized data used to transfer one or more
> Elements
> * A Document Element is metadata about a unit of transfer, not the UoT
> itself.
> * Like a file or package, a unit of transfer exists independently of
> whether metadata has ever been created to describe it.
>
> *[William] *Would this be valid though? If I sent you a "unit of
> transfer" that does not have a Document element I wouldn't consider that to
> be valid. An analogy would be a JPEG file, it contains the serialized image
> data, but it also had a header, without that header it is no longer a JPEG
> file. Yes, you may be able to still interpret the remaining data, but you
> can't claim it's a JPEG.
>
> * Integrity check values (ICVs) can be computed over any sequence of bytes
> including a UoT.
>
> *[William] *Since a Unit of Transfer contains elements but is not an
> element how do you attach the ICV to the Unit of Transfer?
>
> * Serializing multiple elements into a UoT allows a single ICV to provide
> integrity over that collection of elements.
> * Serializing a single element into a UoT allows an ICV to provide
> integrity over that element independently of all other elements.
>
> *[William] *I'm struggling to imagine what this looks like so a physical
> example would really help. My specific struggle is with what the Document,
> UnitOfTransfer, and associated ICV look like when serialized.
>
> As a reminder, the attached diagram (and my serialized versions of
> William's Relationship examples that Nisha graphed) illustrate that a
> logical model does not define serialization -- multiple serializations
> exist for the same logical model. ExternalMap and NamespaceMap exist to
> support Element serialization; they do not exist in logical / deserialized
> Elements.
>
> *[William] *One specific requirement was that we can retain the
> ExternalMap and NamespaceMap when deserializing and serializing, even
> across different formats. I think this requirement then requires that
> information to be in the logical model so that it isn't lost.
>
> The logical model
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fspdx%2Fmeetings%2Fblob%2Fmain%2Ftech%2FModel.png&data=04%7C01%7Cwillbar%40microsoft.com%7Cf6d5be04b4e34d3a4c2e08da03003cd9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637825596808207995%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kqAhq1uIt%2FS3UYTX1gv3vv3JhNrGx7JI4HBBAF5pWSA%3D&reserved=0>
> has a question "should namespace map be on collection or doc?" Because
> Collection, Document, BOM, and SBOM are logical elements, namespace map
> doesn't apply to any of them. Only when Document, BOM, or SBOM elements are
> serialized into a UoT does namespace map data exist. Proof: when a UoT is
> created the namespaces and prefix for each namespace are assigned. Two
> different UoTs could be created with different prefixes and namespaces; but
> after deserialization the Elements from each UoT are identical.
>
> *[William] *I want to separate this into two parts. Yes, once
> deserialized the elements are identical. However, the NamespaceMap is kept
> in the logical model so that when you serialize back out you can repeat the
> original map process.
>
> Dave
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4395): https://lists.spdx.org/g/Spdx-tech/message/4395
Mute This Topic: https://lists.spdx.org/mt/89702111/21656
Group Owner: spdx-tech+ow...@lists.spdx.org
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
