Design for PURL type for software without a registry

[mjherzog]

This Discussion item captures the historical commentary from:

• Add new PURL type for non-packaged software #516 organized by topics - one comment for each topic.

Note that the commentary for these topics does not include the author of each post in order to keep the commentary succinct.
Please comment by topic or create a new comment thread for a new topic.

[mjherzog]

How do you validate the vendor name and domain combination?

Why is validation needed?

• I don't think CPE validates the vendor, product name, etc. fields. In most cases, the creator of the scid tag will be the creator of the software, and they are presumed to be the authoritative source for the values of these fields.

• Because consumers of software identifiers need consistency in product naming.

• I don't think CPE validates the vendor, product name, etc. fields. In most cases, the creator of the scid tag will be the creator of the software, and they are presumed to be the authoritative source for the values of these fields.

  • As I understand it, NVD does attempt to do so. CPE also provides a great case study on naming drift over time as well by way of the deprecated CPEs. NVDs attempt at managing the namespace is clearly imperfect, but I take as an assumption that a goal of this purl type is to do better than CPE. Is that an accurate assumption?
  • The NVD has never provided a guide to how they put together CPEs. Some CNAs complain that the NVD staff ignore the information they include in the CVE record and substitute their own, with no explanation why they chose the items they did.

  PURL is essentially self-validating. For example, a PURL might include just the package manager, product name in the package manager and version string. Anybody can go to the package manager and verify what's in the PURL. There's no way to do that with CPE.

  Of course, it would be a good idea for the CVE Program to validate the components of the PURL in a new CVE record (and I think there is code available to do that automatically, although it will probably be type specific).

  • Indeed. Accurate and consistent naming is difficult. However, this proposal (as I understand it) is to replace an imperfect naming normalization system with no system and that feels like a downgrade.

  How does that work for this proposed type which has no package registry?

  You might take a look at the document on PURL and the NVD that the OWASP SBOM Forum wrote in 2022.
  https://owasp.org/assets/files/posts/A%20Proposal%20to%20Operationalize%20Component%20Identification%20for%20Vulnerability%20Management.pdf

  • Nobody is replacing CPE. It will die on its own. This PURL type simply does not have a registry. There is nothing in the PURL spec that mandates that PURL types MUST have a registry where packages are located. The PURL spec utilizes RFC 2119 / 8174, but a mandatory location is not among them. If your objection is the inability to verify that a package name is valid or not, I would suggest improvements to the core PURL spec itself, not this PURL type.

  If the core PURL spec mandates location, it will make this PURL type, and all current and future PURL types that do not rely on registries, invalid.

[mjherzog]

What are the namespace constraints for the scid PURL type?

• My concern with this type is that there doesn't seem to be a namespace constraint. I see nothing to ensure that consistent names are used over time as people come and go at acme corp.

• That is currently an unsolved problem anyway. Again, this PURL type is designed for non-packaged software. From an inventory management perspective, most enterprises track their software using SWID or random names of vendors and products. There is zero consistency already. CPE is not used in ITAM or SAM. It is solely restricted to vulnerability management use cases. Its adoption outside of that niche is non-existent. The software industry does not have the equivalent of a global registry like the hardware industry does with GS1. SWID used to have tagvault, which would have provided a global registry for commercial and non-packaged software, but the company behind it folded.

  There are multiple PURL types, including generic that do not require a registry. Any change that mandates a registry would be a breaking change and not be available until PURL 2.0.

• Could the following be considered?

  • addition of a < vendor-specific-namespace > to < namespace > so that
  • namespace is < domain >/< vendor >/< vendor-specific-namespace >

  Resulting in the following format for scid :

  pkg:scid/< domain >/< vendor >/< vendor-specific-namespace >/< component >@< version >?arch=< arch >&edition=< edition >&target=< target >&locale=< locale >

  This will give the vendor the possibility to categorize their components as they see fit.

• The PURL spec already allows multiple segments within the namespace component so your idea is supported but I am not sure that this should be specified for the new PURL type overall - it could be implemented per publisher with their registration of a namespace within the new PURL type.

[bact]

Should locale support BCP 47 extensions (Extension T and Extension U) as well?

BCP 47 Extension U (RFC 6067) is needed if we to support information beyond language - like digit and calendar systems.

For example, Sun/Oracle Java SE 8 has a ja_JP_JP locale variant that uses Japanese imperial calendar as default calendar. https://docs.oracle.com/javase/8/docs/technotes/guides/intl/calendar.doc.html This could be expressed in BCP 47 with Extension U as ja-JP-u-ca-japanese.

Or for these Java 2 SE v.1.2.2 Thai Localization from http://www.sun.co.th/developers/thailand (wayback machine), their locale qualifier could be th-TH.

Update: I proposed this a PR here: #857

[mjherzog]

Is the sid PURL type intended to replace CPE?

• Nobody is replacing CPE. It will die on its own. This PURL type simply does not have a registry. There is nothing in the PURL spec that mandates that PURL types MUST have a registry where packages are located. The PURL spec utilizes RFC 2119 / 8174, but a mandatory location is not among them. If your objection is the inability to verify that a package name is valid or not, I would suggest improvements to the core PURL spec itself, not this PURL type.

  If the core PURL spec mandates location, it will make this PURL type, and all current and future PURL types that do not rely on registries, invalid.

• The goal of the sid PURL type is to provide a means to identify non-packaged software, especially including commercial products. CPE won't go away, and any CNA that wants to stick with CPE is welcome to do so. However, since it looks possible that NIST may stop creating CPE names, the CNAs will probably need to start creating their own CPEs (which will include updating the CPE dictionary).
  If a commercial developer wants to start using the scid PURL type (and one huge developer said in the OWASP SBOM Forum meeting today that they will adopt sid), they won't need to update a central database or registry, since the contents of the sid tag are whatever they want to make them.

• Is the intent that it will only be used internally?

  • No, the point is that the developer (supplier) of the product should normally be the authority, so whatever they put in their SCID tag needs to be taken at face value. Even if they've previously called the product ABC but they now call it XYZ, as long as the tag came from the supplier of the product, it needs to be considered authoritative.

• How does one validate the origin of the tag?

  • You get it from the supplier.

[mjherzog]

Who is responsible for software naming under the sid PURL type?

