Ensure the base context doesn't constrain lower-maturity specifications

[jyasskin]

#1158 will freeze the content of the base context (https://www.w3.org/ns/credentials/v2) when vc-data-model goes to REC. The base context currently includes definitions for terms like DataIntegrityProof, which is defined in https://www.w3.org/TR/vc-data-integrity/#dataintegrityproof rather than in the spec that's freezing the context, so if vc-data-integrity goes to REC after vc-data-model, there's a chance that it would want to change the definition and wouldn't be able to because it was already frozen.

I think that implies that the vc-data-model REC should be delayed until all of the terms its context defines are also defined by Recommendations (or equivalent maturity levels published by other standards bodies). This may not actually be a delay if the specs are finished in the right order.

[OR13]

We discussed not including status list or data integrity terms in the v2 context.

The working group decided to include those terms to "make it easier for developers".

I don't agree that including the terms makes it easier for developers.

If we are at risk of delaying the core data model if there are objections to data integrity or status list, I prefer to not include them in the v2 context.

[selfissued]

It would be much cleaner to remove all dependencies on the "securing" specs from the core data model. I suggest that we do this before going to Candidate Recommendation.

[mprorock]

I think the best approach is to only include terms in the core context that are defined in the core context - other specs can provide their own contexts if required

[mprorock]

The more I dig into this @brentzundel @Sakurann I think we need to prioritize ensuring nothing in the core data model is dependent in any normative fashion (directly or indirectly) on work outside the core data model. Otherwise an issue with another spec could prevent the core data model from advancing

[OR13]

Potential solution discussed in

#1149 (comment)

[OR13]

Additional commentary regarding this, emerging in the discussion on #1149 (comment)

[msporny]

I'll make clarifications to the at risk marker on the WG strategy regarding maturity of specification values references in the context.

[iherman]

The issue was discussed in a meeting on 2023-07-25

• no resolutions were taken

View the transcript

3.3. Ensure the base context doesn't constrain lower-maturity specifications (issue vc-data-model#1175)

See github issue vc-data-model#1175.

Manu Sporny: We have marked the context as 'at risk', so if anything looks like it's going to hold up our CR process it can be removed.

Dave Longley: +1 to already addressed.

Ivan Herman: +1.

Phillip Long: +1 that we have language addressing this already.

Manu Sporny: We currently have this in the spec:.

ISSUE: (AT RISK) Hash values might change during Candidate Recommendation.

Manu Sporny: This section lists cryptographic hash values that might change during the Candidate Recommendation phase based on implementer feedback that requires the referenced files to be modified.

Manu Sporny: (in the base context section).

Manu Sporny: Link to that text is here: https://w3c.github.io/vc-data-model/#base-context.

Dave Longley: -1 to needing additional language, right now we can modify in any way.

Dave Longley: "can be changed in any way, including removal".

Ivan Herman: +1 to dlongley.

Manu Sporny: I'll take an action item on 1175 to make this more specific.

[msporny]

PR #1251 has been raised to address this issue. This issue will be closed once PR #1251 has been merged.