Structuring the security considerations section

[simoneonofri]

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

As specified in the comment, this is the Issue to ask to structure the Security Consideration section in the way specified here

[cc'ing: @innotommy]

[msporny]

@simoneonofri and @innotommy the VCWG is currently preparing to transition up to seven of our specifications to the Proposed Recommendation phase, so this request is coming at a very unfortunate time in the WG's lifecycle. Is this a blocking request before Proposed Recommendation, or can we address this request during v2.1 work (the next cycle)?

Are you asking us to re-structure all seven of those specification's Security Considerations sections? or the Privacy Considerations sections as well?

I have looked through the proposed new structure, and the references to the C2PA specification, and it's not clear what structure you want us to use, or what content to include, in order to address this issue. A complete specification example would help. I do think that the existing Privacy and Security Considerations sections have most of the information suggested around threats and mitigations:

https://w3c.github.io/vc-data-model/#privacy-considerations
https://w3c.github.io/vc-data-model/#security-considerations

... but you might be asking for a comprehensive re-write of those sections? I need some guidance here because what it sounds like you're asking for is multiple days of specification editing per specification leading to weeks to months of delays (e.g., WG discussion on the PRs) for the specifications nearing Proposed Recommendation.

[brentzundel]

Re-structuring the section would make sense for future work. At this stage it feels like a substantial amount of work with little benefit if there aren't any additional consideration that need to be covered.
The group will discuss this.

[msporny]

The group discussed this on the call today, noted that doing this work would be good in time (during v2.1), but doing this much editorial work as close to Proposed Recommendation as we are would be disruptive especially because we don't understand what the final work product needs to look like. The group agreed to mark this as editorial and future work and we will pick this work up during the next work cycle (v2. 1, maintenance).

[iherman]

The issue was discussed in a meeting on 2025-01-22

• no resolutions were taken

View the transcript

2.1. Structuring the security considerations section (issue vc-data-model#1583)

See github issue vc-data-model#1583.

Ivan Herman: this is about structuring the security considerations section.

Manu Sporny: if folks remember for the VCDM, the new security group did a review on it.
… and mentioned there were no blocking issues.
… but said they may raise non-blocking issues.
… we have asked for a final horizontal review.
… we made that request a few weeks ago.
… just last week we heard from the security group and they requested we match a new structure.
… which is planned for all W3C specs.
… The vibration API and the Digital Credentials API groups would also be using this sort of structure.
… we said we'd be happy to participate over time, but I don't think we said we would restructure all our documents at this stage.
… if you look through what was provided, there are a number of ways we could restructure this section.
… some of these suggestions require massive amounts of editorial work.
… we're trying to figure out what amount of this is reasonable at this stage.

Ivan Herman: I agree with brent, this is simply too late.
… we're planning to go to PR in February.

Dave Longley: +1 it's too late in the process, it can be something we do in 2.1/x.1 specs going forward that clean up and revise the spec editorially.

Dave Longley: +1 to do it for maintenance.

Ivan Herman: I'd propose that we put on record that we're happy to do this as maintenance work that we are already chartered to do so post recommendation stage.
… so the issue would stay open.
… and we'd just label it for maintenance phase work.

Phillip Long: +1 for doing the security work as maintenance.

Manu Sporny: we do have a label 'future'.
… so we could mark it for that.
… the stuff they're requesting is interesting, but it also is early stage ideas, so this approach would give the security group more time to test out this approach.
… it would be good for us to do this and we have done this in the past--as seen in our current security considerations section.
… but it would be best to take our time and do it right in the maintenance stage.

Dave Longley: do we need a proposal for this one?

Ivan Herman: if manu can add this info to issue, I think we will be fine.

Ted Thibodeau Jr.: +1 push this section revision to 2.1.

Benjamin Young: +1.

Manu Sporny: I'm writing that now.
… the group decided doing this work would be good in time, but doing this much editorial work this close to recommendation would be disruptive especially.
… the group agreed to mark this as editorial and address as future work during maintenance mode work cycles.

Ivan Herman: that's the only issue brent identified for the data model.