Open annevk opened 3 days ago
In this context, this is describing processing logic for the consumer of the API and the received messages.
A failed verify will defer to the application's error processing logic. It is a runtime security check on the message received via the API, and not a logical invariant.
I suspect an enhancement here would be to describe relying party behavior when a verification step fails across the entire section.
I will add that as a consumer of the API I did not have any confusion on this particular element of this section - but I'm on the "experienced" end of the spectrum when it comes to these sorts of systems.
I could see verify being changed to assert for syntactic clarity in the cases where we're talking direct equality between two values (such as steps 7,8,9, and 20) but I do think that "verify" is pretty clear in what is occurring, and it should come down to the RP to determine how they wish to process an erroneous response, as dwaite mentioned.
If you want to record an error or return from the algorithm with some kind of error you need to actually state that.
For example, https://w3c.github.io/webauthn/#sctn-registering-a-new-credential has a step that reads
but it's not at all clear what this means or what should happen when it cannot be true. If it's always meant to be true unless something outside of the scope of the specification has happened, it would be more appropriate to use Infra's Assert primitive.
If it can actually have other values, you'll need to define how to handle those.