• I do not think it is the responsibility of a specification to enforce how people name things. If an organization wants to utilize this PURL type, they should have a standard operating procedure for how to do that. This is something that the PURL community may be able to work on.

• Most of the PURL types do enforce naming though. I would observe that consistent naming is the whole point of this identifier exercise. Is zero consistency desirable/acceptable?

• The Id is not useful for the provider/producer. It's useful for the product consumer, to automatically discover the vulns it's affected by, with its list of Ids such as an SBOM.

  If a commercial developer wants to start using the sid PURL type (and one huge developer said in the OWASP SBOM Forum meeting today that they will adopt sid), they won't need to update a central database or registry, since the contents of the sid tag are whatever they want to make them.

  The (promised) killer feature of purl is that they can be automatically generated in a deterministic, reproducible manner. If PURLs require a central database (even worse one database per producer) and/or are not deterministic since "they can be whatever [the producer] want to make them" without warning ...this promise is broken, and they are not useful to me as a consumer of non-packaged software. In my understanding this is also the point of the "Proposal to Operationalize Component Identification for Vulnerability Management" from the The SBOM Forum in 2022, with its concept of intrinsic vs extrinsic Ids. Purls are supposed to be intrinsic. This would make them extrinsic, a major design goal change.

  This would be very similar to CPE, with the enhancement that CNA (producers) (or discoverer of the flaw, to complicate the matter) would be able to short-circuit the sluggish dying NVD and allocate their own Ids. This would solve the pain point of attribution from a central sluggish NVD. The CPE or SWID or PURL or SWID in a PURL format does not matter for this pain point.

• There will be no central database required for PURL since the PURLs are verifiable through a single source of truth. Currently, that's usually the package manager where the product is found. Anyone who wants to verify the PURL just has to check the package manager.

  In the case of software not found in package managers, including most commercial software, the supplier creates the tag. They can put whatever they want on the tag, since it is the single source of truth. If they originally named the product "Joe's browser" but they accidentally entered "Jose's browser" on the tag, that is the name that needs to go in the PURL, unless the supplier wants to go to the trouble of finding every existing tag for the product and replacing it with one with "Joe's software".

  In other words, the supplier has the final word on the contents of the sid tag. However, if the supplier never creates a tag for a product and somebody else does, they will have the final word.

[mjherzog]

Is TEA a solution for verifying a sid PURL?

• Based on the discussion at today’s Transparency Exchange API (TEA) meeting, I believe this kind of PURL could be verified using TEA Discovery. Here’s a potential approach:

  • Usage of this PURL format could be limited to vendors that operate a TEA Service. The TEA specification is being designed to remain lightweight and accessible, enabling even individual GitHub users to run a compliant TEA Service.
  • Domain binding: The domain field in the PURL could correspond to the domain used in TEI URNs. The current TEA specification does use the domain for discovery and we share the concern that losing control of a domain can impact verifiability. However, future enhancements to the discovery mechanism could support fallback or archival methods that allow continued verification of old products, even if the original domain is no longer under the vendor’s control.
  • Vendor binding: The vendor field could map to a new vendor property in the TEA Product object, allowing clear association and validation.

  This approach avoids the need for a centralized registry while still supporting verification and trust through decentralized, domain-bound TEA Services.

• If I'm reading this correctly a tl;dr might be that TEA describes how to make json formatted documents available which describe software components. Assuming that's correct I believe that you're proposing that the sid PURL type requires a TEA server to be embedded in it in the domain field so that a consumer of some record (sbom/cve/whatever) knows where to do a lookup of the sid and to derive information from. The flow could be:

  • I read a PURL: pkg:scid/coolbeans.biz/coolbeansInc/beancooler@1.2.3 from an sbom/cve/whatever
  • I query coolbeans.biz using TEA for information about beancooler
  • Maybe I get a list of internal components
  • Maybe I just care about checking that the name is canonical (or exists)
  • Maybe something else, but I have an authority to check against for whatever questions I have

• That's a reasonable understanding. The only correction that I would make is that the sid PURL type will not require TEA. It can be used independently. But if the domain has a TEA server, then a lot more information would be possible to retrieve about the PURL.

• The TEA Component Release object contains enough data to allow users to download a software component (like in the example below). While a full TEA server might be overkill to define sid, we could align some structures between TG1 and TG2. See Add new PURL type for non-packaged software #516 (comment) for the example

• Rather than introduce .well-known/purl-locator.json, it would make sense to offload discovery capability to TEA, which already has a mechanism to handle such metadata (particularly, it can grow very large).

