I’ve changed this to work dynamically based on the AAGUID stored during registration (if conveyed by the authenticator). The authenticator's capabilities are no longer stored; the functionality of the inspectors has been replaced by both the registration and authentication policies, and the credential labellers have been improved (they only exist to enrich the UI if desired).

I’ve also cleaned up the properties and config files.

The only reason I thought to record that, is so somebody could audit and possibly amend registrations at the credential repository level (e.g. inspect the database). But, that is probably unlikely, so I am happy to revert to an authentication-time decision on that, dynamically, via policy. I will remove that record from the storage record.

Right now I can’t think of a reason using anything else but aaguid to determine whether a token is eligible for second factor only or sole factor for that matter. For my use just having a blacklist of aaguids separately for sole factor and second factor works.

The custom bean possibility for each of those was just an idea since implementing it with the ability to do that as well isn’t meaningfully more work than without. With a custom bean you could cover any potential scenario you can think of.

What I was mainly pondering is if there was a need to tag a token for only some specific use at registration. I couldn’t wrap my head around why that would be useful vs. controlling the potential uses via just policies which can be altered at any time affecting tokens that have already been registered, too.

(thanks for trying this out so quickly, all this needs documentation). It should be saved on the credential record inside an authenticatorCapabilities map:

iff, idp.authn.webauthn.registration.authenticator.inspector.enabled=true, and you’ve listed the authenticator in idp.authn.webauthn.registration.authenticator.inspector.secondFactorOnlyAuthenticators.

The ‘Inspectors’ could indeed work on-the-fly during authentication (as we now save off the AAGUID), and similarly during registration for display. I’ll move those new actions in.

I’ll have to think about the separate strategies, currently, there is one big set of them (as you’ve seen), but you do have access to information about which type of authentication is happening e.g. 2fa, usernameless, passwordless. Of course you’d need to make your own beans to exploit that signal if you wanted behaviour different to the ones shipped (but it is possible the shipped ones could do that).

Is there a reason I am not seeing that a 2nd factor only flag would have to be saved with the credential into the store?

Just having strategy beans to determine whether a token is eligible for 2nd factor (or sole factor) on-the-fly seems ideal. That way if changes are made to those policies (strategy beans) the changes take effect immediately on all registered tokens without making changes to the database. Similarly the flags (which would be calculated instead of stored) in the registration view would be updated instantly.

Having separate policies/strategies for sole factor and 2nd factor would seem ideal. In many cases the policy for 2nd factor would probably be just a pass-through TRUE policy but not necessarily.

Potential scenarios where you would benefit are for instance if some passkey provider needs to be blacklisted completely for whatever reason or some passkey provider implements proper user verification so it could be used for sole factor.