Define registry inclusion rules

[marcoscaceres]

Closes #58
Closes #191
Closes #124

---

Preview | Diff

[samuelgoto]

This seems like a good goal to me, but seems hard to accomplish logistically. Where does the WebIDL live? In this spec? In the protocol spec? What happens when they get out of sync?

[marcoscaceres]

I was imagining the protocol spec. In our spec, we would only link to the dictionary (i.e., our spec would only have [FooBar](https:/link-to-whatever.com/spec/#FooBar)).

[bvandersloot-mozilla]

It seems like it would be easier to include the definition in this spec as part of the inclusion process.

[marcoscaceres]

It could certainly be done that way. I do share @samuelgoto’s concerns about this spec falling out of sync though.

I was thinking that having just the name of dictionary in this spec minimizes the chance of things getting out of sync. Listing just the name is also what the Cred Man spec does in its registry:

https://www.w3.org/TR/credential-management-1/#credential-type-registry-appropriate-interface-object

[bvandersloot-mozilla]

Either would work, but we shouldn't require other specs that may already be completed to reopen themselves if they could just drop some webidl that describes themselves here. Particularly where they don't already define their structures with webidl.

[marcoscaceres]

Yes, that's a good point. Someone can correct me, but I think the only candidates right now are OpendID4VP (and the mDoc part), and maybe W3C VC? I think all of those are in active development with the aim of integrating with this.

but we shouldn't require other specs that may already be completed to reopen themselves if they could just drop some webidl that describes themselves here.

Generally speaking, what I'm finding is that you can't take existing specs and expect them to work out of the box with the DC API. They really need to be developed in tandem because the Web and JS have very specific requirements. The IDL requirement, along with clearly specified validation criteria, is actually a forcing function for those specs to integrate properly with this spec.

My feeling right now is that they might need to reopen themselves if they want to integrate, because they wouldn't be designed to work with a JS API in the first place (and if any such spec exists).

[samuelgoto]

I expanded on my concerns about this specific requirement here on this other PR, but I remain fairly concerned (security-wise) about requiring all browsers to redeploy before protocols can be extended:

#156 (comment)

[TomCJones]

what's the stable URL of the mDoc? or of the VP for that matter?

[OR13]

This looks good.

If it's possible to use openid as the first example I think a working example will do a better job of explaining than a fake example.

The requirements seem good.

The privacy and security evaluation criteria need to be more explicit though, and there should be a documented appeal process, for rejections.

[marcoscaceres]

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.

[npdoty]

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.)

[hlozi]

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.

[bc-pi]

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.

[jogu]

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?

[bc-pi]

#157 (comment) is the reason I'm requesting changes.

[timcappalli]

2025-04-11 WG call: remove Avoid using version number in the protocol identifier.

[TallTed]

Note that this avoidance results in a requirement that the protocol include version negotiation, even if that is as simple as the two sides of a protocol exchange announcing their version, each to the other, with the potential that either or both sides will respond, I cannot interact with that version of this protocol. <Something> must be updated.

[RByers]

We shouldn't require conversion "before it is passed onto the underlying platform". Perhaps delete everything in the parenthesis?

[RByers]

Ditto

[wseltzer]

Discussed at 11 April meeting notes.

[wseltzer]

Discussed at 21 April meeting notes

[RByers]

This looks great to me now, thanks Marcos and Tim!

[samuelgoto]

Inclusion rules LGTM++

[c2bo]

Seems somewhat redundant to

MUST have a stable URL that points to a freely and publicly available
specification.