• Working on the discovery mechanism in TEA took a while. We already have .well-known/tea which is just a pointer to the actual TEA server(s). I strongly believe that trying to recreate this with another mechanism would lead to confusion of people trying to adopt PURL/TEA (something I'm seeing already) and also duplication of effort.

  Some more details: even for a very small (<10 employees) organization, the number of releases can easily be in the range of a few hundreds per month. For large organizations this would be on the order of tens or hundreds of thousands of releases per month. This dynamic will lead to realization that it's impossible to fit all these data into a single JSON file, which would likely then lead to some attempt to recreate TEA.

[mjherzog]

What are some alternatives for discovering the location of a package?

• Please consider including a "downloadLocation" data element in sid that contains a valid URL.

• The location of a supplier PURL "registry" could be a PURL qualifier.

• A SCITT Product Trust Registry could easily support PURL identifiers the same way that URLs are already supported.

• We had to replace PURL strings with a simplified "product data string" (PDS) in order to support products in the US Cyber Trust Mark Label program. A PDS is simply a string containing "SupplierName/ProductName/ProductVersion" that is used to create a unique product ID using a SHA-256 hash over the PDS file.

  The PDS is sufficient for the US Cyber Trust Mark Label. We did not need the "download" semantics of PURL, we only needed a unique product ID, so the PDS works well in these cases.

• The domain used in a sid PURL can double as a mechanism to discover the location of packages.

  For example: pkg:scid/example.com/Acme/AcmeApplication@1.0.0. In this case, we could simply do a lookup to .well-known/purl-locator.json at the domain specified, such as: https://example.com/.well-known/purl-locator.json

  Which would return a JSON document of all the packages for the example.com namespace - see Add new PURL type for non-packaged software #516 (comment) for the JSON example

  The benefit of this approach is that:

  • Package location can be achieved for scid types, which are, by design, not associated with a traditional package repository (although they optionally can be)
  • Location information is completely decentralized, much like the PURL spec itself, allowing each entity/organization full control over their location information, including what they want to publish, when, retention, and the ability to have full control if the storage location ever changes (e.g. hostname or URL changes)
  • The JSON schema above is purely an example which we can iterate on separately. My goal is to simply get consensus that this approach is viable and if so, we can flush out the details of the JSON schema in the future.

• I very much like the idea of the domain of the id being used to infer a pattern by which some reader can list valid names/validate/disambiguate. I'm neutral on the purl-locator.json vs TEA server. Maybe a purl-locator.json could provide a TEA server or vice versa.

• I think this is fine for OSS not distributed through package managers, but I don't know how it's relevant for commercial software - except possibly for the case of software in app stores, which as you have pointed out could probably be treated like OSS in package managers (with a type for each app store).

  For commercial software not in app stores, someone wanting to download an app first has to conclude a financial transaction with the vendor before they can download the software (unless it comes on floppy disks, of course). Presumably, once they have paid for the software - or been invoiced for it - the vendor will tell them how and from where to download it.

  Which brings up another point: I think there should be two sid types (or more correctly, two different types): one for commercial software (for which the PURL is discovered as in my previous comment) and one for C/C++, etc. It seems that a universal PURL registry might be the best way to have a controlled namespace for the latter, but it would never work for commercial products. To have a controlled namespace for commercial software, the vendor can have a PURL registry for their own products and/or a TEA server.

• We do not want to mix assumptions with the business model with the development of the spec. There are many instances of limited functionality, freemium, or developer-only licenses on essentially the honor system, where commercial artifacts can be downloaded before a financial transaction occurs.

  Even if a transaction is required, this is actually a benefit to the commercial entity as they can have independent access control on those download links, asking users to sign-up or whatever their prospect funneling looks like. The spec would just have the location information. It doesn't assume that the download URL is accessible to anonymous persons like most package repositories are. We should likely make that explicit in the spec though.

• I'm not saying there has to be a financial transaction for commercial software. I am saying that, unlike with OSS in package managers, when someone wants to download a commercial product (which isn't sold through an app store), they can't just go to a URL and download it. Some person (or bot) needs to give them permission to download the product. The user won't be able to download it unless it's been pre-approved. In most cases, permission will only be granted if there has been a financial transaction, but that's certainly not always true, e.g. for a trial version of the software. However, a person or bot always has to give permission before the user can download the software.

  Commercial software in app stores (assuming your idea that app stores could be treated like package managers is accepted by the PURL community) is different, since the financial transaction is built into the download process. As long as someone can present a valid credit card, they can download the software - no human or bot has to give permission for the download. Sometimes, the "transaction" is for $0, but the customer still has to agree to some sort of terms and conditions. When they do that, they can download the software.

  You mention download location. Are you saying that would need to be part of the sid PURL type definition? I hope not, since I don't think that's needed. For software in app stores, the user already knows the download location (also for software in package managers). For software not in app stores (the first case above), the fact that a human or bot needs to give permission for the download means they will provide the download location to the customer (in any case, I don't think there's a single download location for all products by a software vendor that doesn't sell through app stores, like Oracle - so it couldn't be in the spec).

[mjherzog]

Is a download location required in a sid PURL?

• A download location is not needed if you just need to create a unique product identity. This was discussed extensively when the NTIA SBOM Framing document was created.

• A download URL location is not required to use PURL as a software identifier. In addition to the commercial "paywall" use case you have the "internal" use case where you cannot download the software as an external party. For the package managers you have the extra benefit that you can often derive a download URL from the base PURL, but that should not be required to use PURL as an identifier.

  There are also likely more use cases where you might specify a 'download_url' in qualifiers that is not public. It would be nice to have some way to alert PURL tools and users to non-public download URLs in general - e.g. you could also have a private 'repository_url' in qualifiers.

• PURL inherently implies a download location with the pkg:type

• The type component of PURL only implies a download location when the type is for a package manager like npm, etc.

• The sid type could default to no location information (so identity only and no download location) UNLESS purl-locator.json is discovered. In such a case, then that could be used. I believe the purl-locator.json should not be part of this PURL type, but rather, included in the appendix of the specification, because it's entirely optional and could theoretically be used by other PURL types going forward.

• The default for this PURL type should be identity only because, unlike package managers, we need primarily to cover the software identity use case with an option to provide location information using qualifiers or a mechanism like purl-locator.json. For commercial or internal-use/first-party software the download location will often not be public unless you are a customer or a member of the first-party organization.

[mjherzog]

What should be the method of metadata distribution for the sid PURL type?

• Why should the sid type have to endorse one method of metadata distribution vs. another? A supplier should get the data out any way they can: TEA server, PURL locator, email, website, carrier pigeon, full page NY Times ad, etc. The more, the merrier.

• Optionality on the supplier side becomes a maintenance burden on the consumption side. More options => more code paths => more edge cases and bugs. Keeping things simple gives them a greater chance of success when people start pushing data out.

• The spec shouldn't require just one method of distribution. The important thing is that, no matter how the sid metadata are distributed, the method needs to provide an easy way to verify that the information came from the supplier, if they feel they need to do this.

  For example, if the supplier emails the metadata for a new version of a product to all customers of that product and the user notes that the email address matches the one used in previous emails from this supplier, they should be able to accept that as validation of the metadata. They should not be forced to utilize a TEA server, require that the supplier encrypt the emails, etc. If this were vital national security information, such requirements might be necessary. But it's not.

• The burden for software location on the consumption side seems to be unavoidable given that this proposed PURL type is intended to cover such a wide variety of public and private distribution modes. We should offer something like purl-locator.json as a recommended option but the PURL community cannot manage or police software distribution channels. We would want a clear explanation of how you can use PURL and TEA together but we should minimize the overlap.

[mjherzog]

Do we really need a registry for sid PURLs?

• Do we really need a registry? The purl-registry repo looks like a nice place to list early adopters, but it will not scale to thousands of namespaces. Since C/C++ packages and commercial software has never been resolvable to an URL before anyway, we should split this issue into two parts:
  • sid syntax definitions: we should concentrate on fixing the syntax of the sid PURL type first. This way users can use those identifiers on their download page and in their CVEs, while consumers can add them manually to their SBOMs. purl-registry could be just a list of URLs that documents how each publisher formats their scids.
  • sid resolution: whether and how sids could be resolved to the URL to a file, should probably be tracked in a separate issue.
