Structuring the security considerations section

[simoneonofri]

This issue refers to the security review requested in this issue w3c/security-request#71

Structuring the Security Considerations section along the lines of RFC 3552 and as discussed in w3c/security-request#71 (comment).

• Introduction: a brief description of the security impact of the feature and assets to be protected.
• Security Assumptions: paraphrasing what is described in the Common Criteria, section 7.1.4, assumptions are those elements that are considered true about the operating environment of the feature (e.g., C2PA's Assumptions).
• Attacks/Threats: list of attacks or threats with title and a brief description (e.g., Vibration API 2024-06-28 > 2024-09-20 security-request#71 (comment)). For each attack/threat:
  • Mitigations/Countermeasures:
    • If it is in-scope: title and description of the countermeasures, referring to the specific section in which it is described. If the group decided not to apply any mitigation/countermeasure to the Attack/Threat, write a rationale for accepting that risk (business justification).
    • If it is out-of-scope: describe why.
  • Residual Risk: after the application(e.g., Vibration API 2024-06-28 > 2024-09-20 security-request#71 (comment)).

If there are any doubts, we remain available.

Thank you

[cc'ing @anssiko, @himorin, @KimCerra]

[anssiko]

Thank you @simoneonofri. I'd also note the group's prior work in this space: the Generic Sensor API and Compute Pressure API threats and mitigations. To be updated based on learnings from this restructuring exercise.

[anssiko]

Status update: the group's imminent plan is to publish a new CRS and incorporate restructured security considerations in a subsequent specification update. The group is committed to work closely with @simoneonofri and other security experts to help dogfood emerging guidelines for writing security considerations for W3C specs (a la RFC 3552) as outlined in this issue.

[simoneonofri]

@anssiko thank you. For us, it is okay to have it and advance beyond Candidate Recommendation. Happy to work together to make it!

[anssiko]

@simoneonofri thanks for confirming the plan is sound! We look forward to working with you and the Security IG (when it launches, hopefully soon!) to test drive the threat modeling approach with this specification. Once we get the CRS out, we'll iterate at CR to have threats carefully documented and go beyond CR only when you're happy with the result.

[simoneonofri]

@anssiko perfect. we can may organize also a quick call with @KimCerra. Thank you again for the availability for the "pilot" :)