How much levers to give the CA in the strictness of validation

[bwesterb]

Should we allow the client to specify the details of the quorum? Eg. min 2 out of 10. Or just a policy? Eg. CA/B 2026. Or leave it completely to the service.

[sciros]

We were just having this conversation earlier today about how "requirements-aware" the API should be and to what extent it should enforce them.
The policy to specify is a really interesting idea.
As of this moment, the open-mpic API allows for specification of any value for the quorum, with the value of 0 effectively rendering it a logging-only service that interprets all outcomes as passing. I am thinking of proposing a change to that, and have a pull request that's under review which nudges validation logic more towards the requirements-aware side of things.
At the same time, the quorum count is currently an optional parameter. In its absence, the default can either be fully configurable by whoever owns the services (i.e. set it to something like 5 in a config file) or it can be programmatically derived based on the count of remote perspectives being interrogated (i.e. perspective_count - 1 or perspective_count - 2 depending on whether that count is <6 or not.)

Anyway in the interest of making fast progress on this, here's my current thinking and what I'm considering implementing in the coming days, though I'm 100% OK with changing completely if my reasoning is faulty.

I propose that quorum count remain an optional parameter to specify to the service, to allow for a higher-than-minimum-allowed-by-the-requirements threshold. If you want a quorum of 100%, that should be possible.

I also propose that the default quorum is requirements-aware (programmatically derived). The logic used for deriving it can be policy-specific... that's something I hadn't thought of. I don't have a strong opinion on whether that should be how the service applies logic (i.e., it can apply a non-current policy) or whether it should just always be updated to reflect the current policy, and versioned accordingly. Perhaps the latter?

I also propose that the quorum count in the API request (assuming it's a whole number) is allowed to be below the required minimum only if the API is run in a diagnostics/dev mode with value validation (as opposed to request structure validation) disabled. That, or include a warning in the response that the quorum count used is below the required threshold and therefore cannot actually be used to support cert issuance. Not sure if the latter is really a useful use case to support, though.

[birgelee]

There are two points to this conversation I would bring up.

1. (which @sciros already mentioned) that quorum requirements change over time so a policy that is CAB Forum compliant now might not be in the future. Truly adhering to the CAB spec would mean changing the policy over time based on the implementation dates.
2. This is more broad than just quorum, the number of perspectives used in the first place is also related to the CAB F requirements. If we fully take this route of the API enforcing the requirements, does it make sense to force the perspective count as well (i.e., asking for 2 perspectives after 3 are required throws an error).

I am still thinking a bit more on this. I like auto quorum (so if you don't specify a quorum we go with what the CAB Forum says). I am still now sure how much the API should yell at you if you do something not CAB F compliant.

[bwesterb]

What about two options:

1. balance (default) Let the MPIC service choose. This allows the MPIC service to loosen or tighten requirements with more insight. Of course needs to meet current CA/B guidelines.
2. baseline Follows the current minimum CA/B minimum requirements, and nothing more.

I thought about adding a third strict option but I'm not quite sure how to define it.

And of course we add an optional-to-implement API for the exact count.

[birgelee]

I like the balance, baseline options as long as it coexists with a way to specify the exact count. I do like the idea of also having a strict option which I think should be defined are requiring a success from all perspectives used. Another name could be "full" for the option.