• The idea of the namespace registry is voluntary and intended to help esp. FOSS projects that want to take advantage of it.
  • Agreed about the syntax definition, but the primary purpose for a PURL is as an identifier not a locator (URL). In any case, the logical approach is that 'base' test_group tests (for ECMA-427 conformance) would only require syntactic correctness. 'Advanced' test_group tests could optionally validate whether a namespace is registered. This is the same approach as planned for registered namespaces for the 'deb' and 'rpm' PURL types. See also: Schema change / purl-type-definition: Add enum for namespace values #690
  • Resolution to a URL is likely to be handled by qualifiers.

[mjherzog]

@stevespringett
@pombredanne
What do you think of changing the type from 'sid' to 'software-id'? This would make the *type self-explanatory to most consumers and avoid yet another acronym.

[mjherzog]

This post by Mark Nottingham - "one of the authors of the Well-Known URI specification and current Designated Expert for the registry - seems relevant to the proposed use of /.well-known/ files for this PURL type.

So You Want To Define a Well-Known URI

[VanL]

FYI, I synthesized a pkg:sid specification similar to the others based upon my reading/synthesizing of this discussion:

PURL sid type proposal

Last updated: 2026-06-19
Status: synthesis draft from purl-spec discussion #841 for Package URL
working group review
Scope: pkg:sid - identity for distributed software without an
authoritative package ecosystem; commercial products, proprietary binaries,
standalone open source releases, and other non-registry software identifiers

Overview

Package URLs are widely used as stable identity for packages in known
ecosystems. The standard PURL types work well when an authoritative package
registry, repository host, app store, or service/product type owns the naming
rules. They do not cover a large class of software that is distributed and
installed, but not through one of those ecosystems: commercial desktop or server
software, proprietary binary products, standalone open source releases, legacy
platform distributions, localized install media, and similar products.

This proposal defines a PURL type, pkg:sid, for that class. The design is a
synthesis of purl-spec discussion #841 and the original scid proposal in
purl-spec #516. It uses sid because the discussion has moved from scid
("Software Component Identification") toward the shorter "software id" spelling,
while preserving a note that the working group may still choose another final
type string such as software-id.

Motivation (why now). CPE is still the dominant identifier for vulnerability
matching on commercial and non-packaged software, but it depends on central
curation and has known naming drift. If NIST reduces or stops creating CPEs,
CNAs, suppliers, and consumers will still need identifiers for the same class of
software. pkg:sid gives that work a PURL-shaped lane: decentralized,
URI-friendly, compatible with SBOM and vulnerability tooling, and explicit about
the fact that there is often no registry to query.

Design principles

Four principles govern every decision below. The per-decision rationale notes
refer back to them.

1. Use an existing PURL ecosystem when one exists. sid is not a generic
   fallback for hard cases. If the referent is published through npm, PyPI,
   Maven, Docker, OCI, GitHub, an app store type, service, private, or any
   other more specific registered type, use that type.
2. Authority is carried by the first namespace segment. Most PURL types are
   self-validating through a package registry. sid cannot be. Its authority is
   the party that publishes or asserts the identifier, usually the software
   supplier. That authority should be expressed as a self-asserted domain in the
   first namespace segment, and may instead be a registered registry namespace.
3. Identity is not download location. A sid PURL identifies software and
   its release/distribution facets. It does not require a public download URL.
   Commercial and internal software often requires authorization before any
   download location is useful.
4. Build and distribution facets are identity-bearing only when they select a
   different artifact or product distribution. Architecture, edition, target
   environment, locale, and subpath are useful only when they narrow the
   referent. They shall not encode runtime configuration or assessment state.

Relationship to ECMA-427

ECMA-427 defines the seven-component form:

scheme:type/namespace/name@version?qualifiers#subpath

For this type:

• scheme is always pkg.
• type is sid.
• namespace, name, version, qualifiers, and subpath keep their
  ECMA-427 component roles.
• There is no URL authority. Host-like strings in namespace are owner or
  asserter namespaces, not URL hosts.
• subpath keeps the standard meaning: a relative path inside the named
  software distribution.

As of this draft, sid is not a registered PURL type. The historical proposal
used scid; discussion #841 also raises software-id as a possible clearer
name. This document specifies semantics for the sid spelling unless and until
the working group chooses a different type string.

Verbal forms

This document uses the verbal forms of the ISO/IEC/Ecma drafting conventions:
"shall" and "shall not" state requirements, "should" and "should not" state
recommendations, and "may" states permission. "can" and "cannot" state
possibility or capability. The keywords are not capitalized, and "must" is not
used as a normative term.

Scope and type selection

Use pkg:sid when the referent is distributed software and no more specific
PURL type owns its identity:

• commercial or proprietary software products distributed outside package
  ecosystems
• standalone open source projects or releases not authoritatively available
  through a registered package, VCS, or app store PURL type
• binary-only or installable software with no registry-backed package identity
• operating system or application distributions that need CPE-like matching
  facets such as architecture, edition, target environment, or locale
• supplier, distributor, or CNA asserted product identifiers for vulnerability,
  inventory, and compliance workflows

Do not use pkg:sid when another type applies:

• Use ecosystem types such as pkg:pypi, pkg:npm, pkg:maven, pkg:docker,
  pkg:oci, pkg:github, or pkg:huggingface for software distributed through
  those ecosystems.
• Use pkg:service for hosted services, SaaS products, model APIs, managed
  platforms, and service-shaped referents with no distributable artifact.
• Use pkg:private for first-party repository software that exists in an
  organization's private workspace and is asserted by that owner.
• Use a future app store type when the app store is the authoritative
  distribution ecosystem.

Boundaries with neighboring identifiers:

• vs CPE: sid is not required to replace CPE. It is intended to cover the
  same vulnerability and inventory matching need in a decentralized PURL form.
• vs SWID: sid is a lighter identifier. It does not require a SWID
  tagId and does not try to model a full SWID tag.
