Kudos to Zed, for at least attempting to find a workable middle-ground. It's a change from the usual and useless finger-pointing.
Very few vulnerability researchers have any notion of how much it costs to roll out a dot release; the idea that it could cost tens of thousands of dollars strikes them as nonsensical.
Meanwhile, very few software vendors have any notion of how big a deal (say) memory corruption is; the idea that it cost the public hundreds of thousands of dollars strikes them as nonsensical.
All the tools in the world aren't going to get researchers to care about why it's taking 6 months for a vendor to publish their findings. To them, 60 days is an extremely generous window. And all the tools in the world aren't going to educate vendors on the true costs of software vulnerabilities.
I think this is interesting, but the two "types of vendors" I see this being useful for are:
1.) Vendors who don't have an already established method for communicating vulnerabilities (and therefore the researcher doesn't have a good way to interact with them).
and 2.) Vendors who chose not to work with researchers (of which there used to be a lot, and are still a few).
I see type 1 quickly instating a policy to deal with vulnerabilities after something of there's get posted to the site (so they can more quickly deal with future issues), and I see type 2 continuing to ignore vulnerabilities (and possibly being hostile to the researcher and the site for posting things). So maybe the benefit is shaming "type 2" vendors?
Ultimately, yes, it's meant to be easier and more open than current initiatives.
One thing that can make it more useful than ZDI is that you lower the barrier of acceptance for a bug. In ZDI, you send them the bug, they decide if they want to buy it from you, and if you accept, they work with the vendor to get it resolved.
I can see numerous examples of bugs that they wouldn't necessarily be interested in buying from you, that a system like this could still provide for.
I happen to be in the camp who thinks the biggest problem with vulnerability reporting is the lack of response from vendors. A system like this, if it were to become popular, could serve as another way to keep them honest. But in order for it to be ubiquitous, you'd pretty much have to handle dealing with the "biggies", which I think would mean submitting vulnerabilities in the way they advertise.
I agree that it shouldn't ideally be up to the vendor how they deal with vulns, but I think you'd have to have tremendous momentum to shift that burden from you to them.
Remember: literally the one and only responsibility a vendor has here is "provide a secure way to send us findings". They don't have to provide a mechanism to post things publicly. If you sit on a finding for 60 days, nobody† will blame a researcher for going public with it.
† At least nobody with any influence over your reputation or hirability
The only case I can think of in which a vulnerability researcher could run afoul of a vendor in this scenario is if after they did their gig for the big company, they also wanted to post advisories on their website. We tried to thread this needle back in 2005 and gave up pretty quickly. The fact is, if a big bank pays you tens of thousands of dollars to whack a vendor, everything that happens afterwards should benefit the vendor; they, after all, paid for the work. The advisory on your website doesn't help the vendor. Why fight for it? Most of the time, your NDA and MSA strictly prohibit you from publishing anything anyways.
In the one-way-transfer example I listed, don't think "big company"; think "who besides a company might need a one-way-transfer". Maybe they're more "agency" than company, maybe in fact their name is an acronym (a lot of times those acronyms have three letters).
In that hypothetical example, the situation resolves itself the best way that it could:
The "agency", after reading your report about some fundamental insecurities in the product, realizes that it is currently deployed in places where the potential damage from the product being insecure is closer to "people being killed" than "money being stolen". So they pull it "off the market". That's an example where the vendor being actively hostile doesn't actually ruin your day (and you get to sleep soundly that night thinking that maybe you've actually found something that will be more useful than a cross-site-request forgery vector in an online dating site) .
As an alternative (and one which I should have used initially, but didn't think of at first), consider this:
You've found that a product being used by a client to facilitate check and credit card payments is a horrendous piece of shit (think "the custom crypto to encrypt the user database is literally an off-set substitution cipher that repeats every 13 places...the effort required to break it is less than that required for a cryptogram in the newspaper).
The client is glad to hear this, but is not in a position to either 1.) force the vendor to fix the issue, or 2.) replace the product with a more sanely developed one (the product is PCI compliant, after all, and the only reason you are there on-site is for them to pass a PCI audit).
So in that second scenario, you know that there are other people using this product, and it will most likely never be fixed. But yes, you've signed an NDA with your client, and all that you can do is make sure they're aware of the issue.
I don't think the system Zed is proposing will actually help in that example though; as you mention, what you discovered belongs to your client.