Protocol registry: Reviewing is not sufficient

[martinthomson]

There are two requirements for protocols that I think need further elaboration:

MUST have undergone privacy review [...]

And

MUST have undergone security review [...]

Technically, a review saying "this protocol is awful in every way" satisfies these criteria.

It would be more useful if there were a set of concrete privacy and security requirements that a protocol needed to satisfy, such a review would be able to say whether a standard was achieved or not. It might be the case that there are subjective elements to a review, but there should also be a minimum bar that each protocol needs to clear.

This goes beyond the present set of requirements in the current inclusion criteria. I don't have a comprehensive list to hand, but one should be possible to develop. And once developed, that list should be in the spec. For instance, does the protocol depend on phoning home? Does the protocol (or the formats it conveys) guarantee unlinkability of presentations? Or - given that unlinkability doesn't make sense for some use cases - under what conditions does the API require the protocol provide unlinkability? What sort of transparency affordances does the protocol include? What sorts of covert channels are acceptable?

[johannhof]

Yeah, I think this would help with many of the issues @npdoty raises that live outside of the direct influence of the DC API, but are concerns that users (and thus user agents) of DC might care about nonetheless.

I'd like to start this work as part of the Privacy Considerations effort. I think it will have to be a longer term effort in the group as some of these requirements are more straightforward than others, and protocols are still being written.

[simoneonofri]

Hello, yes, this is similar to listing the mitigations that need to be managed outside the API (e.g., protocol level)

We can evaluate using an "Implementation Requirements" section, or produce a questionnaire.

This list can help speed up the reviews.

On the technical side, as we're talking about protocols, we can start from RFC 3552 (Security), RFC 6973 (Privacy), and RFC 9620 - draft (Harms). On a high level, we can model them with LINDDUN. We had discussed this in a side meeting at IETF 120.

[npdoty]

I think this was the point I was raising in #226

[johannhof]

Yeah... you're right. Probably a dupe, then. Anyway, it seems like there's interest in tightening up the protocol registry review process and normative requirements, which I think is a (the?) main thing to crystallize from the Privacy discussions so far.