This is solved by having a secondary definition for Other, which requires the inclusion of things such as a human readable reference page and a JSON or XML Schema URI. Not JSON.. Product ID Vector: <ID String>  Type: [CPE | SWID | SPDX | <ECT> | OTHER]  ID String Version: <Version String>  Vendor Product Name: <Common Public Name>  Version: <Version String> Type Schema: <Schema URL>  Note: <Free Text> Documentation: <Documentation URL>  Note: <Free Text> Something like that to replace the CPE ID field. Things that show up other than one of the expected values can certainly be added to the validator by minor revs as we produce them. -Troy PGP Key ID: 0x7B31ED20 From: <csaf@lists.oasis-open.org> on behalf of "Omar Santos (osantos)" <osantos@cisco.com>
Date: Thursday, November 29, 2018 at 12:32 PM
To: Eric Johnson <eric@tibco.com>
Cc: "csaf@lists.oasis-open.org" <csaf@lists.oasis-open.org>
Subject: Re: [csaf] Generic Software Identification Parameter/Attribute to be included in CSAF 2.0 schema. Makes sense. Thank you for taking a look at this.
Hi Omar, Thank you Eric! I like your suggestion. The main challenge that I was trying to address is that we cannot predict when the next software bill of material (SBOM) standard will be created. If we provide the ability to strictly define cpe, SWID, SPDX, etc, what happen when the next standard format is created? For instance, the example that Art mentioned around âpurlâ.
I think the standard answer there is simply to add another property, as it is deemed useful. In contrast to XML, where an extra element in a schema creates massive backwards compatibility problems (at least when attempting to validate using XML Schema), merely adding an additional property to a JSON object is pretty much a no-brainer. I was trying to suggest something like: "type": "#/cpe/swid/purl/co-swid" "$ref": "#/definitions/non_empty_string_t" I think that it is basically the same as you are suggesting.
Hi Omar, Sorry I didn't manage to get off a response to this before our meeting yesterday. This is to continue the discussion related to a Generic Software Identification Parameter/Attribute to be included in CSAF 2.0 schema. The following is the current CSAF 2.0 draft schema: Under full_product_name there is a CPE property. Replacing CPE for âstandard_product_identifierâ (or similar) may be the best place. Then the $ref: could be to a pointer to a SWID, CO-SWID, SPDX, etc docâ Thoughts or suggestions?
Due to the expectations and processing model behind JSON, I don't see the need or value to be generic. Put differently, in a JSON instance, the product definition could have a property for cpe, swid, spdx. The JSON schema could then more readily validate the corresponding value the property with a regular _expression_ match, at least. That also gives us the freedom, in some ideal future, to decide that one of these properties might be required, while the others could continue to be optional. So instead of having "standard_product_identifier" as a property, and then have the implementation required to distinguish the kind of identifier based on the value, why not have "cpe", "swid", "co_swid", "spdx" as distinct properties? "full_product_name_t": { | | "type": "object", | | "required": [ | | "product_id", | | "text" | | ], | | "properties": { | | "product_id": { | | "$ref": "#/definitions/non_empty_string_t" | | }, | | "text": { | | "$ref": "#/definitions/non_empty_string_t" | | }, | | "cpe": { | | "$ref": "#/definitions/non_empty_string_t" | | } | | } | | }, | | "non_empty_string_t": { | | "type": "string", | | "minLength": 1 | | }, |
|