represent a SPDX cryptographic algorithm in SPDX 3.1 cryptographic algorithm list?

[stevenc-stb]

Issue:
How do you represent a SPDX cryptographic algorithm in SPDX 3.1 cryptographic algorithm list? https://github.com/spdx/cryptographic-algorithm-list.

Option 1:
Will we use the expanded licenses profile as a template for the cryptographic algorithm class?

Option 2: (Current plan)
Use the algorithm ID, version of the cryptographic algorithm list, and parameters dictionary from the SPDX cryptographic algorithm list to select and attach the algorithm.
#1224

@bact @zvr @goneall What are your Thoughts?

[bact]

The situation of SPDX License List is also not very clear to me.

While SPDX License List provides SPDX License IDs, like "0BSD" for BSD Zero Clause License, and standardized license URLs, like https://spdx.org/licenses/0BSD.html or https://spdx.org/licenses/0BSD, I don't think these IDs or URLs get any special treatment in the System Package Data Exchange format (I use the full name here, to distinguish the exchange format from the project name; the project name is also used for the license list).

While the BSD Zero Clause License is a "listed license" (listed on the SPDX License List), the https://spdx.org/licenses/0BSD.html URL will not be automatically seen as a ListedLicense in an SpdxDocument. You can't just use https://spdx.org/licenses/0BSD.html as a "to" for hasConcludedLicense relationship without define it somewhere within the SpdxDocument or declare that it is external, or the validation will failed because the validator can't decide if https://spdx.org/licenses/0BSD.html is AnyLicenseInfo of not. (See: #956; SPDX Java tools and Python tools treat this differently, see spdx/tools-java#290 ; the SPDX 3.0 spec for the exchange format does not say anything about this).

Each license in SPDX License List can be described using vocabulary from SPDX 3.0 (see https://github.com/spdx/license-list-data/blob/main/jsonld/0BSD.jsonld for example), but it is unclear to me how an SPDX document can use those data.

Requesting the listed license URL does not return a machine-readable data.

It would be interesting if we request, thru content negotation:

curl -H "Accept: application/json" https://spdx.org/licenses/0BSD

and get content similar to https://github.com/spdx/license-list-data/blob/main/json/details/0BSD.json

Or request:

curl -H "Accept: application/spdx3+json" https://spdx.org/licenses/0BSD

and get content similar to https://github.com/spdx/license-list-data/blob/main/jsonld/0BSD.jsonld

[zvr]

Option 1 is the way to go — that is the whole point of creating and maintaining the list. Let me describe how this should work (and referencing the existing License stuff in parentheses as examples).

We have and maintain the AlgoList —apologies, I'll use some abbreviations to save typing—, which has entries for different algorithms, and each entry has an "id", a short name to identify an algorithm (the SPDX License List includes licenses with short identifiers).

Each entry on the list essentially becomes an "Individual", a published object, denoting an algorithm. (For example, each license is in the form https://spdx.org/licenses/<id>. You can see the definition of an SPDXv3 license in the example of 0BSD. I actually think that there is an error and spdxId should be @id but I'm not an JSON-LD person). Similar to those, there might be something like https://spdx.org/crypto-algo/SHA-1.

Other SPDX data that want to refer to such an algorithm, they will use the well-known URI for it, since all references in RDF happen by URIs (if someone wants to refer to a license, they use https://spdx.org/licenses/0BSD, for example).

What needs to be done:

1. In the model, there should be a class definition of ListedCryptoAlgo, with the properties defined in the algo data repo. This will be the type of the published objects (similarly, there is ListedLicense).
2. You should also define a way for people to refer to an algo that is not in the list (there is CustomLicense)
3. It makes sense to have a superclass of those two, so that any use (reference) has an easy way of saying "this should be a listed or unlisted algo" (there is License, with subclasses the previously mentioned ListedLicense and CustomLicense)
4. And there should also be RelationshipTypes (probably) or properties (unlikely) that will connect or have as values instances of these Algo classes (like DeclaredLicense or ConcludedLicense). I don't know what information needs to be expressed regarding the crypto algorithms. I assume Package IMPLEMENTS Algo is one.

I strongly suggest that these additions are part of a separate (new) Profile.

Hope this helps,

[bact]

Note that referencing to a well-known URI of ListedLicense is currently failed the SHACL validation. See #956