Notice Mar 2, 2026: This guide is not yet implementable! We are building it on https://govstack-global.atlassian.net/wiki/spaces/GH/pages/5080283 calls. Contact anyone at the Technical Facilitation team for feedback.
Topics:
Defining names of specifications. Working Group decides what to call it. General comments?
govstack-bb-cloud or govstack-bb-cloud-instrastructure
govstack-bb-consent
govstack-bb-cms
govstack-bb-digital-registries or govstack-bb-registries
govstack-bb-registration
govstack-bb-emarketplace
govstack-bb-esignature
govstack-bb-gis
govstack-bb-im or govstack-bb-mediator or govstack-bb-information-mediator
govstack-bb-messaging
govstack-bb-payments
govstack-bb-scheduler
govstack-bb-wallet
Migrating Cross-Cutting reqs to either Cross-Functional requirement extensions or to Functional Requirements
Assertions from the Building Block Specification Framework:
5.2 Building Block Specification:
Specification consists of a description and one or more (mostly technical) requirements.
A Building Block specification is an extension of GovStack Architecture Specification's cross-functional requirements
5.2.1 Specification Identifiers and Naming Conventions:
The names of specifications for Building Blocks need to be unique and never re-used.
When referring to a requirement then the schema is similarly: govstack-[type]-[name]#req-[requirement-number] and when together with version it is govstack-[type]-[name]-[version]#req-[requirement-number]
Since every specification is essentially an extension of core Architecture Specification of GovStack, its correct definition would be for example: govstach-bb-workflow-2.0.0 extends govstack-cfr-2.0.0
5.2.3 Specification Requirements Classification
Each specification consists of a description and then clearly defined requirements. Each requirement must have a unique identifier and then a set of one or more requirements based on the classification defined below. ← this and clause means a requirement has subrequirements but this is not correct. Rather they belong to a functionality or they just belong to the specification.
5.2.4 Unique Identifier
Each requirement has a unique IDENTIFICATION NUMBER within its own specification.
While most specifications will seem to have requirements in sequental numbers, it is expected that numbers under the same unique specification will never be reused for another purpose within that specification. If a requirement becomes outdated or irrelevant, its classification is updated to deprecated and its number is never reused. → In practice this means we collectively undertake the task of assigning requirement numbers to our specifications in the format of govstack-bb-wallet#req-1
govstack-bb-wallet-cfr#req1
govstack-bb-wallet-cfr-data#req1
govstack-bb-wallet-cfr-data-4#req1
govstack-bb-wallet-kdf#req1
govstack-bb-wallet-kdf-1#req1
govstack-bb-wallet-fr#req-1
govstack-bb-wallet-cfr#req-1
Yuliia’s proposal | Ali’s interpretation | |||
|---|---|---|---|---|
5.1.1. Unobservability | The issuer should not be able to learn details (to whom the presentation was made when the presentation was made, etc.) of the presentation (RECOMMENDED) | CFR Extension of AUDITABLE | Privacy/data-flow diagrams showing which parties get which data in issuance/presentation/status flows, threst model This is a Privacy constraint, not functional requirement for the wallet | bb-wallet#req1 extends |
5.1.1. Unobservability | The wallet provider should not be able to observe how the credentials are used (RECOMMENDED) | CFR Extension of AUDITABLE | ||
5.1.2. Unlinkability | A verifier should not be able to link two presentations to the same holder (unless the holder's data is provided as part of the presentation) (RECOMMENDED) | CFR Extension of AUDITABLE | These are privacy guarantees spanning protocols, credential formats, wallet behavior, verifier behavior, issuer behavior. | |
5.1.2. Unlinkability | An issuer should not be able to link two issuance transactions to the same holder (unless the holder provides information as part of the holder's authentication) (RECOMMENDED) | CFR Extension of AUDITABLE | ||
5.1.2. Unlinkability | Two verifiers should not be able to link two presentation transactions to the same holder by sharing the received presentations (RECOMMENDED) | CFR Extension of AUDITABLE | ||
5.1.2. Unlinkability | Two issuers should not be able to link two issuance transactions to the same holder by sharing the received information during the issuance (data provided for holder authentication) (RECOMMENDED) | CFR Extension of AUDITABLE | ||
5.1.2. Unlinkability | An issuer and a verifier should not be able to link an issuance and presentations session to the same holder (unless the Holder provides sufficiently identifying information as part of their authentication to the Issuer and as part of the presented credential shared with the verifier) (RECOMMENDED) | CFR Extension of AUDITABLE |
5.2.10 Example of a requirement
To define a new requirement for example for a new "weather" building block and I want to require that there is an API call which returns current weather based on some parameters (not shown here in the example) then it can be defined as a requirement like this:
#7 Must return current weather for the API request /api/v1/weather RECOMMENDED REPLACEABLE