Deprecate `digestSRI` in v2.1

[msporny]

The VCWG chose to support both digestSRI and digestMultibase in the core data model. This is causing downstream specifications to attempt to support both. digestSRI only exists in browsers and is restricted to requiring two browser implementations for new cryptographic hash formats, digestMultibase is extensible and has a registry for new multihash formats as they are created (broader cryptographic agility when it comes to cryptographic hash formats).

The suggestion is to pick digestMultibase going forward for downstream specifications and include a deprecation notice in v2.1 for digestSRI.

[iherman]

This was discussed during the vcwg meeting on 29 April 2026.

View the transcript

aob

<manu> Deprecate digestSRI in v2.1 -- w3c/vc-data-model#1628

manu: Raised an issue in VC data model to deprecate use of digestSRI in VCDM 2.1, as it is creating confusion in downstream specs, so please review this issue to chime in: w3c/vc-data-model#1628

phila: Thanks everyone for meeting today and see you next week.

---

[iherman]

1. Would it be possible to dig out the original discussions and pro/con arguments to include SRI in the spec? It would help us in this discussion
2. What do we mean by "deprecation notice"

[BigBlueHat]

• Would it be possible to dig out the original discussions and pro/con arguments to include SRI in the spec? It would help us in this discussion

Here's some findings on GitHub (there are likely more in the mailing list or other meeting logs):

• Unify cryptographic hash expression formats #1489 (the question of why are there two options)
• Use digestMultibase with base64-url-nopad encoding for integrity. #1490 (for just digestMultibase)
• Support two different digest formats for resource integrity. #1492 (for using both digest options)

[iherman]

#1490 (which proposed, essentially, the same) was objected to by mesur.io, afaik now tradeverifyd. They are not members of the WG anymore, but they are W3C members. Should we contact them whether they would be o.k. with the proposed change?

/cc @brentzundel

[msporny]

What do we mean by "deprecation notice"

By that, we mean that v2.1 wouldn't remove the feature, but we'd warn that the feature is deprecated and may be removed in future versions.

We would leave the definition of digestSRI in the v2.1 JSON-LD Context, move the content on how to use the feature to an appendix (with a reference to that appendix from the main spec), and note that we plan to remove it entirely in v3.0 (people can still choose to use it by re-defining it in their own vocabularies).

That way, we can hear from the community before we actually make the removal.

[iherman]

What do we mean by "deprecation notice"

By that, we mean that v2.1 wouldn't remove the feature, but we'd warn that the feature is deprecated and may be removed in future versions.

We would leave the definition of digestSRI in the v2.1 JSON-LD Context, move the content on how to use the feature to an appendix (with a reference to that appendix from the main spec), and note that we plan to remove it entirely in v3.0 (people can still choose to use it by re-defining it in their own vocabularies).

That way, we can hear from the community before we actually make the removal.

Thanks @msporny, I am fine with this approach; no objections.

[brentzundel]

@OR13 @mprorock Do you have any opinions to share here?

[iherman]

This was discussed during the vcwg meeting on 06 May 2026.

View the transcript

w3c/vc-data-model#1628

<Zakim> manu, you wanted to speak to digestSRI

manu: This was raised because in another spec, I think recognized entities, the concept of should we use digestSRI or digestMultibase keeps coming up.
… The reason we support two digest schemes is because we couldn't agree on a single one. This is impacting downstream specs that build on the core data model. My suggestion is that we deprecate digestSRI because it is the less flexible of the two. We don't need to remove it from the spec, just mark it for deprecation/removal in 3.0.
… If anyone really likes the feature they can add it into the vocabulary for their use case.
… There were companies that pushed for digestSRI, we may want to ask them where they are on it currently.
… The proposal is to deprecate digestSRI.

ivan: whoever writes the PR should ping me so the term can be deprecated in the vocabulary as well.

manu: I'll take this PR if we have consensus.

<dlongley> +1 to deprecate digestSRI

<PDL-ASU> +1 for the proposal to go forward with standardizing the use of digestMultibase and deprecate digestSRI

brent: I will ping folks that are no longer members of this group that pushed for digestSRI in the past.
… I am not hearing any objection from the group here.

<Zakim> manu, you wanted to ask if anyone is using digestSRI and cannot live with digestMultibase?

manu: I want to know if anyone in this group has implemented and is currently using digestSRI and they will not be able to use digestMultibase.
… Let me look at the implementation report, to see if it shows who is using this feature.
… The test was to support either, we did not split them apart.

brent: If we don't hear from the people we reached out to, there is no opposition to moving forward as proposed.

---

[msporny]

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