Proposal: Add `package_url` and `package_provider` to CPS supplemental schema

[bryonbean]

Summary
Request to add two new CPS Supplemental properties: package_url and package_provider.

These supply provenance and discovery metadata that help consumers trace, reproduce, and report package origins.

This proposal grew out of spdx-to-cps, where we saw a need to represent provenance fields.

As noted in CMake issue #27128:

"Sbom generation would like to list all the information it can, including each dependencies Description, PackageUrl, Website, and License."

This proposal addresses the need for package_url (canonical retrievable source) as well as package_provider (ecosystem identifier).

---

Motivation / Problem
Currently, CPS packages contain metadata about the package name, version, and requirements, but lack a standardized way to indicate:

• Where the package can be retrieved from (URL, registry, distribution archive, etc.).
• Which provider or ecosystem is responsible for the package (e.g., vcpkg, Conan, system package manager).

This information is important for:

• Reproducibility: tools or humans can trace back to the original distribution.
• Provenance: consumers can validate where a package was sourced.
• Ecosystem integration: enabling bridges between CPS and existing package ecosystems.

---

Proposed Specification Changes (Supplemental)

1. package_url

   • Type: string

   • Applies To: package

   • Required: No

   • Semantics:
     A URL pointing to the canonical location of the package.
     This may be:

     • A fetchable VCS or distribution URL, e.g.:
       git+https://github.com/madler/zlib@v1.3.1
https://example.com/foo-1.2.3.tar.gz,
     • A canonical identifier (e.g. purl spec).

     At present, the spdx-to-cps script emits git+https://... style URLs.

   • Example:

     {
       "package": {
         "name": "zlib",
         "version": "1.2.11",
         "package_url": "git+https://github.com/madler/zlib@v1.3.1"
       }
     }

   Distinction from website:

   package_url identifies a canonical retrievable source for the package (e.g., VCS URL, distribution archive, or purl), while website is informational and intended to point to a project or package homepage for human use.

2. package_provider

   • Type: string

   • Applies To: package

   • Required: No

   • Semantics:
     The ecosystem or distribution source that supplied this package.
     Intended values may include vcpkg, conan, system, spack, etc.
     Tools can use this to customize resolution strategies or provenance reports.

   • Example:

     {
       "package": {
         "name": "zlib",
         "version": "1.2.11",
         "package_provider": "vcpkg"
       }
     }

---

Compatibility

• Additive change, backward compatible.
• Existing consumers that do not recognize these properties may safely ignore them.
• If accepted into the Supplemental Schema, tools MAY support them.

[pombredanne]

@bryonbean Hi! I maintain the Package-URL spec. Let me comment on this!

[bryonbean]

@bryonbean Hi! I maintain the Package-URL spec. Let me comment on this!

@pombredanne Please do.

[mwoehlke]

This seems reasonable. A PR would not be amiss. 🙂 (Note: this likely belongs in the supplemental schema.) My only "concern" would be that package_provider probably would benefit from better specification of "allowed" values.

@pombredanne, did you have comments?