Define registry inclusion rules

[marcoscaceres]

Closes #58

---

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)

[bvandersloot-mozilla]

Do we want to define the criteria by which this group would review those?

[marcoscaceres]

Yes. I think so. I was hoping to let those folks chime in about how we might do it, as some are already members of this group.

[timcappalli]

Is it worth including a non-normative example?

[marcoscaceres]

Certainly could, but if we can get one into OpenID, then that can serve as a good basis. Alternatively, we are going to specify that fake test protocol... so we could point to that too as an example.

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