Good luck getting this adopted. A couple of months ago I was trying to responsibly disclose the complete exposure of every customer's name, email address, phone number and the last four digits of their credit card to a public QSR company that allows online orders. It was straightforward enough that I found it passively while trying to login.

It took over a week of me searching the website for a security page, trying to contact support on Twitter, emailing security addresses that turned out to be undeliverable, looking through my network for a contact, etc. Someone with a better network than me finally put me in touch with the right person in the security org, and the first response I received was, essentially, "Are you trying to sell us something? This seems manipulative. Why didn't you email our [undeliverable] address?"

As far as I'm aware, the vulnerability still hasn't been resolved. Here are the problems I see:

1. I don't know if this is a good implementation of this idea in the first place - how does this handle liability? I agree with what tptacek mentioned in this thread already: this seems underspecified, and companies looking to adopt this will want to have specific assurances with regards to liability and what's allowed. What exactly does "Disclosure Type: Full" mean?

2. If a company is not already in the tech trendy group that like to host security pages and use bug bounties, this is probably not even going to be on their radar. What is different about this that will appeal to them? How do you get a large, faceless organization which regards its security organization as more of a risk/compliance/continuity division than a technical software security division to adopt this standard?

To be clear, as someone who has gone through this song and dance several times, I absolutely would like to see improvements. But I don't know that this is the best way to do it. A more realistic standard might be a central tracker that maintains a list of key security contacts and their email addresses at various organizations. There are already lists like this floating around on GitHub, but they tend to be extremely out of date. Other than that it would be helpful to try and standardize a /security.html page with details about who and where to contact (instead of, say, a page that assumes every customer looking for a security contact mistakenly believes their accounts have been "hacked").