• vs generic: generic lacks authority, naming, and build-facet
  semantics. A generic PURL can name something, but it does not provide the
  CPE-like axes sid is designed to carry.

Identity model

The root identity is assertion-scoped:

identity = asserter domain + vendor identifier + component name
           (+ version)
           (+ distribution facets)

More specific identities may narrow the root with qualifiers and subpath:

Level	Form	Meaning
Component	pkg:sid/example.com/acme/beancooler	The asserted component identity without a pinned release. A proprietary product is one example of such a component.
Release	pkg:sid/example.com/acme/beancooler@1.2.3	The asserted component at a supplier, distributor, or CNA release version.
Distribution build	pkg:sid/example.com/acme/beancooler@1.2.3?arch=x86_64&edition=enterprise&target=windows	A specific release distribution narrowed by artifact-selecting facets.
Subcomponent	pkg:sid/example.com/acme/beancooler@1.2.3#drivers/filter	A subcomponent or file path inside the named software distribution.

Rationale (P2). This is the unavoidable tradeoff for non-registry
software. With npm or PyPI, the registry is the naming authority. With
commercial and standalone software, the closest observable authority is the
supplier or another party publishing a product assertion. Encoding that
authority in the namespace makes the trust boundary visible rather than
pretending that the name is globally registry-verified.

Supplier and third-party assertions

The supplier should be the canonical authority when it publishes a sid or
equivalent product metadata. Consumers should prefer supplier-authored sid
PURLs over third-party or inferred sid PURLs.

When the supplier has not published one, a distributor, CNA, customer, or other
party may mint a sid PURL as its own assertion. Such a PURL is still valid,
but its authority is the asserting domain. If a supplier later publishes a
canonical sid, the third-party sid should be linked to it with an alias,
equivalent, or successor relationship at the BOM, advisory, or catalog layer.

Components

Component	Requirement	Definition
type	required	Literal sid, lowercase.
namespace	required	Assertion namespace. The first segment is the authority: a self-asserted domain when it contains a dot, or a registered registry namespace when it does not. A vendor identifier and additional namespace segments may follow.
name	required	Stable component, project, application, or distribution name. A proprietary product is one example of such a component.
version	optional	Supplier, distributor, or asserter release, tag, build, or snapshot version.
qualifiers	optional	Artifact-selecting distribution facets such as arch, edition, target, and locale; resolver hints such as download_url are non-identity-bearing.
subpath	optional	Standard PURL subpath inside the named software distribution.

Namespace

The namespace identifies the assertion authority and the software vendor:

pkg:sid/{asserter_domain}/{vendor_identifier}[/{vendor_namespace...}]/{name}

Rules:

• The first namespace segment serves as the authority. It should be a
  domain-qualified namespace: a DNS-order internet domain controlled by the
  party making or publishing the assertion, self-asserted and requiring no
  registration.
• The first segment may instead be a registry-based namespace, identified by
  the absence of a dot. A registry-based namespace shall be registered in the
  PURL registry; an unregistered registry-based namespace is invalid.
• The namespace should continue with a vendor, project, or component-owner
  identifier as a stable URL-safe token.
• Additional namespace segments may be used for vendor-specific component
  families, divisions, suites, or other supplier-defined grouping.
• Empty namespace segments are invalid.
• The domain segment should be lowercase.
• Vendor and vendor-specific namespace segments should be lowercase URL-safe
  slugs unless the supplier publishes a different canonical token.
• The namespace is not a URL authority and shall not include a scheme,
  credentials, path, query, or fragment.

Examples:

example.com/acme
oracle.com/oracle
microsoft.com/microsoft
kernel.org/linux
distributor.example/acme

Rationale (P2). The original scid proposal required both a domain and a
vendor because either one alone is weak. Domains can expire, transfer, or
change meaning; vendor names can collide. A domain-qualified authority plus a
vendor token still gives the strongest practical anchor and a
human-recognizable creator label, so this draft recommends that form. It does
not mandate it: aligning with the working group's decision, the first segment
may instead be a registered registry namespace, and the vendor segment is a
recommendation rather than a validity gate. Allowing additional namespace
segments captures the discussion request for vendor-specific namespaces.

A rebrand, acquisition, domain transfer, or domain loss may yield a new sid
PURL. Continuity belongs in catalog relationships, not in identifier mutation.
Where archival verification matters, the metadata distribution mechanism should
preserve old assertions independently of current DNS ownership.

Name

The name is the stable component, project, or application identifier. A
proprietary product is one example of such a component.

Rules:

• If the supplier publishes a canonical sid, component metadata object, SWID
  tag, release manifest, or equivalent component id, use the supplier's
  canonical component token.
• Otherwise use the common component or project name normalized to a lowercase
  URL-safe slug.
• Do not include version, edition, architecture, target environment, locale, or
  download location in name when the corresponding PURL component or
  qualifier exists.
• Do not use customer-specific labels, internal asset names, contract ids, or
  scanner display strings as the component name.

Examples:

beancooler
windows-10
java-se
linux-kernel
analytics-suite

Version

The version is optional and opaque. It should be the supplier, distributor, or
asserting authority's own release, product version, tag, build, date, or
snapshot identifier.

1.2.3
22H2
8u411
6.10.2
2026.04

Omitting version denotes the product identity without a pinned release.
Producers should not move version-like tokens into name when the token is a
separable release identifier.

Qualifiers

sid requires no qualifiers. The following qualifiers are defined. The
Identity column states whether the qualifier is part of component identity,
because the type-definition schema has no field to express this and consumers
need to be told.

Qualifier	Requirement	Identity	Meaning
arch	optional	identity-bearing	CPU or hardware architecture for the distributed artifact, such as x86_64, arm64, or a supplier-published architecture token.
edition	optional	identity-bearing	Product edition or SKU when it selects a distinct product distribution, such as community, enterprise, or professional.
target	optional	identity-bearing	Target operating system, runtime, or platform environment, such as windows, linux, android, java, or macos.
locale	optional	identity-bearing	Locale or language distribution when the vendor ships a distinct localized artifact.
download_url	optional	not identity-bearing	Current download, landing, or customer portal URL, when safe to publish. May require authentication.

Runtime state, installation path, license key, contract id, tenant, customer,
detected vulnerability state, remediation state, and scanner confidence shall not
be encoded as qualifiers.

arch

