Makes sense. Thank you for taking a look at this.
Regards,
Omar
On Nov 29, 2018, at 12:17 PM, Eric Johnson <
eric@tibco.com > wrote:
Hi Omar,
On Thu, Nov 29, 2018 at 9:14 AM Omar Santos (osantos) <
osantos@cisco.com > wrote:
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 .
https://lists.oasis-open.org/archives/csaf/201811/msg00001.html 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.
Eric.
I was trying to suggest something like:
"standard_product_id": {
"type": "#/cpe/swid/purl/co-swid"
"$ref": "#/definitions/non_empty_string_t"
}
I think that it is basically the same as you are suggesting.
Regards,
Omar Santos
Cisco PSIRT
Email:
os@cisco.com PGP Key: 8E19A9D13AF27EDC
On Nov 29, 2018, at 12:00 PM, Eric Johnson <
eric@tibco.com > wrote:
Hi Omar,
Sorry I didn't manage to get off a response to this before our meeting yesterday.
On Tue, Nov 27, 2018 at 5:31 PM Omar Santos (osantos) <
osantos@cisco.com > wrote:
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:
https://github.com/oasis-tcs/csaf/blob/master/sandbox/csaf_2.0/json_schema/csaf_json_schema.json 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?
Eric.
" 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
},