submitted in the heat of the 2020-02-26 webauthn f2f meeting

use cases

1. 2nd factor use case, RP is indifferent wrt discoverablity ("discouraged" ?)
2. payments delegated 3d party cred, need NOT discoverable (ie "forbidden")
3. give user best experience for whatever SK they have...
   (disagreement whether having both 2nd factor or 1st factor in-same-flow is a viable use case)
   Shane: target for 1st factor, but will tolerate reg of u2f-style authnr if that's what user has, RP needs to know what got created, hence the credProps extension (this is "preferred")

forbidden means unless it's a ctap2.1 authnr, if rp says forbidden, then platf wont talk to the authnr

wrt "preferred":
jbradley relates the (real) use case of an RP that is future-proofing their registration flow by registering what the user shows up with tho "prefer" creating a resident/discoverable cred if possible (so they can later migrate them to a "passwordless" flow in the future) yet if the user has a legacy 2FA-only authnr the user will be accommodated.

<update with further context from meeting here>

in discussion, we decided that we retain required, preferred, discouraged for "discoverable cred", disagreed whether we need at this time to add "forbidden". perspectives on the latter:

a) "discouraged" will over time come to be "forbidden" in actual practice
b) "forbidden" is necessary to have

Nominally, we can go with (a) and see whether things fly in the greater web payments context (ie the "3P Credentials proposal")