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:
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"
}



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:
  1. Create an Actor interface (that has name, externalIdentifiers, ...)
  2. Have the Actor class implement the Actor interface
  3. Have the Identity class also implement the Actor interface
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:

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"
}