arch is used only when the architecture selects a different artifact or
distribution. It should use common normalized architecture tokens when those are
unambiguous (x86_64, arm64) and may use the supplier's own architecture
token when that is the published discriminator.

edition

edition is used only when the edition changes the referent: different bits,
different feature set, different license family, or a supplier-recognized SKU.
It should not encode a customer's contract terms or entitlement state.

target

target is used when the same product release is distributed separately for a
target software environment or platform. It maps to the role CPE calls
target_sw and the original scid proposal called target.

locale

locale is used only when locale selects a distinct software distribution. It
shall not encode runtime configuration, user preference, or a locale setting that
does not change the artifact.

The value should be a BCP 47 language tag when the supplier's distribution is
identified by a standard locale. BCP 47 extensions may be used when they are
actually part of the distribution identity. When the vendor publishes a
non-standard but stable locale token, producers should use the vendor token
rather than invent a lossy conversion.

Examples:

locale=ja-JP
locale=th-TH
locale=ja-JP-u-ca-japanese
locale=international

Rationale (P4). The discussion around PR #857 surfaced the important
boundary: locale matters for separate localized software packages, not for
runtime locale configuration. The qualifier exists for the former only.

download_url

download_url is a resolver hint, not identity. It may point to a public
download, vendor landing page, customer portal, or authenticated distribution
location. It shall not contain credentials, bearer tokens, customer secrets, or
one-time URLs. Changing download_url shall not change the sid identity.

Producers should prefer BOM external references, TEA metadata, SCITT/Product
Trust Registry records, vendor catalogs, or other metadata channels over putting
large or sensitive resolver data in the PURL itself. The qualifier exists only
for small, safe resolver hints.

Subpath

subpath has the standard PURL fragment meaning: a relative path inside the
named software distribution.

Use subpath when identifying a subcomponent, module, or file within the
broader software product:

pkg:sid/example.com/acme/beancooler@1.2.3#drivers/filter

Use qualifiers for distribution facets and subpath only for a path inside the
distribution. Do not use subpath for download URLs, installation paths, or
customer deployment locations.

Construction

Given a software component or release to describe, a producer mints the PURL as
follows:

1. Choose type. If an existing ecosystem, service, private, app store, or
   VCS PURL applies, stop and use that type instead.
2. Choose assertion authority. Prefer a supplier-published sid or supplier
   metadata. If minting a third-party assertion, use the domain of the party
   making that assertion.
3. namespace segment 1 (authority) := the assertion authority's DNS-order
   domain, lowercase, when using the recommended domain-qualified form; or a
   registered registry namespace when using the registry-based form.
4. namespace segment 2 := the vendor, project, or component owner identifier
   published by the supplier or normalized from the vendor name. Recommended,
   not required.
5. additional namespace segments := supplier-defined component family,
   division, suite, or namespace only when needed and observable.
6. name := the supplier's stable component token, or a normalized component
   slug when no token is published.
7. version := the release, build, tag, date, or snapshot identifier, when
   known.
8. qualifiers := artifact-selecting facets (arch, edition, target,
   locale) only when they narrow the referent.
9. subpath := only when identifying a path inside the named software
   distribution.

Equality and propagation

PURL equality is defined on decoded components, so equivalent percent-encodings
of the same value are equal.

Identity narrowing handles the vertical axis:

• A finding against a product-level sid can apply directionally to releases
  and distribution builds below it.
• A finding against a versioned sid can apply directionally to builds narrowed
  by architecture, edition, target, or locale.
• A finding against a fully-qualified distribution build applies only to that
  build unless catalog evidence says otherwise.

Relationships carried in the BOM, advisory, or catalog layer handle the
horizontal axis:

• alias / equivalent links CPE, SWID, supplier sid, distributor sid, and
  third-party sid identifiers that are believed to name the same referent.
• successor links rebrands, acquisitions, product renames, and domain
  changes.
• variant-of links related distributions, forks, or vendor-specific builds
  when they share lineage but are not the same referent.

Rationale (P2, P3). sid intentionally makes assertion provenance
visible. That means two parties may mint different valid PURLs for what later
proves to be the same product. The identifier should not hide that uncertainty;
equivalence belongs on a relationship asserted by a catalog, advisory, or BOM.

Relationship to CycloneDX and SPDX

In CycloneDX, a pkg:sid identifier attaches to a component for commercial,
proprietary, standalone, or other non-ecosystem software dependencies. It is
especially useful where existing inventories would otherwise carry CPEs, vendor
strings, or unstructured software names. In SPDX, it is an external package
identifier on the corresponding element.

SBOM producers should keep ecosystem dependencies on ecosystem PURLs, first-
party repository components on pkg:private, hosted services on pkg:service,
and non-packaged distributed software on pkg:sid.

Resolution and metadata distribution

There is no mandatory public registry for pkg:sid. Base validation is syntax
validation plus type-specific normalization. Advanced validation may check an
optional namespace registry, supplier catalog, TEA service, SCITT/Product Trust
Registry, vendor website, signed customer notice, or other supplier-controlled
metadata.

Resolution is therefore layered:

1. Parse and normalize the PURL.
2. Determine the assertion authority from the first namespace segment.
3. Determine vendor and product identity from the remaining namespace and name.
4. Apply version and distribution facets.
5. If supplier metadata exists, validate the PURL against that metadata.
6. If TEA discovery exists for the domain, use it for richer product and release
   metadata.
7. If a future purl-locator mechanism exists, treat it as optional metadata,
   not as a requirement for PURL validity.
8. If download_url is present, use it only as a resolver hint; expect
   authentication or access control for commercial and internal software.

Package-collection tooling should treat pkg:sid as valid PURL syntax but not
automatically collectable without a product catalog, supplier metadata source,
or user-provided resolver.

TEA and well-known resources

TEA is a natural companion for sid, but not a requirement. A domain-bound TEA
service can publish product and release metadata, validate canonical names, and
provide download or provenance information without centralizing the sid type.

This proposal does not define a new /.well-known/ resource. If the working
group chooses to define a PURL locator resource, it should be specified
separately, should follow the IANA well-known URI registration process, and
should not make sid validity depend on resolution.

Anticipated objections

