Agree with @OR13. I'm still hopeful that privacy folks will jump into this and help us define the criteria. I've pinged in #58 and let's see about getting this on the agenda for the next call.

This is a novel use of privacy and security reviews for Registry updates, so I don't know that we have settled guidance yet. Please bear with us / let's do our best to figure out the best way to do this.

We did discuss briefly in the issue giving more specifics on privacy-related requirements for the protocol level, but I think we're unlikely to include all of those details within this registry section. Would it still be useful to summarize the high-level needs for the protocol, even if the reviews will inevitably be more detailed?

One consideration is that we expect not only to have reviewed the protocol specs for privacy, but also to have addressed any issues raised in those reviews, if the implications are significant for our privacy expectations for the system as a whole. So I suggest we:

• change the language to require a privacy review and issues addressed,
• add a citation to the user considerations/threat model document in whatever state we can (so that we can give some set of expectations to those trying to determine whether a protocol is well-suited), and
• indicate that the group should evaluate the results of those reviews when making a consensus call.

(I'm recovering from COVID; please forgive belated replies or awkward wording.)

Please remove the word “freely” and retain “publicly available”. It’s important for specifications to be publicly available, yet we know that some key formats and protocols for digital credentials are not always freely available. Discussing that in the context of the registry inclusion criteria seems neither suitable nor an effective use of our time.

Discussing criteria for inclusion in the registry, as part of a PR literally titled "Define registry inclusion rules", seems not only suitable but essential for this group, which is tasked with defining both the API and its associated registry.

To my admittedly naive eye, pushback against requiring specifications to be both freely and publicly available feels antithetical to the W3C’s ethos of openness and accessibility. The W3C's core principles emphasize that Web standards should be available to everyone, to support interoperability, global participation, and the continued growth of the Web.

What would be an ineffective use of our time, in my view, is a prolonged debate over whether free and open access to specifications should be a baseline expectation.

To my admittedly naive eye, pushback against requiring specifications to be both freely and publicly available feels antithetical to the W3C’s ethos of openness and accessibility. The W3C's core principles emphasize that Web standards should be available to everyone, to support interoperability, global participation, and the continued growth of the Web.

I think @bc-pi does raise an interesting point here. Is there precedent for W3C working groups effectively endorsing non-freely available specifications?

Discussed at 21 April meeting notes

I made some changes. @timcappalli, please take a look. If all looks good, please merge.