Here's a table that Steven (who'll be at TPAC) draw up that can be helpful to think about these things:

Also, I sketched up https://gist.github.com/agl/d4b7a646ec7474eec1071ebc9be77e79 to see about explicitly defining the map from registration options to high-level intent. (Take a look, you might think I'm crazy.) I've ignored all residentKey=preferred as something for the future. The combinations that remain undefined are:

(NoAttachment,RKNotSpecified,UVPreferred)
(NoAttachment,RKDiscouraged,UVPreferred)
(Platform,RKNotSpecified,UVDiscouraged)
(Platform,RKNotSpecified,UVPreferred)
(Platform,RKDiscouraged,UVDiscouraged)
(Platform,RKDiscouraged,UVPreferred)
(Platform,RKRequired,UVRequired)
(CrossPlatform,RKNotSpecified,UVPreferred)
(CrossPlatform,RKDiscouraged,UVPreferred)

If we take out those that are UV=preferred (which does not seem to make a lot of sense to me as an option) we are left with

(Platform,RKNotSpecified,UVDiscouraged)
(Platform,RKDiscouraged,UVDiscouraged)
(Platform,RKRequired,UVRequired)

The first two fall into Steven's “anti-exfiltration” bucket, i.e. you're checking for a credential that malware cannot have extracted from the machine and you're checking that there's a physical human at the machine. Perhaps this should be a documented use case.

The last is a typing-free situation, but with an odd platform attachment. Still, the intent can likely be categorised the same as other typing-free cases, leaving only uv=preferred and the flow around rk=preferred as undefined.

Thanks for putting this together. It seems to me, though, that there are even more variations of parameters to consider, which map to more and/or other use cases. For example:

• What kind of attestation is requested (none vs indirect vs direct) may affect whether the RP can "inventory" their authenticators (i.e., imagine an RP that wants to ensure users use authenticators from a defined inventory).

• Whether or not the RP uses the hmacCreateSecret extension affects whether the credential/authenticator can be used to unlock devices.

• Whether or not the RP uses the credProtect extension, and which of its possible six values it selects, affects whether the authenticator can be used in certain tap-to-sign-in scenarios.

These are just off the top of my head - there might be more parameters or other extensions that also induce separate use cases that RPs may want to consider.