Outline plan to mitigate normative context risk when transitioning to Proposed Recommendation #1251
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -5451,6 +5451,17 @@ <h3>Base Context</h3> | |||||
| 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. | ||||||
| <br><br> | ||||||
| The Working Group is expecting all of the terms and URLs supplied in the | ||||||
| JSON-LD Context to be either stabilized, or removed, before the publication of | ||||||
| this specification as a Proposed Recommendation. While that means that this | ||||||
| specification could be delayed if dependencies such as [[?VC-DATA-INTEGRITY]], | ||||||
| [[?VC-JOSE-COSE]], SD-JWT, [[?VC-JSON-SCHEMA-2023]], or status list | ||||||
|
There was a problem hiding this comment.
Suggested change
At this moment at least, SD-JWT is not even on the list of the official publications of the WG, i.e., talking about the PR phase of that document is meaningless. There was a problem hiding this comment. PR #1242 adds SD-JWT terms to a normative document (the base context) that the group is publishing. It highlights the problem that @jyasskin raised... we now have a normative dependency on a document at IETF that is almost certainly not going to be finished on the timeline that the VCWG is on. While it's not on the official publication of the WG, the VC-JOSE-COSE specification, and the base context have a normative dependency on it. Again, the base context having a dependency on it isn't a big deal... by the time we hit REC (Summer 2024), SD-JWT should be stable enough (in the properties that it uses)... and if it's not, the group can remove references to it from the base context (which is what this PR says for those properties, and any other unstable properties). There was a problem hiding this comment. Ok. B.t.w., let us be precise. By believe that in this context (sic!) our dependency is on the URL-s and not on the details of the respective specifications. To take an example, we have a dependency on And yes, the SD-JWT specification might be in flux, but the URLs we use may not... There was a problem hiding this comment. Yes, correct, our dependency is on the URLs, primarily. @jyasskin's point was that we could accidentally create a bi-directional dependency. Not only do we lock in the terms and URLs from our standpoint, but we could make it such that the spec that we reference then couldn't change the terms/URLs if they wanted to (because we'd ship something that they weren't ready to ship). For example, if SD-JWT decides to change the The mitigation to all of that is just keeping all of the groups in sync w/ one another and being ready to pull the terms that are not stable enough as we go into Proposed Rec. We have 9-ish more months for all of this to stabilize, so making the decision now is premature... we'll reserve the right to make the decision later (which is what this PR attempts to say). There was a problem hiding this comment. yes, the v2 context has terms from several related documents, if any of them stall / fail or are blocked indefinitely, the bundling strategy could bite us, the list includes:
Possible there are other documents that could cause problems beyond these. vc-jose-cose does not define any terms, hence it has nothing appear in the v2 context, but normative dependency issues would still exist. There was a problem hiding this comment.
Debatable... One of our specs should speak to the fact of all the ".../jose#" and ".../jwt#" entries in the core context now... same for SD-JWT properties. If the JOSE group decides they don't want to use those URLs, or SD-JWT changes (or vice versa), it creates the same issue... and the resolution is the same as all the other specs -- features will be cut/removed if they get in the way for REC. |
||||||
| do not enter the Proposed Recommendation phase around the same time frame, the | ||||||
| Working Group is prepared to remove the dependencies if an undue burden is | ||||||
| placed on transitioning to the Recommendation phase. This is a calculated | ||||||
| risk that the Working Group is taking and has a mitigation strategy in place | ||||||
| to ensure the timely transition of this specification to a Recommendation. | ||||||
| </p> | ||||||
| <p> | ||||||
| Implementations MUST ensure that the base context value, located at | ||||||
|
|
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just wonder whether we should also refer to the vocabulary here. We have made the vocabulary just as normative as the JSON-LD in terms of the associated hash values.
A side issue, that is related to this, though not directly part of this PR is whether it is wise to refer to the integrity of the HTML version of the vocabulary. The vocabulary includes a number of non-normative text helping the reader of the spec, like diagrams or other explanations, and even those could not be updated with the current setup. In my view, the integrity of the JSON-LD and Turtle file should suffice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do the same thing that we did here:
https://w3c.github.io/vc-data-integrity/#contexts-and-vocabularies
I'm looking for feedback from reviewers if they want to do something along the lines of what we did in the Data Integrity specification.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would recommend only focusing on the JSON-LD / Turtle files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I raised #1261 to track @iherman's request.