"PURLs are supposed to be deterministic and self-validating." That is true
for registry-backed types, and the design should preserve it where possible.
sid exists because this class of software has no package registry. The
deterministic source of truth is therefore a supplier or asserter's product
metadata, not a global registry. That is weaker than npm-style verification but
stronger than unstructured vendor/product strings.

"This recreates CPE." It overlaps CPE's use case, but not its governance
model. sid is decentralized and PURL-shaped. It can carry CPE-like facets, and
catalogs can map CPEs to SIDs, but it does not require NVD to allocate names.

"A central registry is required for consistency." A registry can help, but
it should not be required for base validity. The discussion split syntax from
resolution for this reason: a registry of thousands of commercial and standalone
software namespaces is unlikely to scale as a mandatory gate. Optional registries
can document namespace policies, early adopters, or mappings.

"Download location should be required." No. A sid is primarily an
identifier. Commercial downloads may require payment, customer approval, or
authentication; internal downloads may be unreachable to outsiders; and many
SBOM or advisory uses need matching, not download. Location belongs in metadata
or a non-identity resolver hint.

"Why not pkg:generic?" generic has no authority model, no required
domain/vendor structure, no CPE-like distribution facets, and no clear
validation story. Adding all of that as conventions on generic would create a
hidden type with less discoverability.

"Why not pkg:private?" private names first-party repository software
owned by the organization minting the PURL and carries repository coordinates.
sid names distributed software a party obtained, supplied, or asserts for
vulnerability and inventory matching. The same SBOM can use both.

"Why not pkg:service?" service names hosted service referents with no
downloaded artifact. sid names distributed software products and installable
releases.

"Locale is too complicated." It is complicated when treated as language
metadata. This proposal treats it as an artifact discriminator only. If locale
does not select a distinct distribution, omit it.

Candidate type-definition JSON

{
  "$schema": "https://packageurl.org/schemas/purl-type-definition.schema-1.0.json",
  "$id": "https://packageurl.org/types/sid-definition.json",
  "type": "sid",
  "type_name": "Software Identifier",
  "description": "Distributed software with no authoritative package ecosystem PURL: commercial and proprietary products, standalone open source releases, binary-only/installable software, and CPE-like product identifiers. Use an existing package ecosystem, VCS, app store, service, or private type when one applies.",
  "repository": {
    "use_repository": false,
    "note": "There is no mandatory repository or registry for SID. Resolution uses supplier, asserter, catalog, TEA, SCITT, or other metadata when available."
  },
  "namespace_definition": {
    "requirement": "required",
    "case_sensitive": false,
    "permitted_characters": "^[a-z0-9.-]+(/[a-z0-9][a-z0-9._-]*)*$",
    "native_name": "assertion authority plus optional vendor namespace",
    "normalization_rules": [
      "The first namespace segment is the authority. When it contains a dot it is a self-asserted DNS-order domain controlled by the party making or publishing the assertion and requires no registration. When it contains no dot it is a registry-based namespace that shall be registered in the PURL registry; an unregistered registry-based namespace is invalid.",
      "The namespace should continue with a stable vendor, project, or component-owner identifier.",
      "Additional namespace segments may be used for supplier-defined component families, divisions, suites, or namespaces.",
      "The namespace is not a URL authority and does not contain a scheme, credentials, query, or fragment."
    ],
    "note": "The namespace binds the assertion authority and, where present, the vendor identity; it is not a download location."
  },
  "name_definition": {
    "requirement": "required",
    "case_sensitive": false,
    "permitted_characters": "^[a-z0-9][a-z0-9._-]*$",
    "native_name": "software product or component name",
    "normalization_rules": [
      "Use the supplier-published component token when one exists; otherwise use a lowercase URL-safe slug of the common component name.",
      "Do not encode version, edition, architecture, target environment, locale, customer, or download location in the name."
    ]
  },
  "version_definition": {
    "requirement": "optional",
    "case_sensitive": true,
    "native_name": "release, tag, build, date, or snapshot version",
    "note": "An opaque version string from the supplier, distributor, or assertion authority."
  },
  "qualifiers_definition": [
    {
      "key": "arch",
      "requirement": "optional",
      "description": "CPU or hardware architecture for the distributed artifact. Identity-bearing when it selects a different artifact."
    },
    {
      "key": "edition",
      "requirement": "optional",
      "description": "Product edition or SKU. Identity-bearing when it selects a distinct product distribution."
    },
    {
      "key": "target",
      "requirement": "optional",
      "description": "Target operating system, runtime, or platform environment. Identity-bearing when it selects a different artifact."
    },
    {
      "key": "locale",
      "requirement": "optional",
      "description": "Locale or language distribution. Identity-bearing only when the vendor ships a distinct localized artifact; do not use for runtime locale configuration."
    },
    {
      "key": "download_url",
      "requirement": "optional",
      "description": "Current download, landing, or customer portal URL, when safe to publish. Not identity-bearing and may require authentication."
    }
  ],
  "subpath_definition": {
    "requirement": "optional",
    "case_sensitive": true,
    "native_name": "path inside the software distribution",
    "normalization_rules": [
      "Use subpath only for paths inside the named software distribution.",
      "Do not use subpath for download URLs, installation paths, or customer deployment locations."
    ]
  },
  "examples": [
    "pkg:sid/example.com/acme/beancooler@1.2.3",
    "pkg:sid/microsoft.com/microsoft/windows-10@22H2?arch=x86_64&edition=enterprise&locale=ja-JP&target=windows",
    "pkg:sid/oracle.com/oracle/java-se@8u411?arch=x86_64&target=windows",
    "pkg:sid/kernel.org/linux/linux-kernel@6.10.2",
    "pkg:sid/distributor.example/acme/appsuite@1.0.0",
    "pkg:sid/example.com/acme/beancooler@1.2.3#drivers/filter"
  ],
  "note": "Identity is the first-segment authority (a self-asserted domain or a registered registry namespace) plus an optional vendor segment plus the component name, narrowed by version, artifact-selecting qualifiers, and subpath. Download location and metadata distribution are optional and not identity-bearing."
}

Summary of key decisions

