Create Security Categories for Use Cases

[mmccool]

Consistent with the plan in https://github.com/w3c/wot/blob/main/PRESENTATIONS/2023-09-tpac/2023-09-14-WoT-TPAC-UseCases-McCool.pdf, do the following:

• [ ] Create a list of categories
• [ ] Assign use cases to categories (use cases can be in more than one category
• [ ] Make a list of risks/threats (same/linked with definitions in S&P Guidelines doc).
• [ ] Identify which risks apply to which categories.

[mmccool]

Initial list of categories:

• Public Service - Provides a public service; misuse can result in lack of support to other users.
• Private/Confidential Information - Handles personal or confidential information; misuse could disclose privately identifiable information (PII) or sensitive business information.
• Safety-Critical - Misuse has the potential to cause personal injury.
• Business-Critical - Misuse has the potential to cause financial injury or damage to business operations or reputation.

[mmccool]

Next steps:

• Define basic template and organization of categories and risks in document.
• Create initial set of categories and risks
• Ask for review to finalize/edit/expand the list of categories and risks.

[mmccool]

Kaz's comments (see minutes): if we would like to start with those three as the starting point, maybe it would make sense to use the wide review viewpoints as well … e.g., privacy-critical, security-critical, internationalization-critical and accessibility-critical

[mmccool]

• "Private" could also be "Private/Confidential Information" (original comment above updated)
• Re Kaz's comments: these are more general, implying a hierarchy; accessibility and internationalization are general, and not related to a specific deliverable (would have to put in a "general" section). And these last two are probably functional requirements. Should create issues in use cases repo.
• What is difference between functional and technical requirements? Is "Security" functional or technical? Functional is "end user expectation" whereas technical is "how a function can be achieved", e.g. they are related to a functional goal. So functional requirements are higher-level, and the technical requirements should relate to them. As an example, there might be a functional security requirement to "provide access only to authenticated and authorized entities in order to protect private data, safety-critical operations, or business-critical functions" that is by followed by a technical requirement to "provide the ability to authenticate with OAuth2".
• Maybe "technical" requirements should be in each deliverable spec, e.g. part of a work item, and the UC&R document should just have functional requirements. Technical requirements are too detailed and are related to an "implementation".