Date
1 - 4 of 4
Actor datatype
|
David Kemp
Punchlist item: Last week we decided that Actor should have always been a datatype rather than an Element as previously shown on the model diagram. The Actor datatype should label its identifiers without requiring any association with Identity elements. This example File element shows how "creator" looks with "Identifier" having a specified syntax (name, email, uri, ...) and Actor being an Identifier having a specified subject type (person, organization, tool, any): { "id": "urn:acme.dev:artifacts:gnu-coreutils/v9.1/src/du.c", "type": { "file": { "filePurpose": ["APPLICATION", "SOURCE"] } }, "creator": [ {"person": {"email": "fred@..."}} ], "created": "2022-04-05T22:00:00Z", "specVersion": "3.0", "profiles": ["Core", "Software"], "dataLicense": "CC0-1.0" } |
|
|
|
Martin, Robert A
David,
That isn’t my recollection of the conversation. Making it a data type breaks huge functionality that is key to linking SBOMs to other enterprise activities.
Bob
From: Spdx-tech@... <Spdx-tech@...> on behalf of David Kemp <dk190a@...>
Sent: Tuesday, November 8, 2022 10:31:42 AM To: SPDX-list <Spdx-tech@...> Subject: [EXT] [spdx-tech] Actor datatype Punchlist item: Last week we decided that Actor should have always been a datatype rather than an Element as previously shown on the model diagram. The Actor datatype should label its identifiers without requiring any association with Identity elements. This example File element shows how "creator" looks with "Identifier" having a specified syntax (name, email, uri, ...) and Actor being an Identifier having a specified subject type (person, organization, tool, any): { "id": "urn:acme.dev:artifacts:gnu-coreutils/v9.1/src/du.c", "type": { "file": { "filePurpose": ["APPLICATION", "SOURCE"] } }, "creator": [ {"person": {"email": "fred@..."}} ], "created": "2022-04-05T22:00:00Z", "specVersion": "3.0", "profiles": ["Core", "Software"], "dataLicense": "CC0-1.0" } |
|
|
|
David Kemp
William can confirm, but I believe his rationale was that subelements of Identity (Person, Organization, Tool) would be used in conjunction with relationships to capture complex concepts (such as giving names to a group of identifiers, mapping identifiers to identities over specified time periods, etc.) for use cases needing that information to be captured in BOMs. For simple v2 use cases and backwards compatibility, the actor identifiers are sufficient. Identity elements can optionally enrich each identifier either within BOMs where they appear or be created at a later date. David On Tue, Nov 8, 2022 at 12:05 PM Robert A Martin <ramartin@...> wrote:
|
|
|
|
William Bartholomew (CELA)
David's correct. The actor is a lightweight data type that can capture the name and identifiers observed performing an action in the supply chain. If you want to capture additional information about the actor, then you can link it to a subclass of identity
that is then a full element. This helps avoid a circular dependency with the creator.
If we wanted to, we could go a step further and:
This would allow you to use SimpleActor if you want the lightweight representation, it still allows you to use an Identity where an Actor is expected, and tools can just code against the Actor interface if they don't need any of the extra information from
the identity.
Regards,
William Bartholomew (he/him) – Let’s chat Principal Security Strategist Global Cybersecurity Policy – Microsoft
My working day may not be your working day. Please don’t feel obliged to reply to this e-mail outside of your normal working hours. From: Spdx-tech@... <Spdx-tech@...> on behalf of David Kemp via lists.spdx.org <dk190a=gmail.com@...>
Sent: Wednesday, November 9, 2022 8:44 AM To: SPDX-list <Spdx-tech@...> Subject: [EXTERNAL] Re: [spdx-tech] Actor datatype William can confirm, but I believe his rationale was that subelements of Identity (Person, Organization, Tool) would be used in conjunction with relationships to capture complex concepts (such as giving names to a group of identifiers, mapping
identifiers to identities over specified time periods, etc.) for use cases needing that information to be captured in BOMs.
For simple v2 use cases and backwards compatibility, the actor identifiers are sufficient. Identity elements can optionally enrich each identifier either within BOMs where they appear or be created at a later date. David On Tue, Nov 8, 2022 at 12:05 PM Robert A Martin <ramartin@...> wrote:
|
|
|