Decision	Reason
Use sid only when no existing ecosystem, service, private, VCS, or app store type applies.	Avoids turning sid into a generic fallback and preserves ecosystem self-validation.
First namespace segment is the authority: a self-asserted domain or a registered registry namespace; a vendor identifier should follow.	Aligns with the working group's decision while still recommending the domain-plus-vendor form for human/vendor disambiguation from the original scid proposal.
Additional namespace segments are allowed after the authority/vendor segments.	Incorporates the discussion request for vendor-specific namespaces without weakening the leading authority semantics.
Supplier-authored identifiers are preferred; third-party identifiers are assertion-scoped.	The supplier is normally authoritative, but consumers and CNAs may need identifiers before suppliers publish them.
arch, edition, target, and locale are identity-bearing only when they select different artifacts/distributions.	Mirrors CPE's useful axes while preventing runtime configuration from polluting identity.
download_url is optional and not identity-bearing.	PURL identity needs to work even when download requires authorization or no public location exists.
TEA, SCITT, purl-registry, and well-known locators are optional metadata/resolution layers.	Keeps syntax and identity separate from resolution, and avoids mandating a central registry.
CPE/SWID continuity lives in relationships, not in the SID string.	sid can coexist with legacy identifiers and be mapped by BOM/advisory/catalog data.
Locale uses BCP 47 when appropriate, but only for distinct localized artifacts.	Captures the PR #857 point without mistaking runtime locale configuration for package identity.

References

• ECMA-427 Package-URL specification: https://ecma-tc54.github.io/ECMA-427/
• Ecma International ECMA-427 page:
  https://ecma-international.org/publications-and-standards/standards/ecma-427/
• Package URL type definitions:
  https://github.com/package-url/purl-spec/tree/main/types
• Package URL type-definition schema:
  https://raw.githubusercontent.com/package-url/purl-spec/main/schemas/purl-type-definition.schema-1.0.json
• purl-spec discussion #841 "Design for PURL type for software without a
  registry": https://github.com/package-url/purl-spec/discussions/841
• purl-spec #516 "Add new PURL type for non-packaged software":
  https://github.com/package-url/purl-spec/issues/516
• purl-spec PR #857 "SID: locale qualifier: Add Extension U example to BCP
  47": https://github.com/package-url/purl-spec/pull/857
• purl-spec #690 "Schema change / purl-type-definition: Add enum for
  namespace values": https://github.com/package-url/purl-spec/issues/690
• package-url purl-registry experiment:
  https://github.com/package-url/purl-registry
• Mark Nottingham, "So You Want To Define a Well-Known URI":
  https://mnot.net/blog/2026/well_known_uris
• ISO/IEC Directives, Part 2 (verbal forms for the expression of provisions)
• BCP 47 and RFC 6067 for locale extension discussion

[mjherzog]

@VanL Thank you for the summary/synthesis. I have a few feedback points:

• The current proposal - https://github.com/package-url/purl-spec/blob/main/docs/decisions/001-PURL_type-software_without_registry.md - does not mandate an "assertion domain" for the first segment of the namespace.

  • The text in the decision draft is: "The first segment of the namespace serves as the authority. When the segment contains a dot, it is treated as a domain-qualified namespace representing the internet domain of the publishing entity. Domain-qualified namespaces are self-asserted and do not require registration in the PURL registry.
    When the first segment does not contain a dot, it is a registry-based namespace that must be registered in the PURL registry. A registry-based namespace that is not registered in the PURL registry is invalid."
  • I suppose that there may be an argument for two parallel PURL types such that one would require an "assertion domain" and one would require a minimal registry entry but no one has proposed that (yet).

• We deliberately use the word component, and not product, as the primary definition for name. This is intentional to avoid perceived preference for proprietary products over open source projects. Component is a neutral term that maps to CycloneDX nicely. Obviously a proprietary product is an example of a component, but it should be a secondary reference. In particular the top Identity Model Level should be Component, not Product.

• On a terminology note, per the Ecma standard/style guide, we do not capitalize keywords like MUST, SHALL, etc. and we do not use MUST or MUST NOT. I do not have a citation at hand but the explanation was that "must" refers to the physical world (like the laws of physics). This point was clarified as we submitted PURL for Ecma approval last year. I suppose that I need to find that reference for future use.

[VanL]

Updated the original discussion/spec to reflect this feedback.

[VanL]

@mjherzog I have a question about the proper applicability of pkg:sid. Take this case:

path	current	suggested (host)
isc.org/bind9.yaml	pkg:sid/isc.org/isc/bind9	pkg:gitlab/isc-projects/bind9 (gitlab.isc.org)
isc.org/kea.yaml	pkg:sid/isc.org/isc/kea	pkg:gitlab/isc-projects/kea (gitlab.isc.org)

For this sort of situation , would pkg:sid or pkg:gitlab be preferable?

[mjherzog]

@VanL I would recommend the pkg:gitlab formulation because it provides additional information in the 'gitlab' PURL type, but we do not currently have a gitlab type. We will, however, have the new 'git' *type very soon so the PURL string for that would be:
pkg:git/gitlab.isc.org/isc-projects/kea
The PR to add the 'git' PURL type is: #823 for reference

[VanL]

So the git PURL type would be preferable to the sid type? Why? That is the root of my question. Thanks, Van Van Lindberg ***@***.***

…

On Mon, Jul 6, 2026 at 11:38 AM Michael Herzog ***@***.***> wrote: @VanL <https://github.com/VanL> I would recommend the pkg:gitlab formulation because it provides additional information in the 'gitlab' PURL *type*, but we do not currently have a gitlab *type*. We will, however, have the new 'git' **type* very soon so the PURL string for that would be: pkg:git/gitlab.isc.org/isc-projects/kea The PR to add the 'git' PURL *type* is: #823 <#823> for reference — Reply to this email directly, view it on GitHub <#841?email_source=notifications&email_token=AABUNKWY7H2DAYIM6PHBUDD5DPIY7A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZVGUYDGNBZUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17550349>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABUNKQNVXDBQIBVUODNZAL5DPIY7AVCNFSNUABHKJSXA33TNF2G64TZHMYTCMBTGM4TCNZXHNCGS43DOVZXG2LPNY5TSNZTGQZDOMFBOYBA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[mjherzog]

Just restating the Community call discussion today

• The general idea is to prefer the specific over the general so the 'git' type tells you how the software is stored/managed
• The 'generic' type is last resort
• There can always be multiple PURLs that identify a software object or component depending on where it exists in the stream of source (upstream) to deploy (downstream)