Function strongest 

pub fn strongest(challenges: Vec<Challenge>) -> Option<Challenge>

Pick the strongest challenge offered, which is a deliberate departure from RFC 8760 §2.4.

§2.4 says the UAC “SHOULD use the topmost header field that it supports unless a local policy dictates otherwise”. This is that local policy, and the reason is in §3 of the same document: offering MD5 alongside a modern algorithm “opens the system to the potential for a downgrade attack by an on-path attacker”. A challenge is not integrity-protected, so an attacker who can reorder the header fields can make the weakest algorithm topmost and a client that honours the order will comply. Ranking by strength removes that lever entirely, at the cost of ignoring a server’s stated preference among algorithms it has already said it accepts.

topmost_supported is the other policy, for a deployment where the server’s ordering carries information this client does not have.

Ties go to the earlier challenge, so the server’s order still decides where strength does not — and the result does not depend on how the header rows happened to be collected.