Add digestSRI property to General Properties#69
Conversation
Closes w3c#68.
TallTed
left a comment
TallTed
left a comment
There was a problem hiding this comment.
LGTM modulo minor editorial tweaks to refer to section titles without numbers and re-wrap source lines.
Thanks for the tweaks! |
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
| </td> | ||
| </tr> | ||
| <tr> | ||
| <td>digestSRI</td> |
There was a problem hiding this comment.
I don't think we need to support digestSRI here -- it's not easily compressible, it doesn't support as many hash formats as Multihash, and it was only included in the main spec because not having it was going to lead to a formal objection. IOW, it was a mistake to include digestSRI and I'd rather we don't make the same mistake here.
That said, I won't object over this PR -- I just want to know who can't solve their use case with digestMultibase?
There was a problem hiding this comment.
Raised a tracking issue here: w3c/vc-data-model#1628
|
This was discussed during the vcwg meeting on 28 April 2026. View the transcriptAdd `digestSRI` property to General Properties by shigeya · Pull Request #69 · w3c/vc-recognized-entities · GitHubManu_Sporny: Digest SRRI is how web browsers tend to be very limited in the cryptographic hash mechanisms that they allow. In fact, I think it's just Shawu 256, 384 and 512 that they allow. there are many other types of cryptographic hashing algorithms. Digis multibase supports a very large variety of cryptographic hash algorithms like Blake and other kind of more modern mechanisms. Digest SRRI very small set of available choices, but they're all fairly universally supported and accepted. Digest multibase is much broader in what it would allow. Manu_Sporny: But we typically try to limit it to kind of the same things that are used in digests SRRI while allowing people to make different choices in communities that need to make different choices. okay so we just used digest multibase in this spec. she is suggesting we should use digest srri. I think yall took a look at it and approved I'm opposed to it but I'm not going to object. I don't think we need two different ways of doing it here. Manu_Sporny: I don't think we should repeat the same mistake that we made in the VC data model core spec. but both mech mechanisms are simple enough to implement. I guess the main question I have is why multibase covers digest SRRI and… Manu_Sporny: more I guess why do we need both ways? go ahead Benjamin. Benjamin_Young: Yeah, I think the main thing to know from Shagaya is… Benjamin_Young: if somebody he knows is using digest because unfortunately it is in the foundational spec so somebody could be and Yeah, they're going to wonder like he did why it's not in here. I agree it's unfortunate that they're both in the data model. So I think just because he submitted it, is it asking him whether or not he was cleaning it up because he's aware of it and these don't match or if it's like I use this and it should be here. that would be helpful. Benjamin_Young: But it is I don't know we'll face this across all the specs render method will face it as well if it isn't already Manu_Sporny: Thank you, Plus one to that. go ahead, Steve. Steve_Capell: Just a quick question. Steve_Capell: These are self-describing hashes, right? So whether it's multibase or whether it's SRRI, you can see because it's written there in this case 6256 in the multibbase case a letter code and they're non-over overlapping in other words if I put a hash by inspection of the hash I can see that's a multibase. Is that right? So there's no collision here. It's just more than one way of doing it. Yeah. Manu_Sporny: Yeah. I think the argument against having both of them is ecosystem complexity and… Manu_Sporny: I think some could argue that ship already sailed and… Steve_Capell: Yeah. Mhm. Manu_Sporny: others could argue no we can still remove features in the future if we see that people haven't implemented it but you're right there's no collision here someone will either use digest SRRI or they'll use digest multibase or they'll use both of them and nothing bad happens other than all software systems have to be more complicated because of it because we didn't pick one Steve_Capell: So what I don't know is how ubiquitous these two digest self-describing digest methods are in the wide world. Steve_Capell: are we including something that's hardly used anywhere, in which case I'd be against, or are we including something that is very widely used somewhere, in which case there's a bit of a risk of excluding it,… Manu_Sporny: Plus one. Those are exactly the right questions to ask. and we don't know because we haven't done a I don't know… Steve_Capell: right? Manu_Sporny: if we know how to get data on that, other than maybe work with system vendors that have a tremendous amount of data in their systems and even then it's kind of like you don't know if you've got everything. The way we did this for, JasonLD is that there's a common crawl data set that,… Steve_Capell: Sure. Manu_Sporny: scour hundreds of millions of websites and we got very good data back on what features were used and which ones were not. But then the argument became like, yeah, but that's all the public data. You don't know anything about what the private data is. So, this kind of stuff is really difficult to figure out who's actually using these things. the only time you really find out is when you go to remove the feature and all of a sudden you get a bunch of angry emails from a community you never knew existed, turns out they depend heavily on whatever thing you're about to remove. go ahead, Phil. Phil_Archer: Sorry, I think that is the kind of thing that it's worth bringing to the wider group. I mean, as everyone here knows, we've just been through not just the recharging process, but what happened at the end of last week was all the people who didn't renew or couldn't renew or we decided not to renew their invited expert status, whatever it may be, they've all gone. But a lot of people have joined. It's still an enormous group. and whilst whatever size the group, it's a tiny fraction, we hope, of the people using the technology, it's a bigger group than we've got here right now. Phil_Archer: So it might just be worth raising it tomorrow and I think in general this kind of thing is what the whole working group call can help with that because you got a specific question for a specific feature and you're talking about either including or removing it and I think that's what the working group call can help with. Manu_Sporny: Yeah, plus one to that. And I think it's probably, the form of the question is, do we want to deprecate digest multibase in the core verifi VC spec? we didn't make a choice before. there's some advantages of one over the other. Do we want to remove it before it gets even more out of hand or… Phil_Archer: Yep. Manu_Sporny: or do we want to keep it And I think as my prediction is we're just going to leave it the way it is because that's the easiest thing to do and it's the least controversial and so on so forth. but it doesn't mean we have to duplicate that in other specs we made the mistake in BC data model. my position is do we want to make the same mistake here? I'm arguing unless we have very good reason we shouldn't do it and… Manu_Sporny: maybe we need to document that we made a conscious decision not to support it here. go ahead Benjamin. Benjamin_Young: So I think the downstream specs… Benjamin_Young: if the group decides they could pick a lane in terms of what they promote and talk about essentially in their specs u picking one of the digest formats. I don't think there's anything in the stack that's gonna prevent the use of the other ones from the upstream data model spec and I don't think we could deprecate it but we can't rip it out in a 2.1. so it's still going to be there for a while. Benjamin_Young: So, it really comes down to kind of what we want to signal as the working group going forward, which may actually work best if we look like we're aware of what we're doing and say, the group has decided to deprecate digest SRRI as of 2.1 or however this shakes out. and so please don't use that. it's totally possible, but please don't. or even if it's not fully deprecated, we're aware that there's another format, certainly you could use it. This spec's only going to talk about this one because reasons Manu_Sporny: Yeah, plus one of that. I'll go ahead and raise an issue on the core data model spec. let me see. chose to support both digest SRRI and digest multibase in the core data model. This is causing downstream specifications to attempt to support both. the features are equivalent enough that ideally only one is I shouldn't say they're really equivalent enough the features are Benjamin_Young: I'd point to the fact that digest multi-base is extensible and already supports more formats. SRRI only exists in browsers and is, really restricted to what they either have done or feel like they want to do over a weekend. so multibase is mutable and updatable by this community as well as anywhere else whereas digest SRRI is a fixed thing of the path. Manu_Sporny: and has a registry for new multi-ash formats as they are created. broader graphic agility when it comes to graphic mesh formats. Manu_Sporny: The suggestion is to pick digest multibase going forward for downstream specifications and include a deprecation notice in v2.1 for digest SRRI and then this needs discussion and Manu_Sporny: This would be a class to change. we'll take this… Manu_Sporny: if something comes of it. Dave_Longley: I was too late. Dave_Longley: I was going to say when you said restricted to browsers, do you want to say restricted to requiring two browser implementations? And that's where the spec Yeah. Manu_Sporny: Browser implementations. for four new cryptographic hash formats. So we'll put that is it eternal w Yeah. Benjamin_Young: They've reumbered it, so now there's a dash two in it. and I can't quite tell where it's happening. web app looks like… Benjamin Young: Manu_Sporny: Yeah. Yeah. Benjamin_Young: but the two is now overwriting one but if you go to the standards history it looks like there's an SRRI one which was 2016 so they rebooted the work in last April Come on. Manu_Sporny: Yep. Yep. Yep. Yeah. And It goes to CSP3 I guess which is a working draft and as we can see the hash algorithm you can only use SHA 2 256 384 or 512 that's it no Blake no Shaw 3 no no Poseidon none of the other cryptographic hashes Manu_Sporny: Yeah,… Benjamin_Young: and… Benjamin_Young: notably there's not a way to add more. Manu_Sporny: I mean you have to be a browser manufacturer and you have to implement it and the way to add more is you update the spec and publish a new recommendation, right? It's a pretty heavyweight process. Benjamin_Young: Yeah, you have to update this spec. Manu_Sporny: Literally this highlighted text. All right. raised the tracking issue here. Yes. Manu_Sporny: and good luck trying to convince them to implement Blake or Poseidon. All So, we looked at that and the digest SRRI thing. We will wait for the BCWG to decide what they're going to do before figuring out what we want to do here. And then we definitely want to hear from Shik Sunan to see if we see what he thinks. I think those are all of the PRs that we have. bouncing really quickly over to issues. this one does have a PR that exists here exists. Manu_Sporny: No, we don't have that label. I want to add that. All right. are there any particular issues that people want to change document title. We'll have to modify or I mean that's taken care of now. ensure compatibility with digital identity anchor work. Manu_Sporny: Steve, I don't know if you want to chat about that today or if there are any updates there. Steve_Capell: Yeah. I… |
|
Hi. Thanks for the discussions. As it was discussed extensively on the last call, I should respond before the next one. Let me provide some facts and thoughts on this. I knew at least one instance of code currently using digestSRI. I need to check how the 'deprecation of digestSRI' impacts their situation. Unfortunately, it's the middle of vacation week in Japan, so I can't get confirmation until next week (I don’t even want to ask the developers in the middle of vacation). I understand that it is better to reduce the possibility of confusion. But this is clearly a breaking change if somebody already relies on it. As I mentioned, we're in vacation week, and I will not be available for calls this week. |
|
I checked with the developers, who use VC and also have strong backgrounds in web technology. They are relying on the original SRI, which is still active as a new W3C Working Draft (SRI-2), so digestSRI was a natural choice for their design. The context is actually more nuanced than it first appears -- the use case spans both the VC world and the Web world (HTML I'll need more time to gather additional information and provide updated proposals. |
5 participants
Closes #68.
Summary
Adds the
digestSRIproperty to the General Properties table, aligning with VCDM 2.1 Section 5.3: Integrity of Related Resources, which defines bothdigestSRIanddigestMultibaseas mechanisms for integrity verification of related resources.Changes
digestSRIrow describing the property, with a reference to the SRI specification and VCDM Section 5.3.Rationale
The current specification only references
digestMultibasefor integrity verification, but VCDM Section 5.3 defines bothdigestSRIanddigestMultibase. ThedigestSRIproperty uses the Subresource Integrity format, which is a W3C Recommendation with native browser support.Note
I haven't updated an example using
digestMultibase.Preview | Diff