Use cases
A profile is written for a consumer who has a decision to make. This section holds the use cases that have been carried through from that decision to a finished profile — the rules, the attributes they constrain, and documents that can be checked against them. The catalogue of purposes a profile can serve stays in the methodology, under Use Cases; what is collected here is the work of developing one of them in full. A blank in the same shape is kept as the template.
What a worked use case contains
Each page in this section follows the same eight-part shape, in the same order, because each part is the input to the next. The shape is the twelve steps of Method grouped for reading rather than for working. The template is that shape as a blank, with each section saying what belongs in it and how to tell when it is finished.
- The decision being supported. Who the consumer is, what actions it is choosing between, and the questions it has to answer to choose. Stating the actions is what makes the rest checkable: a decision answerable in only one way is not a decision, and a profile written from one has no principled place to stop.
- The constraint the producer is under. What the party filling the document in can actually observe. An operator of its own service can be asked for more than a vendor shipping a product it cannot inspect, and a profile that ignores the difference is unsatisfiable rather than demanding.
- From questions to attributes. Each question turned into one fact that can be declared at the boundary. The questions that do not survive this step matter as much as the ones that do, and are recorded rather than dropped.
- The profile definition. The product-level, per-interface and group rules, with their conformance levels; any rule inherited from a base profile that this one tightens; and any rule that applies only under a stated condition.
- A worked interface. One real interface with every required attribute filled in, so the rules can be read against something concrete rather than in the abstract.
- What the profile deliberately excludes. Each exclusion with its reason. Without this the profile cannot be reviewed: a reader cannot tell an exclusion that was argued from an attribute nobody thought of.
- Expressing it in a CBOM. How the attributes land in CycloneDX and SPDX, and which of them the formats have no native field for.
- Recorded decisions and open questions. What was settled while writing it, and what the working group has not settled.
A purpose is not listed below as developed until there is a rules file that passes requirements C1 to C17 of Conformance, and at least one document that conforms to it and one that does not. Until then it is a purpose with a description, which is a different and much cheaper thing, and it belongs in the catalogue.
Developed so far
| Use case | Consumer and decision | Profile | State |
|---|---|---|---|
| PQC migration | A migration programme lead deciding which interfaces to migrate, in what order, and what each will cost | pkic.example.pqc-migration v0.6, extending the interface disclosure baseline v0.7 |
Developed in full. One product rule, nine per-interface rules, one group rule, one tightening. Rules file, two documents and the validator. |
| IoT device estate | A fleet operator deciding, per device model, whether to update it, replace it, put a gateway in front of it, or accept it | Draft. Consumer, constraints and candidate attributes written; no rules file yet. Four questions block it, Q62 to Q65. Added to the catalogue as purpose 9. | |
| Procurement and tender conformance | A buyer checking tender responses without reading them by hand | Described in the catalogue. Closest to the existing baseline of the eight, because the baseline's product rules already catch the omission it is most exposed to. | |
| Vulnerability management and incident response | A responder deciding which services an advisory reaches, in hours | Described in the catalogue, with the boundary it has to respect set out in Vulnerabilities. Blocked on Q57: the one attribute it depends on is the one the baseline permits a producer to withhold. | |
| Regulatory and compliance reporting | An auditor or regulator checking a position against a framework | Described in the catalogue. One profile per framework, which makes this a family of use cases rather than one. | |
| Continuous integration quality gate | A pipeline deciding whether to fail a build | Described in the catalogue. Needs no profile of its own: the requirement falls on the validator, and the Demo shows the behaviour. | |
| Crypto-agility assessment | An architecture function estimating how hard replacing an algorithm would be | Described in the catalogue. | |
| Supply-chain transparency | A supplier disclosing once rather than per customer | Described in the catalogue. The interface disclosure baseline is substantially this use case already. | |
| Mergers and third-party risk due diligence | An acquirer sizing cryptographic exposure across an estate it cannot inspect | Described in the catalogue. Coverage matters more than depth here, so the entry depth of a family may be the right instrument rather than a new profile. | |
Three of the eight undeveloped cases may not need a profile of their own, which is recorded above rather than discovered later. A use case that is served by an existing profile, or by a depth of an existing family, is a better outcome than a new profile and should be argued for on that basis.
Why they are not in the methodology
The methodology is the working group's deliverable: a specification for how to define a CBOM profile. A worked use case is an instance of following it. The two are kept apart for three reasons, and the first is the one that decided it.
- Instances multiply and a specification should not. There are nine purposes in the catalogue today and sectors will bring more. If each worked one is a section of the methodology, the length of the deliverable comes to depend on how many use cases exist, which is a property of the world and not of the specification.
- The two have different readers. Someone assessing the methodology needs one worked example and is ill-served by nine. Someone with a migration to plan needs theirs in full and will not read the other eight.
- They are governed differently. A profile is versioned, dated and stewarded on its own schedule, as Governance sets out. Carrying it inside the methodology ties its revisions to the methodology's.
What stays in the methodology is the part that is general: why the use case has to come first, the catalogue of purposes, and which attributes each emphasises. The PQC migration profile is still cited throughout the methodology as the example that exercises composition, group rules and tightening, and those citations now point here.
Proposing one
A use case is worth developing when a consumer and a decision can be named, and when the facts the decision needs are not already required by the interface disclosure baseline. Open a topic on the aspect issues stating the consumer, the actions being chosen between, and the questions that decision raises. The attributes come out of that analysis; starting from the fields a format happens to offer produces a profile with no stated purpose and no way to argue about whether it asks for the right things.
Once the topic has a consumer and a decision, copy the template and work down it. A page that is only half filled in is still worth opening a pull request for: the sections it leaves blank are the ones the working group has to answer, and they are easier to argue about in place than in the abstract.