digital-credentials
digital-credentials copied to clipboard
WICG
Define registry inclusion rules
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?
If a specification is not freely and publicly available, I'm skeptical that we could effectively conduct privacy and security reviews. Individual W3C participants could pay the cost to access a paywalled document, but my understanding is that we would also have to agree not to disclose any of the details of that document to others. I don't see how we could comment in any detail on the privacy and security implications of a document without quoting that document in detail, or how we could effectively discuss the specification in a meeting where most of the participants don't have access to it.
I also think we should keep the requirement that an entry in the registry be freely available.
Making DC API a "pay to play" API if a more popular protocol in its registry requires implementers to pay for access to its spec is not considerate to the wider internet community. If a non-free protocol becomes popular enough then sure, people will buy access to it anyway. But as the product of W3C processes then the DC API's registry should reflect the values of the W3C and seek to make its capabilities available to as many people on the web as are interested in using it. I think this necessarily means we MUST (normative) require free access as part of making it into the registry.
I made some changes. @timcappalli, please take a look. If all looks good, please merge.